Corsair Dominator 3600CL16 on X299 Dark

[dmann3042000]

Running a solid X299 build, with 10920X with 64gig of memory.  I do know this platform has poor

latency, however, their seems to be alot of tweaks to make it better.  was running cl 18 version of memory for awhile, but was

sort of paranoid of it being AMD optimized, and could never seem to make stable other then the XMP , which runs solid, but always worked fine

and Aida64 memory test seems mid 70's for letency test, so i had a chance to go cl16 3600, and at 5Ghz, the latency is now 90.

Seems the lower CL16 timings seem to make latency higher, so what tweaks will lower latency? and yes system is very snappy, and very

stable, just shows in Aida64, poor latency, and mesh is at 30 if anyone asks.

[c-attack]

Aside from CAS latency, the secondary timings have the most impact on latency in the way programs like AIDA measure. Take a look at the guide below. It’s a lot, but definitely one of the core resources for DDR4 memory adjustment. The tREFI values are usually part of XMP and can vary, but the motherboard may do its own thing as well. 
 

https://github.com/integralfx/MemTestHelper/blob/oc-guide/DDR4 OC Guide.md

 

[dmann3042000]

Very helpful, and much thanks.  Buildzoid had a piece on this with XMP and x299.  And how Aida runs tests.  I was hoping though with cl16 of this would lower my 

latency, however , it showed 90 in the test.

 

[c-attack]

XMP timings are generally soft on latency, regardless of brand.  Then there are additional factors that are CPU specific, but working the secondary timings is the key.  I think even at 8000 my DDR5 XMP kit was 70ns for AIDA latency.  Once I hand worked the timings, that dropped to 58ns without changing the primary CAS value.  

[dmann3042000]

So whats a good way to work the sub timings? I follow buildzoid, but he made changes to the top set of timings, and the IPC offset vcore.

Again, i do use cpu at 5ghz, and 64 gig of ram.  I did hear that higher capacity memory needs additional tweaks.

 

 

[c-attack]

RAS to RAS L (long) and S (short).  There is a specific section in the guide about this.  You can't get too aggressive with 4x16, but I would hope 8/8 is feasible.  This then ties into the tFAW setting further down.  Use the Short value x4, so 32 is RAS to RAS_S = 8.  In all likelihood you can run 8/4 which then makes tFAW 16.

 

CAS Write Latency (tCWL).  This one also has it's own section in the guide.  Values range from tCWL=CAS Latency to -1 or -2 in tight timings.  This is definitely one that will crash you when off.

 

The tRFC  refresh cycle times will shrink your AIDA score. How much they matter in real life is another matter.  Special section on this and it depends on the IC.  Some guestimating required.  Not a value that will flunk you on the boot test, but when set to low causes locks up.  It's a large numerical value, so no need to be super aggressive.

 

In the same vein is the tREFI or refresh interval.  This is another 'benchmark friendly' timings that reduces latency, but if you use long duration real life loads be somewhat cautious.  A value of 32,768 should bring back a few ns without posing any risk, even under extended load.

  

That's plenty to start.  Once that is tried and tested, the tertiary RDRD and WRWR sg/dg offer the most bang for your buck in terms of Read/Write improvement.  The "safe" settings in the guide will best auto settings by a good margin.  

[dmann3042000]

In short, where can i find this guide? and being a 10th gen X cpu at 5ghz load, 4x16 will be tuff?  with tight timings?  and in a nut shell 

what values should i really focus on? on sub timings?

[c-attack]

The github linked guide is in the second post.  The timings listed above have the most affect on latency, but there are other things you can do.  

[dmann3042000]

21 hours ago, c-attack said:

The github linked guide is in the second post.  The timings listed above have the most affect on latency, but there are other things you can do.  

Interesting charts.  For some reason even though its Corsair DDR4 3600cl16 dominator, it shows micron in spec, not Samsung B di which i 

thought Corsair uses on higher end memory.  I sorta feel dooped on these modules, thingking they were B di.  

[c-attack]

Samsung B die was getting scarce toward the end of the lifecycle, so it depends on when you purchased.  In the kits between 3200-4000 the usual way to tell was by primary timings.  The Micron would have higher tRCD and tRP, usually CAS Latency +4.  Samsung B die typically had +2 from CAS to tRCD/RP.  

[dmann3042000]

I don't what i did, but there was a setting that was in the 900s, so i was able to lower it to 630, and wow latency is in 70's now vs 90s before.  And i did hear that

about Samsung vs Micron.  There a few more tweaks i can make here to get the very most of this setup.

[c-attack]

That’s the tRFC and auto values are usually high. 
 

