Originally Posted by Ortus
Changing SD DDs to the higher value didn't seem to make a difference in AIDA but noticeably increased the amount of time HCI took in dram calc, membench easy went from around 101s to around 108s. It looked like it was also increasing the time Kahru was taking but I didn't think to record times for Kahru the whole way down.
If you've gone down to tRCD 14 instead of 15 - tRDWR 7 would be better than 8
tRCD RD / 2 = tRDWR has to work on 16Gb dimms, but it won't if you waste some latency somewhere
Originally Posted by rares495
Veii can tell you more but lowering tRDWR was always the first thing he recommended. I think ideally you want it to be half of tRCDRD but it will never work so (tRCDRD/2)+1 is what most people end up using. As far as I could tell, it really matters more than tCWL for performance.
Originally Posted by 2600ryzen
I think lower tcwl increases copy performance, not sure.
Edit: looks like it's the other way around, I just tested tcwl 14 trdwr 11-1 v tcwl 16 trdwr 8-3 and 8-3 had better copy BW.
Using low tCWL was on the intel side of things a tweak, as they have tRAS, tRFC, tREFI as scales and a lot of split optimisations on the
tRDWR -> tRRDR
tWRRD -> tRRDD
AMD -> Intel
Side of things
tRC i haven't seen anywhere changable and the "best way" to get lower performance was to drop tCWL
But tCWL <-> tRDWR go hand in hand
If you lower one, you have to up the other one by the same amount
on AMD , tRDWR i found to be next to SCL the biggest perf increase factor
If tRDWR = tRCD RD / 2 won't work
just add a bit of latency on tWRRD, then it will work
Usually it shouldn't need it, only when you go -1 of half tRCD
((tRCD RD/2)-1) on Single Rank dimms works even when you lower tRC -2
Originally Posted by rastaviper
As I have mentioned at a previous post, I have managed to run all of them with 1T, except the tRDWR which at 7 didn't allow my system to boot.
Anything else to push more? Can you explain what is the 5-5-7-7 for the SD DD's exactly?
And the tRas should be 27 as in your image or 29? Because I have it at 27 and it runs fine.
I can't fully yet
They are added transfer delays, while running 1-1-1-1-1-1 works on unstable kits but results in at least 8-10% perf drop
I follow 1usmus's research here, pretty sure dimm amount does define the values and likely also PCB revision ~ as they are just cutoff delays
tRAS i had as 27 in the picture because tWR was 10
What you see in black or whatever colour fits for the time, everything that is applied needs a change at the same time
If one thing is off, the set might break
If nothing was written, just continue to use what you have
tRAS 29 was for your set, tRAs 27 was if you follow the remain timings which do include tWR at 10
As we know
tCL+tWR+tBL = tRAS
Originally Posted by nick name
Since I can't find any concrete answer on odd primaries (tRCD) being changed to even I went ahead and just set 14-14-14-14 with tCWL at 12. Thanks to
for reminding me that I needed tWRRD set to 1 and tRDWR at 10 to drop tCWL below tCL. I used to leave those on Auto but this latest CH7 BIOS sets them super high when left on Auto. I set tRFC to 6 x tRC. Honestly, that's kinda why I liked 14-13-13-13 because I could set tRC to 40 and tRFC to 240. Setting tRFC to 252 just bugs me.
So ten hours of Karhu. The warmest the DIMMs got was 42*C and I set 1.5V with a droop to 1.48V according to HWiNFO. I think I can drop the voltage a touch, but 1.5V is kinda my default. My SOC is 1.106V with a droop to 1.1V and VDDG 1.05V and VDDP 1.0V. Everything else set to Auto.
GDM off results in immediate errors though it will POST and boot.
So it appears that running straight 14s depends on your RAM and not your settings. I'm not sure what attribute of the RAM allows for it though. Whether it's die quality or something else.
CPU cache is set to enabled in Karhu.
tRCD depends on the IC binning and the PCB, a bit on the voltage but the same goes for ClkDrvStrengh
There has to be enough so the dimms can run GDM disabled and can be driven, but more won't do anything
Could maybe pass-bye with 0.2v more to lower primaries one step further down, but then it also depends how the IC scales and if it can even run voltage beyond 1.56v
A bigger advantage of voltage you get by being able to lower tRP
Which logically lowers tRC
You can test your luck on the dimms how low you can get tRC ~ likely micron has different scaling than b-dies
(Micron rev. E kits can use the same tRDWR math and -2 on it without breaking stability, it's just something only they can do)
B-dies without affecting any other timing, can go tRC down to -2
Lower than that might need tCWL +1 = +2 as even number, to show positive benefits
Although the amount of positive benefits on this kind of shifting, i haven't tested ~yet~
It's an option to consider tho
Overall clean tRAS -> tRC transition remains key, and won't be affected by Dual Rank or who knows 64gb dimms
But going lower than tRC-2 i can't see as viable option so far.
If tRC-1 on DR works i haven't tested so far, but pretty much only Single Rank can abuse this tweak
Same for tRDWR=((tRCD_RD/2) - 1) with added tWRRD delay, only SR exclusive
Originally Posted by Ortus
Turns out being unable to lower tRCDRD further might be entirely temperature related, all the other timings are fine up to 50c at least, but tRCDRD starts throwing errors at 30.5c, spewing them at 36, and crashing at 41.
Probably not cracking that when my room hits 25c ambient most of the year.
Try it out,
Capacitor discharge is Temp related, but i haven't seen anyone go under tRC*6 , *5 should be possible but i haven't gotten my hands on anything to work personally on recently
Voltage should only increase heat - it will increase the amount of charge and up to your timings, more will be left
But then higher heat has a negative effect and they will lose even faster the charge
tRP is there to adjust and help on this "issue"
If your dimms get too hot, increase tRP
If you want less vDIMM, increase tRP
if you want to meet a tRFC target, decrease tRP and increase voltage
Only increasing voltage won't really grant you a good tRFC ~ as neverless what fixed refresh-cycle-delay you pick, tRP same as tRAS has to pass before anything can happen. The same goes for tRC, nothing will happen till that one elapses and tRAS being the only one that is autocorrected if it's ACTIVE timing ends up being too short.
After ROWs are ACTIVE'ated = tRAS
and are read, they lose charge ~ more like the charge is transferred to the sensing amplifiers
Soo they need to be (p)recharged again.
DDR4 can write data to this cells while they recharge, but every readout is a full loss of charge
tRC = the Row Cycle is scale-able and the end point of this one operation.
You can cheat and just increase it, where nothing will happen till this cycle ends
At the benefits of stability on lower voltage.
Although again, this is cheating and should only be considered on awkward temperatures like XOC or your typical SpaceHeater system
Intel altogether skips this value, as only a clean transition matters
Although intel users do often push tRAS higher and so tRP also higher to cover it
A technique is also to increase tREFI to the maximum and just let the memory time break after the 9th tRFC happens
This way the only thing the OCers could learn is, that tRFC is depending on charge
(tRP, so tRAS - well you get the point)
And the early answers that tRC for tRFC didn't matter and only depends on voltage, where kinda correct but also didn't show the whole picture
There is far back then , but let me reupload it again:
A wonderful 150+ page PDF of Abusing DDR-Heterogeneity
Mr. Donghyuk focuses a lot on the tCL+tWR+tBL topic -> especially for tRAS
1usmus learned from this too but he is an engineer by himself, soo it likely wasn't the only source of information
Cycle-Stacking , or rather "discharge-stacking" is the method that allows such ruleset breaking "rules" to work
This includes tRC-2 or factoring in tSTAG
I hope we get to control tREFI and tAL (time added latency)
helping us to calculate stuff tighter and with lower tWR limits