Thank you for the log. This is really unusual as in virtually all cases we have seen the GPU thread either crashes or freezes entirely. The watchdog checks for this but if there is any regular progress in the GPU thread, it "thinks" that the GPU is OK and doesn't restart the miner. In any case, there is something wrong with GPU2 (maybe the clocks are too high?) as it had 10 incorrect shares and 33 correct ones: almost one quarter of its shares are incorrect. Even if it is showing 31-32 MH/s hashrate, its effective hashrate is at most 80% of this - 25-26 MH/s. Generally, anything above 1-2% incorrect shares is a sign to dial back the overclock a little on that specific GPU to avoid losing too much of the effective hashrate.

We could add a command line option that specifies the minimal "normal" speed but it would be of limited usefulness if the rig has vastly different GPUs, or if the ambient temperature slowly rises and the GPUs start to throttle to avoid overheating.


Basically, it "rearranges" the memory accesses of the OpenCL ethash search kernel a little in attempt to hide part of the memory access latency. If the GPU memory had zero latency, an RX580 would be making about 33 MH/s with standard 2000 MHz memory clocks. The default value (15) is usually the best but in some cases (extreme overclocks, aggressive BIOS mods to lower the memory latency, etc.), you can achieve slightly better hashrate with different GT parameter. Please note that after changing the parameter you have to wait a minute or so for the hashrate to settle and see if it is better or worse than before.