I wouldn’t worry too much about b die vs Micron at this point. If this were a 2x8 kit or even 2x16 you could clamp down pretty tight on the primaries but the CAS latency first value is likely to be the same. Either way, you’re not going to run 4x16 at 16-16-16-32 so the B die might be wasted. Something like 16-18-18-36 vs 16-20-20-36 is not going be a big deal if you tighten up the secondaries. That should put you way ahead of anyone running b die at XMP. 

[dmann3042000]

Makes really good sense.  Why is it when doing quad with 16's at 16 all the way?  2x8 or 4x 8 was a breeeze, but at 64 gigs really 

stresses things.  And agree about b di vs micron at this point, but b di, you can overclock the piss out of that stuff.  and the kit i have

is the quad 64 gig kit at 16 18 18 36 btw.

[dmann3042000]

Been getting good latency now on the cl16 and secondary timing, but what is a good daily voltage for these modules and do i need to up 

the voltage if im tuning secondaries?

[c-attack]

Push any value too low/high and you may need more voltage to compensate.  However,  I would simply use any secondary value that allows you to maintain stability at your chosen voltage.  Going up 5-8C with a 0.05v DRAM voltage increase is likely a bad trade for a half nano-second of latency.  These things are often temperature sensitive on stability, so that push from 52C to 60C now causes the entire thing to become unstable and you are worse off than before.  Other than sport benchmarking, pushing the voltage up for lower level timings usually does not make sense.  1.45v is about as high as I would go for general use.  If you've been working with 1.40v, you might stay there but certainly can bump up and see what happens.  

[dmann3042000]

I leave the dims on 1.380v on a daily.  I see alot of people like buildzoid, or durbour run at 1.6v, but for benchies only.

And i played with a setting that people have gotton down to 240 called refresh cmd, but 632 is about as low i i do, seeing

lower does nothing. and even a no post below 540.

[dmann3042000]

I have noticed, that lowering the TRFC below 600 seems to lower latency a bit in aida64.  however, going lower like some of the

setups around here, say: 280, my setup will not post despite upping voltages slightly.  Could be he all core 5GHZ, 32 mesh that is

making things not happy.  I use stock 1.35v on these dims. good tight settings, but is 65ns ok in Aida64?

[c-attack]

tRFC has a specific value that is likely to cause lockups or freezing -- or maybe just errors if testing.  It's usually somewhat specific to the IC and also the density, so somebody running a 2x8 kit can crank down pretty hard while the 2x48 or 4x16 kit will need much higher values.  tRFC definitely will help with AIDA latency or any other benchmark, but it's usefulness in most real world apps is going to be bit lower.  When it doubt, go up.  

 

I am not sure how much lower you can go with a quad channel board.  Typically the increase in bandwidth comes with some latency cost.  

Edited December 6, 2023 by c-attack

[dmann3042000]

I run 4x16 dims at 64gigs on X299 Dark, so makes alot of sense.  I think when i was running 4x8, my

latency was much better in aida.  I use the setting of 587 which was detected on auto, but when xmp is

detected, its about 930, which is horrible.

[c-attack]

What value are you using for tREFI?  That one determines how often it recharges the row. You can mitigate the time to recharge the row by having it recharge less often. This is the one with the large 16K-232K values.

[dmann3042000]

I got that setting at: 32767, which is what i got from , buildzoid.  I  run trfc at 587, which was auto at stock mem settings before xmp.

[c-attack]

You can try 65535 for tREFI and see how that moves the Aida latency.  It's probably about 0.9-1.0 ns and you can decide whether that is worthwhile.  On an 8 slot board with only 4 sticks, you likely don't get super hot.  On the other hand, if you run long, heavy loads quite a bit, better to stick with the lower value unless you actively monitor the RAM temp.  

[dmann3042000]

32767 is as high as it goes.  I could let auto piick up the setting, but Steve at Gamers Nexus says go to max on it.  Any other setting that

is crucial to latency?  Aida means nothing to gaming, or some stuff like blender, but its good seeing aida showing 66ns instead of 60ns.

[c-attack]

I'd say call it day.  It's mostly the secondary timings that affect latency and in most instances it is benchmark specific.  Interesting the tREFI maxes out at 32767.  That may be a quad channel limitation.  I haven't had one in a while.  

[dmann3042000]

I will more than likely to call it a day.  Since here, on is just deminishing returns.  It seems, even

though i get slighly lower latency, it does nothing to gaming.  I though those who did this added

20-30 fps to games, but not really.   I also use 587 on trfc which it likes.  And being quad channel

and dual rank at 64 gigs across 4 channels, and a all clock 5ghz, it pretty much, just  enjoy it. instead

of cranking more out of X299