Topic: AMD Mem Tweak XL - Read/modify timings/pp/straps on the fly - page 50. (Read 58892 times)

IMO RFC impact to Share, High RFC much shares, Low RFC less shares

the higher --ref value for my cards is 12800 for vega56 pulse hynix runnung 940mhz mem.
All samsung cards are running below 10000 --ref.
With higher values I got hashrate drops, dead gpu in teamred, hw errors or inconsistent hash.
All my cards are tuned to run 50-53 degrees gpu temp, it is 60-65 degrees hbm temp according to gpu-z.
vega56 cards are downvolted to 800mv (~775mv in gpu-z). vega64 cards with higher soc clock for higher mem clock are downvolted to 825mv (~800mv in gpu-z)
vega56s are doing 20.5kh/s, vega64s are doing 21.2-21.6 kh/s.

What temps are you running to handle this --ref 15600 values?
Or are you using low intensity settings such as L18 for teamred to compensate it?

I will get to that eventually.

For now I'm testing other settings.
On normal timings the best intensity was L24+24. at the same core/mem freq I had consistent 19,24kH/s on all cards +-0.05kH/s.
On new timings this intensity was not that stable. After that L22+22. After 4,5h of hashing first HW error showed up and speed was 21.85 kH/s but with the spread od 0.4kh/s betwen cards.
After that I have tested L20+20 but that was ruled out because of decrease in hashrate of about 0.5kH/s/cards.
Now I'm using L18+18 and got result of 21.83 kH/s +-0.03kH/s between cards.
Using Adrenalin 19.4.1.

What memclk?
I got instacrash with this. Also you can try to lower FAW to even 12. After some discussion it seems lower FAW is better.

Why?  if temps are low enough, data is more stable, and refreshes can be less frequent.  Stock setting is almost certainly tuned to gaming usage under expectation of super high temps, plus a healthy margin.  And if the setting is too high, it should manifest in mem errors and/or invalid results due to bit flips - no need to look at pool rate.

FYI, my pool rate is as expected (w/ --REF 15600)

--CL 12 --RAS 28 --RCDRD 12 --RCDWR 5 --RC 44 --RP 10 --RRDS 3 --RRDL 3 --RTP 5 --FAW 20 --CWL 7 --WTRS 4 --WTRL 9 --WR 16 --WRRD 1 --RDWR 19 --REF 17550 --MRD 8 --MOD 15 --PD 8 --CKSRE 10 --CKSRX 10 --RFC 250

guys. this crazy high --ref values you are using can't be good. check your pool-side hash ...

vega64 lc is happily mining 21.2kh/s with 1230/1090@800mv showing only 115 watt in HWinfo GPU chip power

First - quick results for cn-trtl, w/ efficiency-focused settings, using timings mostly borrowing from others here, w/ some minor tweaks:

Vega 64 air, ubuntu 18.04 + amdgpu-pro 18.50, TRM 0.4.3 (L18+18), 852 cclock (p0)/1107 mclock/818mv, power readings at the wall

stock timings:
--CL 20 --RAS 33 --RCDRD 16 --RCDWR 10 --RC 47 --RP 14 --RRDS 4 --RRDL 6 --RFC 260 (--REF 3900)
18.5 kh/s @ 135w (137 h/w)

modded timings 1
--CL 19 --RAS 28 --RCDRD 12 --RCDWR 5 --RC 44 --RP 12 --RRDS 3 --RRDL 3 --RFC 248
19.75 kh/s @ 137w (144 h/w)

modded timings 2
same as above, plus --REF 15600
20.71 kh/s @ 137w (151 h/w)


Second - notes on power...  I don't see any appreciable power differences - nor would I expect to.  Clocks and voltages are untouched, we simply have a bit more data being transferred.  Even the 2w difference I'm reporting here is conservative - taking natural fluctuations in my readings into account, my actual increase could be closer to <= 1w.  People seeing large power increases (at least on vega 64) seem to have something else going on.


Last - some conjecture / educated guessing re: THAT --REF THO!!!  I'm assuming --REF is the refresh frequency, in nanoseconds, and unlike most timings, a higher value (meaning less refreshing) is better.  Refreshes steal bandwidth, and AMD seems to have gone majorly conservative (aggressive?) on this, probably due to the super high temps of the HBM during normal/gaming use.  As leakage increases w/ temps, more refreshes would be required when running your GPU/HBM at high clocks/voltages.  Since (efficient) miners tend to run cooler, the crazy high default refresh rate is really unnecessary.  I found 4x the default to be around where returns quickly diminish, at least at my clocks - i can get maybe another 50 h/s (turtle) going 4.5x.  HOWEVER - if you run super aggressive for max h/r, or just aren't effectively cooled in general, you may want to dial this back, or you may start seeing mem errors / bad shares from corrupted data due to insufficient refreshing / leakage.

