Any low hanging fruit left in this 128G OC @ 1900 FCLK?

Associate
Joined
24 Aug 2004
Posts
383
Location
Glasgow
I've pretty much reached the limit of my knowledge about about tuning RAM on a Ryzen system.

For search engines:

Corsair Vengeance RGB Pro CMW128GX4M4D3600C18
Hynix M-die (MJR) H5ANAG8NMJR-TFC

It's 128G Vengeance Pro 3600 C18-22-22-42 kit, it's Hynix parts but at that density there wasn't really a lot of options in stock without importing and praying.

Mb8LO49.png

In any case I understand Hynix has the capacity for higher frequency but depending on the die/bin can suck for tighter timings.

I think I can probably thank my SoC silicon, I pretty much just slapped this stuff in - set the SoC voltage to 1.15v, set the FCLK to 1900 and the RAM to 3800. Booted first go, nice.

It posts at 18-20-20-36 with 1.36v but fails hard at C16 at any frequency (this was expected after reading about Hynix M die).

Are there any more easy sub timings I should tighten up? I really have no clue what to look at next, thinking there's probably not much room for improvements now?

3NGbb3g.png
 
Last edited:
Associate
OP
Joined
24 Aug 2004
Posts
383
Location
Glasgow
If you cant get your primary timings down (tCL, tRDRD, tRP, tRAS) the next most impactful are your controller to dram latencies. These are in two sets, the first and most important are tRRDS, tRRDL and tFAW (Set tFAW to 16 first then tune down the other two timings independently and go down one at a time). The next set are less impactful, these are tWTRS and tWTRL (4/8 should be your target but I suspect 4/12 may be the limit).

You can try reducing tRDRDSCL and tRWRWSCL to reduce same channel latencies, these can usually go as low as 2 but having quad ranks may throw that out the window.

Finally dial back your tRFC as that's way high, keep it a multiple of your tRC value (you should be able to start at 840 and go down 56 at a time) but don't go gung-ho with it as you can cause OS corruption if you try and boot into windows with it too low. Mid to Upper 600's is where Hynix usually lands.

Thanks great advice, need to run a few burn/stability test now and I think i'll call it a day. Wasn't expecting much out of these sticks but 1900 FCLK was a pleasant surprise.

Do take note though that tuning 128gb of memory is something nobody has much experience of. Its hard on the memory controller running 4 x 32gb sticks already so you won't reach the same kind of timings as others have running 2 x 16gb of the same chips. Also thoroughly testing 128gb of memory takes a long time....a very long time. This will not be a quick tune, you should be prepared for a lot of post failures and stress testing that takes many hours at a time.

Yes! had the same issue last time around with 4x16G ;)

Also according to your screenshot your SOC voltage is at 1.05v...

Ah, so the interesting thing about that is after having to set 1.15v VSOC I noticed there was a fair amount of vdroop, I've applied an amount of VSOC LLC and it seems very happy now at 1.05v - sensors report 1.03v but I'll ged the multimeter onto the provided board contacts just to check the LLC is not spiking.

Here's where I am with no burn/stability tests so far:

DlH1WAL.png
be081a3d-bda2-4886-b8d9-4f8f3708b8d8
 
Associate
OP
Joined
24 Aug 2004
Posts
383
Location
Glasgow
You've managed a nice drop in latency there, nearly 10% well done :). It's latency improvements you'll feel most in usage, so that's where you want to spend most of your efforts really. Its the rarer use cases where bandwidth comes to the fore...though 4 x 32gb is a rare use case already :cool:


I've only experience with Samsung B-Die, so the below rules are based on that. It would be interesting to see if they hold true for Hynix too:

tWR can always be set the same as tWCL, lower requires testing.

tRTP can always be set to the same as tWTRL, lower requires testing.

tRDWR and tWRRD are set as a pair on AMD. It looks like you're at a slightly more relaxed setting from the 8/3 it defaults to with Samsung. Most of the time 9/1 seems fastest but I wouldn't try going that low, there's definitely a loose relationship with tCL and tWCL too.

Timings ending in DD refer to latency between Different Dimms. These can usually drop to 6 on Dual Rank B-Die or 1 on Single Rank B-Die

Timings ending in SD refer to latency between ranks on the Same Dimm. These can usually drop to 4 on Dual Rank B-Die or 1 on Single Rank B-Die

Timings ending in SC refer to latency between dimms in the Same Channel - you already have this at 1 though so it can't go lower. Included just for information only :)

Cool cheers, trying to elimate some instability which I feel has been there since I enabled PBO2, so I've got the current timings locked in a profilie I'll run for a few days. I'll check out these additional timings and report back in a few days.
 
Associate
OP
Joined
24 Aug 2004
Posts
383
Location
Glasgow
So just to complete this after a year or so of running the tuned/stable XMP on these sticks - here's where things ended up after benching and burn. This equates to about a 5-6% performance uplift in e.g. linpack type workloads versus the non tuned XMP profile.

Thanks again @MrPils :D

uLoeRKk.jpeg
 
Last edited:
Associate
OP
Joined
24 Aug 2004
Posts
383
Location
Glasgow
tWR can always be set the same as tWCL, lower requires testing.

tRTP can always be set to the same as tWTRL, lower requires testing.

tRDWR and tWRRD are set as a pair on AMD. It looks like you're at a slightly more relaxed setting from the 8/3 it defaults to with Samsung. Most of the time 9/1 seems fastest but I wouldn't try going that low, there's definitely a loose relationship with tCL and tWCL too.

Timings ending in DD refer to latency between Different Dimms. These can usually drop to 6 on Dual Rank B-Die or 1 on Single Rank B-Die

Timings ending in SD refer to latency between ranks on the Same Dimm. These can usually drop to 4 on Dual Rank B-Die or 1 on Single Rank B-Die
For the timings ending in DD|SD anything lower than the values in the previous post and the system wouldn't post
The other values had an amount of leeway but on longer burn tests I saw a few errors and felt I was starting to see minimum returns from the time being invested in more benching and burn tests
 
Last edited:
Back
Top Bottom