Ok lets start from a beginning.
Clocks. 1530@1050V and 1100@1050. Works great on CNv8 with 15+14. 2050h/s. Cards are on water.
On the same clocks on CNR and those crashes. On 13+12 works with bad hashrate reporting. At that settings and 18.6.1 driver I have 36*C on the core and 155W of power.
I also use this miner for Lyra2rev3 with 108Mh/s per cards with no problem for weeks.
So NO, this is not the problem with voltage/clocks setting.
Every algo creates a different load signature, which can require different clock/voltage settings. Just because some combo of settings worked for some other algo, doesn't mean it will work here. Though it does appear the settings should be close to cnv2.
What about the bad hashrate rapport? This is voltage/clocks setting issue to?
Absolutely - I've seen the same behavior, in many different miners, for many different algos. Just now, in linux, I experienced a 2700H/s report from TRM stemming from a too extreme uv.
Yes, the combo of clocks and algo is the key metric. The issue with this algo is the random code (re)generation. Since we build our kernels in asm, we don't recompile like the other miners, we solve this in a different way. In turn, this means this kernel gets a very different load footprint in one specific way.
@wacholek: we've also done some extensive host-side changes in this release, so can you verify that CNv8 and lyra2rev3 runs just as good as before with _this_ version, not 0.3.8 or 0.3.9? Would be great data to have to fix things. Also, I remember you running some custom mod for water, but what OS and driver are you running?
System Win10. 4 x Vega 64 wit LC bios on water.
Lyra2Rev3 1500@950 1100@945 On v0.3.10 429.8Mh/s ; On v0.4.0 435.7Mh/s. Very good. Hashrate and avr Hashrate the same. Good work!!!
I will test CNv8 later.