These ones I did them manually I used the Try it frequency option and worked my way 4400 but settled for the 4300 and just tweaked it a little, so if they are not to bad I may just leave them as they are, Thanks for your input
Have you properly tested this for stability? What's your DRAM voltage, and what are your exact modules?
The timings are very good for that speed. You have to put it all into perspective with the actual DDR4 frequency. The timings actually come down to nanoseconds, if you factor in the frequency.
There is actually no DDR4-4266 that has XMP timings of CL18, the lowest is CL19. DDR4-4266 at CL19 equals a CAS Latency of ~8.91ns. This is the same as DDR4-3600 CL16, which if you know something about RAM, isn't bad at all! And you're lower than that, so the latency equals something like DDR4-3600 CL15, but of course with higher bandwidth because of the higher frequency.
The higher in frequency you go, the harder it becomes to keep low latencies, as the RAM and the memory controller are under more stress, and certain electrical parameters are close to leaving the specified range.
I would guess you are using quite highly rated modules already, and the BIOS must've set the DRAM voltage close to 1.4V by now or even higher...
So, those modules use either Samsung B-Die chips (more rare) or Hynix CJR (more common). You have a really nice result if those really use Hynix CJR. If it's Samsung B-Die, you could optimize here and there a bit, for example, unlike CJR (where only tCL can go lower), the Samsung B-Die can handle tRCD and tRP on the same level as tCL. Then you could consequentially lower tRAS a bit, too.
But it's really nothing to fuss over. This all takes ages to verify for stable operation. Every little setting you change, you have to at least a quick RAM stability test for 15-30 minutes. Then in the end you have to try lowering the DRAM voltage again, and do final stability testing over 2-3 hours, especially with 32 GB.
Don't think that it's stable, just because Windows doesn't bluescreen or show problems. Unstable RAM can slowly corrupt your Windows installation and ruin your files. Some errors are only found after half an hour of running those programs, some rare errors only after >1 hour.
You could try GSAT to be absolutely sure. It's the toughest RAM test of all.
But this is a good result for Hynix CJR, if it's stable! You might be able to optimize some things a little more here and there, but to be honest, i don't know if it's worth the additional effort, and it might need more voltage in the end. I would just leave it at this. I mean, you went from 3600 to 4266 with decent timings while staying under 1.4V.
tREFI is the Refresh Interval, the higher, the less often it does a refresh cycle (for the time specified via tRFC). Because for that whole time where the refresh cycle happens, there is no data transfer to/from the RAM. So raising tREFI is one way to have more data transfers and less refresh cycles to interrupt it.
The only slight problem is, data retention is very hard to test. You see, the transistors in the RAM slowly lose their charge, until they're refreshed again. Too short tRFC you can see more easily, cause the RAM will fail training and throw an error during POST, or don't wanna POST at all, if you set it too low. Too high tREFI, the only test i know for that is one of the last tests in Memtest86, the bit fade test, https://www.memtest86.com/download.htm#free
But it's also temperature-dependent. The hotter the RAM chips, the faster they lose their charge. You could theoretically create a worst-case scenario by blowing hot air onto your RAM with a hairdryer (not too hot and not too close) and then letting Memtest86 go to work.
If you're curious, for my Samsung B-Die, i went the safe route of setting tREFI to 32000. Most people will set it to 65K without batting an eyelash. But since you can't test it very well, unlike most other parameters, i am more on the careful side.
It all depends on your modules, the chip density on the modules, and the frequency the RAM is running at. The higher the density of the chips on the module, the longer the refresh has to be, and therefore the higher tRFC has to be. Density means for example, a 16 GB module using 8 chips has double the density of an 8GB module using 8 chips. Then there are known values to which certain types of chips can go down to, again, depending on the chip in combination with the frequency it's running at. If you run at DDR4-4266, your tRFC has to be higher than at DDR4-3600, to arrive at the same amount of time in nanoseconds.
However, tREFI (the interval between refreshes) is always officially deemed to stay the same 7.8 μs (microseconds, from mikros = small in Greek). There is no such dependency on density etc., but instead they said, this is a proper value for DDR4 RAM that will ensure that there's never a problem, no matter the module. This, of course, is thrown overboard with RAM OC. You see most OC guides recommend to max it out at 65K. But most overclockers who write these guides only tend to test for stability. As i said, data retention is much harder to test, the bit fade test in Memtest86 attempts to do it, but i don't see much RAM failing on that part of testing. Maybe it has to be tested in a worst-case scenario like i mentioned before, because as the modules get hot, the official specs call for double the refresh cycles (every 3.9 μs).
I try to stay more on the safe side and go to tREFI 32K with my Samsung B-Die. There is really no scale for it. If you want to be safer, stay at 32K, if you want to challenge something that's hard to test, go to 65K at your own risk...
Note that in the above table, tRFC is in nanoseconds. That is not the value you enter in the BIOS, that one is in clock cycles. To calculate the tRFC value, there is this table:
350 ns at DDR4-3600 means a tRFC value of 630 clock cycles. Depending on the chips/ICs used on the module, you can go a bit lower, a bit more lower, or way lower in the case of Samsung B-Die. B-Die should be good for 160-180 ns. This is one of the main strengths of it. For your DDR4-4266, if it were B-Die, you would be able to set tRFC as low as 340-380 clock cycles. But with other chips, this is not possible at all. With Hynix CJR, you're looking more at 280 ns as the lowest time, which means, you could try tRFC 600 at your frequency, looking at the above table.
Here are some best-case tRFC capabilities of certain types of chips used on modules:
Again, in nanoseconds, so only really useful if you have the table that translates this to clock cycles for different RAM frequencies. The lower the time value in ns, i.e. the shorter the tRFC refresh cycles, the better for RAM performance. But these are best-case values where you would always add a little headroom. That's why i said, for your frequency, you could try a tRFC of 600 instead of 630.
I forgot to mention that I had tried tRFC at 610 previously and it did not boot so I went tRFC620 it booted but the numbers were a little bit out of sync which is why I am on 630 tRFC now
What do you recon
Yeah that's always a bad sign if the RTLs or IOLs are too far apart for the two channels. Good on ya for keeping an eye on that. Stay at 630 then, definitely. As i said, the table with the best-case tRFC capabilities, you always have to add some headroom, not all modules are capable of it. You're still just under 300 ns tRFC with that, which is respectable for anything that's not Samsung B-Die.