Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 95. (Read 211877 times)

cn-trtl doesn't need high core clocks.  Vegas are fine at 1275-1280 core clocks and can be undervolted to 806-825mV depending on quality.
40 KHs doable on VII @ 1575 core/1250+ on HBM2 (dirty oc).

Is someone able to share their PPT file or paste the contents where they are able to run sub 875mv? I have always had difficulties running below 875mv on my reference Vega 56/64. This is with having memory below 1100 and core as low as 1250...

All my above posts are with p states 0-6 disabled. 
I think new drivers can handle this p state transition better . I post once i get results.

yes, thanks.

I disable non needed power states on Overdriventool beta and now able to run my vegas 64LC at ~1280/1100@800mv with 19.6khs. gpu-z power readings 105-115watt
I'm on win10 19.3.3 drivers

This is exactly what I was saying caused problems.  Try either disabling all lower p-states in your ODT profile, or set the lower values higher than 800 - for instance, as a quick POC, just write 850 to all but p0 (both mem and core)



I don’t remember off-hand, but it was the last version of 18.x.  In general, I’ve seen no noticeable differences between windows driver versions since at least 18.6.1 for any algo (and I’ve tried most) unless using an wolf0/xmr-stack (or clone) miner, which had an issue w/ >18.6.1

Hi devs,

does is it possible to add lyra2vc0ban?

Thanks.

1. Ive rechecked my PPT. SOC is @ 1107 : HEX : 6C,B0; Also confirmed with HWinfo
2. My Base PPT has 800mV on all P States from P1 to P5; P6 is also 800 set via ODT;
    Mem P states are also set to a base 800mV,
3. Power limits are set at 0%

My Core p7 state : 1408 @ 875mV; Mem p3 state : 1100 @ 875mV
Any lower crashes the system.

This is the same state im in 


Re-reading your post, the only difference i see is the driver, which im in 18.6.1 and you in 18.11.x
Maybe try that over the weekend. What is your exact driver version?


Edit : To clarify, the crash occures not after applying the ODT and GPU reboot,  Crash after TRM initiation, maybe its a TRM thing

That's not necessarily true...  SOC and core appear to share power lines (which explains their relationship in bios/ppt) - I've seen many cases where a specific voltage which didn't seem to be enough for 1107 SOC was suddenly fine when I dropped core low enough.  Ethash was a great algo to test this on, as you can run Vegas at p0 w/ no performance effect.  CN-trtl is similar in this regard - while we may not be able to go all the way down to 850 Mhz cclock, 1100 is perfectly performant, and leaves a lot of power headroom for SOC/IF, resulting in lower required voltages.

In short, it's really the combination of core clock + SOC clock which determines your voltage requirement.

my vegas 64 liquid didn't want to go below 875mv (850 in gpu-z) with soc clock 1107 (needed for mem clock 1100). It results in 19.6khs
For 1140 mem clock (1199 soc clock) they need 900mv (875 in gpu-z). It results in 20.2khs

It doesn't depend on gpu clock - only soc clock is setting min required voltage.

vega 56 ref samsung with stock bios is happily mines with 825mv (800 in gpu-z) with 940 mem clock resulting 19.5khs

My 806mv cards may be golden samples (or at least silver,) but i have 5 of my 64s online now, at 806, 806, 812, 818, and 825mv.  Effective cclock is between 1150-1190, and reported h/r is 19.53-19.54.  I'm pretty sure you could get any 64 to 806 if you drop the cclock low enough (which is reasonable on this algo,) but it seems anything under 1200 MHz shouldn't need more than ~825-831. 

Even sub-1400 shouldn't need more than ~850mv, so it seems like you most likely have a problem in your ODT profiles or ppts:

1. Check that you're SOC is running 1107 and not 1200.  I assume it is, since you say your cards crash above 1107, but SOC is the primary reason i see jumps from sub-850 to above 875mv.

