btw, it didn’t affect my fans…
@brnfex - I think you’re ignoring the obvious here. Under no circumstances should you get a null pointer deref from doing “safe” overclocks. Something in the new version has issues. Until those are ironed out, the updated amd-oc shouldn’t be forced on everyone. Even if I do no OC at all, default fan speeds, I can still recreate the null pointer deref, 0% fan speeds, etc. If the only thing that changed is amd-oc, and reverting it back to the prior amd-oc resolves the issues, what does that tell you?
And as for the bios mods, they’re just your standard memshift ones. Nothing fancy.
Anyways, I’m open to further suggestions, but I’m certain I’m not the only one having issues with this. Even my boss, who runs several hundred rigs in a DC has had nothing but issues with this and had to revert or hold off updating.
New amd-oc here is working beautifully.
Reduced consumption + - 100w in a rig of 12 RX580 8Gb / 371MHs (6 Asus Dual OC + 6 Sapphire Nitro).
I needed to reduce the DPM from 5 to 4 (core from 1257 to 1215MHz @ 900mv) because one of the Sapphires crashed.
I am very pleased with the change.
Thanks to the colleague who suggested the script.
We’re relying on an external tool, so that’s out of our control. Literally the only major change are two loops that iterate over the voltage and core states, so there is something odd here. amd-oc shouldn’t apply settings at all if you have no overclock set up in the dashboard.
Can you please run the result of:
wolfamdctrl -i 0 --show-voltage
wolfamdctrl -i 0 --show-core
If you can, please run the amd-oc directly and check the output about errors.
@HaloGenius just need run overclocking in stream. Because for one GPU in “amd-oc” need 22 (!) heavy command! It takes a lot of time (and if 10-13 GPU?)
IMHO need to correct the code to run in the separate stream:
for coreStateCtr in {1..7}; do #setting frequencies for all states
wolfamdctrl -i $cardno --core-clock ${CORE_CLOCK[$i]} --core-state $coreStateCtr &
done
and
for voltStateCtr in {1..15}; do #setting undervolt for all volt states
wolfamdctrl -i $cardno --vddc-table-set ${CORE_VDDC[$i]} --volt-state $voltStateCtr &
done
This will work very quickly. Because it doesn’t wait for an answer from command.
Personally I’m think option in web interface like pill in NVidia will be best solution in this case
@steambot, I’ve just tested that and it made my cards unresponsive. It must be done linearly, or to somehow copy the card’s PP table, modify it and then and move it back - not sure if it will even work.
@brnfex i havn’t amd gpu for testing. just i think that need to find correct --volt-state and --core-state.
From what I have seen so far while testing with fixing core voltages - something happens to pp_tables and if you try to re-apply amd-oc without restarting miner - system will hang (most of the times). So, when I was modifying amd-oc on my own, I also modified agent.do_command.sh so it would restart miner every time I went for amd-oc change.
Anyways, this new amd-oc should work magic on undervolting AMD cards, but it looks to me that we need to restart the miner process every time you want to change amd-oc settings.
Hey guys, just to add my 2 cents… I have tested 0.5-54 on my small rig of 2 x RX 470 4GB and 1 x RX 480 4GB. The rig has been running stable for 24 hours now, with core clocks set to 1050 1050 1150, memory clocks set to 1950 1950 2075, core voltage set to 905mv and DPM at 5. I have had no issues whatsoever. Reported power consumption is down by more than 80w!
I think HiveOS devs should start making a database of gpu models with vbios and OC values, accessibles to users (or maybe paid users) with optimized values. A kind of “1 click optimization” ?
I’d pay for that…
each card is different… i don’t think it is plausible.
Each GPU, even from the same brand and series, behaves differently. There is no way to make an universal solution that doesn’t suck for good ones or doesn’t crash bad ones.
Totally agree with @brnfex.
Cards stay a the same only when they in stock state. If you made any manipulation with BIOS, core or memory clocks then you just forget about “cards from the same party”
Just for example - cards from the same party has different ASIC quality. The same with any element on the board.
I agree with @brnfex and @HaloGenius - each and every card is different and you can’t have “one solution fits all” here. Especially if you are pushing the cards to their limits. Furthermore, I have seen on the Net few lists with that info, but never had real benefit from them. Basically, if you want to be efficient, you need to learn few things and figure out things on your own. And when you do - you’ll be proud of yourself 
@givo - I had the same findings. After numerous bits of testing I got this all working. However, two things:
- Applying settings while the miner is stopped, and then starting the miner while the settings are being applied typically leads to a NULL point dereference and the system hangs (have to hard reboot)
- Applying settings while the miner is running leads to the same results as #1 or settings not being applied correctly (ie, fans at 0% or less than applied values)
@HaloGenius Suggestion:
Place a lock on the amd-oc or some check that if amd-oc is running, then a 2nd copy can’t be ran. This would fix the double application of amd-oc when applying it with the miner stopped and then started. Additionally, when applying changes from the gui, if the miner is running, restart it instead, as amd-oc is applied when the miner starts.
Hi HiveOS miners,
I have to add some notes to this thread, since I’m using the undervolting technique recently introduced in HiveOS for more then 3 months, so I have some experience with it (from roughly 10-20 mining rigs).
-
first of all - You can’t combine wolf’s ohgodatool with another common technique - VRM voltage offset in VBIOS. actually, you can, but it might cause problems and it does not make sense. So, you have to remove the voltage offset from your VBIOS and reflash your RX card
-
fan speed related issues: actually, I never got the idea enforcing the GPU fans to a certain level. If You need to lower the GPU temperature (and the memory modules/mosfets tied to a GPU heatsink), lower the temperature target instead of forcing the fans to certain level of PWM. and most importantly, never-ever set the fans to their max PWM, and then complain about fans lifespan
-
applying the settings on-the-fly: I recommend You to stop the miner, run the script, then start the miner again. I’m doing this when switching from one algo to another (for example, from ethash to cryptonight v7/heavy), since some algo performs better with higher core clocks.
Anyway, I’m happy to see the introduction of this technique in HiveOS, this might help other miners to switch their rigs to LinuxOS.
1 Like
@dewminer76 How do you know if I have voltage offset from my vbios? (you know a linux command line?). Because I don’t have a Windows to tune my cards, I only go to anorak tech and get vbios from there. That might explain my problem of sysfs disapearing for some cards for fan control
@dewminer76
You just confirmed all my personal observations and conclusions on this topic.
Anyway is dirty hack to get low power consumption.