First - quick results for cn-trtl, w/ efficiency-focused settings, using timings mostly borrowing from others here, w/ some minor tweaks:

Vega 64 air, ubuntu 18.04 + amdgpu-pro 18.50, TRM 0.4.3 (L18+18), 852 cclock (p0)/1107 mclock/818mv, power readings at the wall

stock timings:
--CL 20 --RAS 33 --RCDRD 16 --RCDWR 10 --RC 47 --RP 14 --RRDS 4 --RRDL 6 --RFC 260 (--REF 3900)
18.5 kh/s @ 135w (137 h/w)

modded timings 1
--CL 19 --RAS 28 --RCDRD 12 --RCDWR 5 --RC 44 --RP 12 --RRDS 3 --RRDL 3 --RFC 248
19.75 kh/s @ 137w (144 h/w)

modded timings 2
same as above, plus --REF 15600
20.71 kh/s @ 137w (151 h/w)


Second - notes on power...  I don't see any appreciable power differences - nor would I expect to.  Clocks and voltages are untouched, we simply have a bit more data being transferred.  Even the 2w difference I'm reporting here is conservative - taking natural fluctuations in my readings into account, my actual increase could be closer to <= 1w.  People seeing large power increases (at least on vega 64) seem to have something else going on.


Last - some conjecture / educated guessing re: THAT --REF THO!!!  I'm assuming --REF is the refresh frequency, in nanoseconds, and unlike most timings, a higher value (meaning less refreshing) is better.  Refreshes steal bandwidth, and AMD seems to have gone majorly conservative (aggressive?) on this, probably due to the super high temps of the HBM during normal/gaming use.  As leakage increases w/ temps, more refreshes would be required when running your GPU/HBM at high clocks/voltages.  Since (efficient) miners tend to run cooler, the crazy high default refresh rate is really unnecessary.  I found 4x the default to be around where returns quickly diminish, at least at my clocks - i can get maybe another 50 h/s (turtle) going 4.5x.  HOWEVER - if you run super aggressive for max h/r, or just aren't effectively cooled in general, you may want to dial this back, or you may start seeing mem errors / bad shares from corrupted data due to insufficient refreshing / leakage.

This is by far the best settings I tired.
4x Vega 64 with waterblocks.
Core [email protected] and [email protected] Normally it was 19.24kH/s/Vega. After the timing set is about 21.85kH/s/Vega.
Max temps: Core 40*C, HBM mem 53*C.
Team Red Miner v0.4.3 L22+22. HWinfo GPU chip power 157W. I don't have a power meter.
almost 4h no errors. https://ibb.co/R7CWKjw

You would be using a  lot of power. You should be able to drop your core and voltage a lot. 950mv is soo high for 1300 core.

This is by far the best settings I tired.
4x Vega 64 with waterblocks.
Core [email protected] and [email protected] Normally it was 19.24kH/s/Vega. After the timing set is about 21.85kH/s/Vega.
Max temps: Core 40*C, HBM mem 53*C.
Team Red Miner v0.4.3 L22+22. HWinfo GPU chip power 157W. I don't have a power meter.
almost 4h no errors.
https://ibb.co/R7CWKjw">https://i.ibb.co/t3b56Lr/Vega.jpg" alt="Vega" border="0">
prywatne">https://pl.imgbb.com/'>prywatne serwery plemiona

Hi Guys,

Zorg33 said to me share this set, because it's impossible, but working good for me:
--CL 12 --RAS 28 --RCDRD 12 --RCDWR 5 --RC 44 --RP 10 --RRDS 3 --RRDL 3 --RTP 5 --FAW 20 --CWL 7 --WTRS 4 --WTRL 9 --WR 16 --WRRD 1 --RDWR 19 --REF 17550 --MRD 8 --MOD 15 --PD 8 --CKSRE 10 --CKSRX 10 --RFC 250

Vega56 @ 64 sapphire samsung ram, Win10, 18.6.1 and 18.5.1 classic 1408/900core 1100/900mem

Turtle 22+
ETH 51+
Cr-Lite 10K khs (1600/990 1100/900, but crashed, 9600kh 1408/900 1100/900 super stable after 24h)

On another note, what's the idea behind increasing values like FAW or REF?

cool!  cnr 1450/900? is it 1450 core and 900 memory? how about the voltage? is it can run for long time?