This XMP profile isn't updating at 3600Mhz.
This XMP profile isn't updating at 3600Mhz.
Testing the stability of the clock frequency comes first. This is what I’m referring to with SSE OCCT. I suggest running it for an hour. The key point here is that this involves a lot of detailed work. DRAM Calculator isn’t very helpful; if you send more vDIMM, the timing specs will decrease (especially compared to Micron chips). This affects parameters like tRCD, tRP, tRC, etc., depending on voltage. Generally, these numbers can drop if higher voltages are used. In terms of relationships, it’s not a strict rule but some basic stability considerations apply. You might achieve sub-150ns on tRFC (timing/frequency multiplied by 2000 equals the desired value), though there’s no fixed guideline—experimentation is key. If you manually adjust tRFC, skip tRFC2 and tRFC4 as they won’t be used. The tRRD_S difference is usually a few clicks lower than tRRD_L (think 4/6 or 6/8). You’ll likely hit around 14-18 tFAW at about 4000 cycles. Since you’re using AMD, the tREFI is fixed, so you can’t modify it. Also, tRAS equals tCL plus tRP combined with some extra terms—this isn’t a definitive cutoff; just ensure it stays stable. Performance will improve as you lower tCL, but be careful not to overshoot. tRTP generally helps by reducing instability until a point, which can boost reads. Lowering tRCDRD and tRCDWR further won’t help much unless you go beyond certain limits. Don’t forget that tCWL should match or be slightly lower than tCL (depending on how low you go). If you reduce tCL too much, you’ll need to increase tRDWD, which is acceptable if it improves write performance. Remember, running a full profile (like TM5 with the Anta77 file) can take several hours. It’s important to sync half-clocks properly with AMD’s memory management, and enabling GDM is crucial for stability. Running without GDM makes things harder. Keep experimenting, but don’t lose focus on the main goal: stable timings.
There's one kit of red Ripjaws that are dual rank on a 8GB stick. It's such a crap bin, so almost not worth mentioning. Everyone has commented about how four sticks is harder to stabilize FCLK wise than two sticks. Indirectly true, but 4x8 is actually going to be worse--rank eqalized--versus 2x16GB. In latency bound scenarios, you'll see a 2-8% uplift solely because how the MRC trains subtimings. Instead of feeding through two ranks on a single stick on single slot in a single channel, now you got to go through two different slots with two different sticks. When you boot up, the MRC (through the board and DRAM) will train a few times to run the memory sticks at the speeds programmed into them from the SPD (or randomly guess). This is done by a very complicated computational algorithm which essentially balances the operation boundaries of the motherboard / DRAM and the I/O requests and power to the rest of the system. Since you auto'ed, it'll basically be voodoo magic in what outcomes is spit out. 4x8 sticks on daisy-chain motherboards are going to have to train harder to sync everything together (Proc ODT among other impedances go weeee), despite that the latency doesn't necessarily follow that rule. Though explaining RTLs and IOLs is not something I want to do here.
Discussing these parameters—ProcODT, RTT_NOM, RTT_WR, RTT_PARK, CAD_BUS timing—is it really crucial for performance or stability? Or are they just minor details best left set to AUTO? It might have added some noise to your question.