2. I've noticed in my testing that I can have cards crash if lower states aren't sufficiently powered - seems they can trip up during the brief transition across states during miner startup.  Solution is to either disable all lower states before starting the miner, or carry your top voltage all the way down to at least p2 (if you're using super low voltages like me.)

3. I have no definitive proof, but I have gotten the sense over many tests that the GPU threads aren't super isolated - i.e. one GPU struggling w/ insufficient power may cause another GPU to crash first, making it rather difficult to determine where your problem really lies.  Even if it's not necessarily the case, it's good practice to tune the GPUs one at a time - only adding another to the list once you've ensured stability of those already online (over hours, not minutes.)

Lastly, i should mention i'm on Sapphire Nitros, though i do have a single ref 64 i have yet to switch over, but which has always performed within the top third performance-wise of my nitros, so I don't think there's a inherent difference, other than cooling design.

I just ran a quick test on EthOS with a pretty bare bones config and it crashed initializing due to apparent 'opencl 2.0' refusing to load. That said, haven't gone super far from there. Running R9 Fury in 5 card config (known working). Pretty much a corner case here since I run a fairly large amount of specifically the AMD Sapphire Fury 4GB HDM, which I would happily keep running since they do really well on memory intensive algorithms and crazy low power (ran 800+ hash on last XMR Cryptonite_8 using claymore with processor underclocked @ 70-75w per card). I am super happy to buy a few beers for anyone tossing some solid ideas on how to get TeamRedMiner running under ethOS with R9 Furys

Ok here goes trying to replicate pbfarmer:

Testing :
Cards : Vega 64 (Reference - aircooled)
Averaging : Running on 6 cards and reporting to 1 card stats to ensure stabilty of settings
OS : Windows 10 1709
Driver : 18.6.1

CN_Config : L28+28 (Since thx to pbfarmer tests is the most optimal)


Note:
1. Core clock has ZERO impact on power consumption and MINIMAL effect on hashrate
1. If seting had failed in any 1/6 cards, then results are not posted
2. Goin below 875mV in ODT crashes
3. Goin above 1100mem in ODT crashes (till 1107 stable but in same strap)

pbfarmer : how did you get to 806mV  

Rx550
4300hs
My vegas  19.2-19.5khs

Great work now to get voltage down on my cards

Once again you guys rock

Thanks a lot for extensive tests, will try to replicate on windows and post results

Ok, only Vega 64 for now, and only from a single GPU (though voltage needs should really be the only variable moving forward w/ addl GPUs).  Will try to post VII and 590 numbers later:

Env: ubuntu 18.04 + amdgpu-pro 18.50.
Best cn_config - based on initial test: L28+28 (see table below)

Test desc	|GPU (actual cclock, mclock, mv)	|Miner h/r (kh/s)	|Power ATW
|CNR settings	|1390 MHz, 1107 MHz, 825 mv	|19.60	|?
|mclock+	|1390 MHz, 1145 MHz, 900 mv (not tuned)	|20.18	|?
|mclock+, cclock--	|1210 MHz, 1145 MHz, 862 mv	|20.14	|~170w
|Final settings	|1210 MHz, 1107 MHz, 806 mv	|19.54	|~150w

Notes:

• Definitely lower power requirements vs cnv4/cnr if tuned properly
  
• Algo performance is heavily dependent on mem bandwidth, not so much on core clock speed.
  
  • Increasing mclock from 1107 to 1145 gave ~+3% h/r, but at a heavy cost (+13% power) due to SOC scaling to 1200.
  • Dropping core clock from ~1400MHz to ~1200MHz only reduced h/r by 0.25% (19.60 to 19.54 kh/s) - all the way down to ~1100MHz still gave 19.45 kh/s, but 850Mhz resulted in ~12 kh/s, so there is a cliff somewhere, or maybe I needed to re-adjust cn_config
  • I didn't do any more tests reducing cclock further, as I was already down to the voltage floor at 806mv/1200MHz.  However, if we can go significantly lower (like ethash,) we may be able to save enough power in cclock reduction to make an mclock boost worth it???
  • Finally another algo that would seem to make the 56->64 flash worth it.
• cn_config 'L' variants not only had better h/rs, but seemed to also put less pressure on GPU, therefore requiring slightly less power
• Windows 10 pro w/ 18.11.x drivers produced exact same results at my efficiency settings in linux, so didn't bother testing further. In general, I find w/ most algos that as long as the effective (under load) clocks match, h/rs and power use will match as well.  The only real diff between linux and windows is the cclock setting required (much higher) to get to your desired effective cclock.

   

cn_config	hashrate	___	___	cn_config	hashrate
L28+28	19.60			28+28	19.32
L28+30	19.57			22+24	19.32
L26+28	19.57			24-24	19.32
L26+26	19.56			20+20	19.30
L24+24	19.52			23+25	19.08
L20+20	19.48			25+25	19.06
24+24	19.44			L30+30	19.06
L28-28	19.39			22+22	19.01
24+26	19.36			23+23	18.95
26+26	19.34			L27+29	18.89
26+28	19.33

Been running the miner fine since the fork but the rejected rate seems a bit high for some reason all across the board. Even with the newer updates i'm still looking at 2% rejected rate.

Where should we be looking for 470/570 cards as far as the config? I've tried L16+48 and some inbetween didn't see much.

Looks like you guys have covered vegas pretty well.

yes, win10 with 19.3.3 drivers and level 1 timings

Not trivial to measure, there are a few different trade-offs in play, but I'd actually say they're about on par. CN-turtle uses the CNv8 main loop which (in our case) draws less power than the CN/r main loop, but CN-turtle does for sure put more load in general on the gpu than the 2MB pad variants.