integralfx / memtesthelper Goto Github PK

https://github.com/valleyofdoom/StresKit

I can confirm that on MSI's Tomahawk and ASUS' TUF Z690 DDR4 boards tRP and tRCD are not linked. You can set different values for them and they will not default to using the highest number. They are utilising the separate RP and RCD registers of Alder Lake

I can also confirm Gigabyte has NOT followed suit, yet, unfortunately

Is there any information about what VDDq voltage we should be using for Alder Lake? I see VCCIO in the guide but that's not an option for 12th Gen

I'm surprised no one seems to mention this anywhere, but these timings mutually drive each other. The rule is tWR = 2*tRTP. These two are configured via the Mode Register 0 (MR0) in the memory.

Taken from the Micron Rev E datasheet but it's the same for all DDR4 afaik.

How can I Solve this?

I use MemTestHelper v2.2.0

and MemTest 6.2

http://www.mediafire.com/file/pd57k0dkj9p0722/MemTest62.zip/file

Hi

I see you at least used to support 6.0.1 in pre 6.4 builds, I tried them out, but when I hit the run button, it launches the HCI memtest processes, but then nothing happens, they are launched as if I launched manually, awaiting input of ram amount and to hit start.

Is this only for the non pro version?

Lower tWR have the potential to allow lower tRTP to be stable. Lower tRTP however means you can go lower on tRAS and probably be stable there which is one of the major timings. It is certainly a bad idea to move tWR to the end.

However tritary timings are not necessarily the one that should be left to end. an example is tRDWR and tCWL. While tRDWR is a tritary timing, tCWL is a secondary one. It is always better to have tRDWR not higher than 8 then tighten tCWL later for both stability and performance on Ryzen IMC.

As soon as I started the test the program crash but the test work just fine. tried to change "start minimize" but it doesnt work.

I highly advise warning that corruption is possible during RAM overclocking, and to advise users to regularly do sfc /scannow checks every so often after a change is made to make sure there isn't any. From personal experience, tRFC+tRP and RTL/IOLs can potentially cause corruption if overly tightened.

Over extensive testing, I have found that tRCD+tRP raises the IMC voltage requirement. Thus, I suggest tweaking it after all other timings are done rather than in the beginning, as other timings tweaks may be stable but instability could be wrongly attributed due to insufficient IMC voltage. This is a good resource for common BSOD error codes: https://www.reddit.com/r/overclocking/comments/atwtt5/psa_bsod_codes_when_ocing_and_possible_actions/

When tRFC is too tight, the PC can freeze, so that is something to mention for people to keep in mind. Also, increasing VDIMM allows tRFC to be tightened further. Here is a convenient chart of tRFC values to test (not mine): https://i.imgur.com/6Zg1MKy.png

Due to RAM being heat sensitive, it is recommended (for gamers) to perform a lengthy game test at least 80% GPU usage to test whether the GPU's ambient heat will cause the PC to BSOD. I suggest a constant test of at least six hours; I've had BSODs occur anywhere between 1-5 hours.

The explanation for tRC is somewhat confusing; rewording it would be nice. An easy way to explain it would be: If reducing tRFC+tRP and tRAS can boot but cannot pass TM5, gradually raise tRAS.

The easy way to tighten RTL and IOLs is to first train them on Auto and then for every -1 decrease in IOL, you want to decrease the same matching RTL by -1. It is sometimes more efficient and stable for all IOLs to be same. Some motherboards do not like when IOLs are manually changed, so you would increase the IOL Offset instead.

At the end of the guide, you could add a note that those with Samsung B-die or Micron B/E-die can experiment raising their voltage beyond the 1.5V JEDEC spec, at their own risk and discretion. Up to 1.6V should be safe for most people, so long as they have proper cooling for their RAM. This will allow a further reduction of CAS latency and increase of frequency.

You should advise people to run a benchmark such as AIDA64 after each change to make sure there is an actual improvement in performance. Many timings have regressive performance if they are set too low.

Which memory timings do you think that they mostly increase the load on the CPU IMC?

Under "Timings Software", there is no entry for X99 chipset. Asrock Timing Configurator 3.0.6 is the last known version for that chipset to display timings correctly.

Hi,
So, I have pondered on your suggestion of the equation you propose to determine tRAS being:
tRCD + tRTP = tRAS

And while I believe thats correct in the manner you stated "tRTP" ... but the problem is on that graphic from the anandtech article that you reference ... tRTP isnt shown on it, furthermor .. the tRTP setting in my bios anyways is more akin to the Fig 7 graphic from: https://www.anandtech.com/show/3851/everything-you-always-wanted-to-know-about-sdram-memory-but-were-afraid-to-ask/5
and not necessarily the definition you provide when referring to the graphic you posted (because such timing is missing from it).

So, after reading anandtech's article and looking at some of the RAM operation types and their graphics (the page hit, page miss and page empty) graphics ... and when looking at the graphic you posted.
Ive come up with following equation that seems to ,at least be more in "spirit", of the timings shown between all those graphics.
So, using the graphic you provided, I believe this is how you would calculate the "tRTP" you reference:
"tRTP" = CL + tBurst(4 on DDR3/4 afaik) + 2
therefore
tRAS = tRCD + CL + tBurst(4T on DDR3/4 afaik) + 2

While this might sound high .. when reading through the anandtech article .. it seems that using this equation .. allows all the operations except tRP fit nicely into the tRAS window + 2 clock "padding" (idk if the +2 is necessary, it may not be and may without the +2 that could be considered "minimum tRAS") ..when I reference the stock timings on my RAM, the +2 is not part of tRAS(but for some reason the pic you reference has those extra 2 clocks(maybe a DDR3 vs DDR4 variance? idk)).

Now one possible variance I can see, is I think anandtechs article is about DDR3 ... perhaps the requirements/ window / timing for tRAS has been modified in DDR4? idk.

My initial testing results with my memory testing / tweaking considering the above...
Ive been testing my DDR4 @ 3800 - 17 - 19 - 19 - 38 (based on your current equation) ... and seems to work fine.
Ive changed the 38 to 42 ... based on my new equation, and so far I havent seen any noticeable performance loss in aida64 at least. In fact, upping it to 42 alone allowed me to increase IOL offsets another 2 notches, brining my latency down even more.

Anywho, perhaps something worth exploring =)

Under section mentioned in title, when calculating the delays in nanoseconds, DDR4 MT/s values are taken instead of dividing them by 2 to get the ram's true frequency in MHz.

I don't know where to go with the question (I have used some Fb groups and forums but noone is helpful so far). I got Viper Steel Patriot 4400mhz 19CL, unfortunately doesn't work stable on any xmp profile so I needed to find something on my own (I am now a novice in ram oc) and finally I have found two stable setups:
-3600mhz 15-15-15-35 at 1,4V (vccio&vccsa at 1,15V)
-3900mhz 15-15-15-35 at 1,49V (vccio&vccsa at 1,2V).
I have i9 10900k and gigabyte z490 aorus ultra.
Normally I would say that going from 4400mhz 19CL to 3900mhz 15CL is super good but my bandwith in aida benchmark is super super bad - only around 40 GB/s (latency around 43ns). If I jump to 4000 mhz (unfortunately cannot get stability, whatever I do) I have the expected 57 GB/s. So just 100 mhz difference is around 17 GB/s higher. What could cause it? So far it seems like my PC isn't happy with speed below 4000mhz and something is bottlenecking here... And 40GB/s bandwith I should have on something like maybe 2900 mhz, not 3900 mhz.
I would really appreciate your help, it gets me crazy...

tWR and tRTP does not provide much of performance uplift so we could have ignored them and left them to the end, but!! lower tRTP could mean lower tRAS and here where is the performance uplift comes from that's why these timings really matters especially for micron rev E ones. Micron can do very low tRP, tRAS, tRTP, tWTRS and tWTRL compared to other types of memory chips so spending some time on lowering tWR totally worth it rather than leaving it to the end. The order should be like this:
tRP >> tWR >> tRTP >> tRAS >> tRC.
I Think the best results would be achieved with this order.

Originally posted by @IslamGhunym in #55 (comment)

The software named "Thaiphoon Burner" linked in DDR4 OC Guide.md resides on a website flagged as "contains trojan" by Malwarebytes, and does seem to actually contain malware.

Trojan also found in TM5 and y-cruncher

If this isn't some kind of IQ test, I would very strongly suggest not recommending users to install this.

memtesthelper is broken as of windows 1903 v2
microsoft updated windows 1903 to 1903 v2 last week which included all the updates between v1 and v2
so presumably one of the windows updates on the tail end caused memtesthelper to break
Memtesthelper doesn't automatically minimize all the instances of memtest, and it also doesn't track coverage / speed and automatically stop memtest when an error is detected
In order to have the memtests actually start, you would have to manually close all the pop up boxes
It's like it doesn't detect the instances at all
And can't act upon any of the instances

Screenshot

Removes 16-20-20-40 timing suggestion for <= 3200 MT/s since all ICs should be fine with 18-22-22-44 as a starting point. Saves time when starting out to find the maximum frequency.

See #83

I think that in the IMC section table header for second column should be "VCCIO/VCCSA (V)" instead of "VCCSA/VCCIO (V)".

there is no MFR and some others in the guide.
Unfortunately, for happy circumstances, I became the owner of such a wonderful memory.

found information for myself here.
https://community.hwbot.org/topic/147255-guide-skylake-memory-timings-on-asus-motherboards/

I wanted to share my findings here so it can hopefully be useful.
The memory OC I was doing was on ASUS B450M-A with 3400G APU and 2 x 8 GB DDR4 micron Rev E single rank dual channel.
Anyway, I read the guide countless times really and spent months messing with timings and frequencies. The maximum achieveable with my samples was 3466. I was not able to stabilise the 3533.. tried everything really including resistance. However the graphic unit was crashing bellow 1.25v SOC at 3466. each a frequency step I went over 2933 required a higher SOC voltage in order not to crash on 3D applications. I have seen no negative scaling with higher SOC voltage up to 1.35v which is something nice. However over 1.45v DRAM voltage I started to see no better results because I was clearly limited by the picasso IMC in everything. a 3533 however will require higher than 1.25v SOC which will put me into unsafe voltage range considering PBO was enabled and may push SOC voltage as high as 1.32V in some rare cases. So 3466 was my limit here.
I was able to run 14 tCL and no lower than that at 3333, 3400 and 3466. The same story goes for tRCD and tRP and other timings as well was not effected by higher frequency on 1.45v except tRC and tRFC

Anyway, what I wanted to add is this:

I was able to run tRP as low as 11 and it scales with voltage even tho in your guide for Rev E chips, it is written that it does not scale with higher voltage, but when I followed the order in your guide about timings tRP was not stable bellow 18 = tRCD which looks like it does not scale with voltage just like tRCD. I tried a different order of tightening timings (the same order I did previously) than the order in your guide and I was able to go as low as 11 for tRP. tRCD however was the same can't be lower than 18.

So why I had different findings?
The thing is tRP, tRAS, tRTP, tWR and tRC have relations.
Running lower tWR made lower tRTP stable.
Tightening tRTP and tWR before tRP made tRP unable to run bellow 18 and benchmarks showed a clear drop in the read and write bandwidth and 2 more ns latency, but when I tightened tRP first I could go as low as 11, but that required higher tRTP, but there was a real performance difference. Well tRP is a major timing of course so having it lower shall do better.

So what I wanted to say maybe the order this way would give better results:
tRP >> tWR >> tRTP >> tRAS >> tRC.
Of course I am not better than any of you to explain why, but this is what my experiment have shown so hopefully it can be useful.

After run test MemTestHelper dialog will disappear.

memtesthelper.log contains only 4 lines:
2020-01-03 19:24:16.2291|INFO|MemTestHelper2.MainWindow|Starting... 2020-01-03 19:24:16.2291|INFO|MemTestHelper2.MainWindow|Selected threads: 12 2020-01-03 19:24:16.2291|INFO|MemTestHelper2.MainWindow|Input RAM: 24576 2020-01-03 19:24:16.2291|INFO|MemTestHelper2.MainWindow|Available RAM: 28350MB

Have Access Denied error when I am trying to open DDR4 OC Rankings from here. Tried to open this with two accounts. Don't know if it should be so.

w10 x64 1909 18363.449
hci 6.4
helper 2.1.0

memtesthelper.log

Originally posted by @Chicos123 in #4 (comment)

• On Alder Lake CPUs, tRD and tRP are no longer linked

Hello, first of all thanks for the awesome writeup, I'm hoping this question reaches one of the contributors.

In the tightening timings section, the following is written:

I would recommend to tighten some of the secondary timings first, as they can speed up memory testing.

As a beginner in memory overclocking, this confuses me a bit. Since the primary timings have the highest impact on performance, wouldn't it be more efficient to tighten those first? This may well be a false assumption but, isn't there a chance that when one of the secondaries gets tighter, one or more of the primaries becomes harder (e.g. requiring more voltage or less frequency) or outright impossible to tighten further?

Thanks in advance for any insight on this matter.

Is it possible to have a similar document with DDR5 info, I think the stuff here is amazing it would be great to have a version for ddr5.

if you're testing very close to free ram size
helper getting crash .. 😢

Hi
This guide doesn't mention anything about SoC Loadline Level Calibration, especially on Zen3. I'm newbie to overclocking, what it actually does, does it matter and should I touch this or just leave on auto?

asrtc 4.0.10 dead, i suggest replacing with https://web.archive.org/web/20211010085116/http://picx.xfastest.com/nickshih/asrock/AsrTCSetup(v4.0.10).rar
astrc 4.0.13 also dead, not sure if this https://filehorst.de/download.php?file=ecporlpy as found here https://www.overclock.net/threads/official-intel-z690-z790-ddr4-daily-memory-overclock.1794799/ is legit

Since HCI Memtest is still one of the best RAM testing programs, I'd like to use your tool or something like it.

1. Why is there a 2GB limit in MTHelper (in the case I want fewer threads), even though I can run Memtest standalone with 3GB and it seems to work fine?
2. Is there a link to Memtest 6.4 before it was modified? Is it even needed? I have 5.0 and it seems to work just fine (DDR4 on Z490). It found errors even a bit faster than 6.3 and 7.0, but maybe that was just coincidence.
3. Is there a way to prevent opening of the browser/link when an error is found? If not that would be nice to have.

Like I said in the title, when I start the test, memtesthelper opens all the MemTest threads and starts them but then the memtesthelper just closes itself.

TestMem5 seems to try to display a foreign language (Russian?) in its UI. I recognize it because during multiplayer in game I used to play, if a Russian player typed in chat, it showed exactly the same characters. It had something to do with the game only supporting one alphabet, so the Russian release came with a different alphabet than most other international releases. Maybe it's something different here, but the similarity is too striking to ignore. I'm talking about TestMem5's statements like

Îøèéêà â òåñòå 13 ÷åđåç .

They don't appear in the log file along with the messages like "Error in test #13 through 1:55.06", but perhaps they are supposed to be the same error message...? I'm not sure. The other odd thing is that if that is the case, some of them would show an error in 'test 0'. I suppose that maybe this issue could be related to memory instability somehow, but in that case it is very consistent in its inconsistency, which to me seems dubious.

Anyway, here's the full log it generated after completed the 8-hour test:

========= TestMem5 Log File =========
Customize: Extreme1 (32GB) - 8h overnight @anta777
Start testing at 0:53, 1.6Gb x16
Error in test #13 through 1:55.06.
Error in test #11 through 2:01.24.
Error in test #13 through 3:39.58.
Error in test #13 through 4:07.34.
Error in test #13 through 6:28.26.
Error in test #13 through 7:17.53.
Testing is completed through 8:57.11,
detected 115 error(s).

And the full list of statements displayed in TestMem5's UI:

Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 14 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 15 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Error in test #13 through 1:55.06.
Error in test #11 through 2:01.24.
Îøèéêà â òåñòå 2 ÷åđåç .
Îøèéêà â òåñòå 15 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 0 ÷åđåç .
Îøèéêà â òåñòå 0 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 2 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 0 ÷åđåç .
Îøèéêà â òåñòå 0 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 15 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 0 ÷åđåç .
Îøèéêà â òåñòå 12 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Error in test #13 through 3:39.58.
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 2 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 12 ÷åđåç .
Error in test #13 through 4:07.34.
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 0 ÷åđåç .
Îøèéêà â òåñòå 14 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 2 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 15 ÷åđåç .
Îøèéêà â òåñòå 15 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 12 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Error in test #13 through 6:28.26.
Îøèéêà â òåñòå 14 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 10 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 0 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Error in test #13 through 7:17.53.
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 15 ÷åđåç .
Îøèéêà â òåñòå 15 ÷åđåç .
Îøèéêà â òåñòå 0 ÷åđåç .
Îøèéêà â òåñòå 7 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 8 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 13 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 2 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Îøèéêà â òåñòå 15 ÷åđåç .
Îøèéêà â òåñòå 6 ÷åđåç .
Îøèéêà â òåñòå 5 ÷åđåç .
Îøèéêà â òåñòå 11 ÷åđåç .
Tested is completed through 8:57.11, detected 115 error(s).

Maybe this is helpful to fix the issue, or maybe it's not worth looking into, but I figured I'd share this just in case.

Even though MemTestHelper crashes (or is crashed..) the basic fuction of opening the instances of MemTest with correct amount of RAM still works, right? We just lose the nice overview it gave us?

Also, just wondering .. shouldn't the last instance use "all unused ram" ?

Hi
I got very far with this guide, but I can't get stable GDM OFF.

https://www.overclock.net/threads/official-amd-ryzen-ddr4-24-7-memory-stability-thread.1628751/post-29200766

More info and my current stable setup

I quote:

On Intel, tWTRS/L should be left on auto and controlled with tWRRD_dg/sg respectively. Dropping tWRRD_dg by 1 will drop tWTRS by 1. Likewise with tWRRD_sg. Once they're as low as you can go, manually set tWTRS/L.

Ok understood; but what does this mean: "Once they're as low as you can go, manually set tWTRS/L.`"
Because you give suggested timings for tWTRS/L; does this mean I should drop tWRRD_dg/sg until tWTRS/L reaches the suggested timings per your sheet? And then set them again manually, to be sure? Because if I drop my tWRRD_dg/sg by 1 on my kit, I've already reached tWTRS/L as per suggested "Tight" timings.

Or do I manually set the tWTRS/L timings and then try to "go as low as I can" with tWRRD_dg/sg?

Greetings,
Merlin

As soon as I started the test the program crash but the test work just fine. tried to change "start minimize" but it doesnt work.

Server mod here and I'd like to chime in on a few dead links apart from the ones in #62.

Note: Thaiphoon is known to guess ICs, so it shouldn't be fully trusted. It's highly recommended to check the label on the sticks if possible.
See here for more info.

dead, looked around no backups

G.Skill 042 Code
Similar to Corsair, G.Skill uses a 042 code to indicate the ICs.
Example: 04213X8810B
The first bolded character is the density. 4 for 4 Gb, 8 for 8 Gb, and S for 16 Gb.
The second bolded number is the manufacturer. 1 for Samsung, 2 for Hynix, 3 for Micron, 4 for PSC (powerchip), 5 for Nanya, and 9 for JHICC.
The last character is the revision.
This is the code for Samsung 8 Gb B-die.
See the r/overclocking wiki for a full list.

wrong navigation (I was the one who made the breaking change a couple years ago 😅 and deleted my Reddit acc since), should be this

For Asus Maximus boards:
Play around with the Maximus Tweak Modes; sometimes, one will post where the other does not.
You can enable Round Trip Latency under Memory Training Algorithms to let the board attempt to train RTL and IOL values.
If you can't boot, you can try tweaking the skew control values.
More info here.

forums broken, no content loaded, archive.org copies are barely better (text only)

On Ryzen 3000 and 5000, 1usmus suggests 28Ω - 40Ω. Lower settings may be harder to run but potentially helps with voltage requirements.

dead

This value is not to exceed 1.10V on Ryzen 3000 and 5000, and should always be restricted to at least 0.10V less than DRAM Voltage.
Source: AMD

dead, archive avail

Impact of RAM on Intel's Skylake desktop architecture by KingFaris moved, should be this
Intel Memory Overclocking Quick Reference by sdch dead, archive avail
The road to overclocking memory without increasing voltage by Raja@ASUS broken, see above

Hello, a few months ago I said that Gigabyte didn't allow different values for tRCD and tRP on their 600 series intel boards. It was added into line 352 in this guide. On Alder Lake CPUs, tRD and tRP are no longer linked as long as you are not using a Gigabyte motherboard.

I can confirm that, after some messaging back and forward with their support team, they added the capability into the new BIOS version. I have used the F22 BIOS and it does let me use different values and it will train with them.

Currently, tCWL depends on tCL as the following is stated:

The problem is that tCL is changed after tCWL is tuned. Then there is no mention of tuning tCWL again. To fix this, we can simply tune tCL before tCWL but i'm not sure if that will have a negative outcome.

I'm open to discussion. What do you think of this solution?

For AMD, run Prime95 Large FFTs and OCCT VRAM with max utilization simultaneously to stress the FCLK and ensure FCLK stability. This should be run after any frequency/FCLK change.

This is not clear to me.

Does this mean

Does this mean I am suppose to stress my... GPU?

From this sentence I interpret this in the following ways

1. Literally -> run a vram (gpu) stress (this seems like the incorrect thing to do for a system memory overclock)
2. Run prime95 large FFT and OCCT Memory -> This gives a OOM since prime95 is programmed to use all the memory it can and wont complete
3. Like 2. but set OCCT to 45% memory and prime95 to 45% memory (copy data from large fft but change memory)

Could this language be cleared up?

Possible fixation

For AMD, run Prime95 Large FFTs and OCCT VRAM (stressing GPU memory will stress infinity fabric) with max utilization simultaneously to stress the FCLK and ensure FCLK stability. This should be run after any frequency/FCLK change.

Please feel free to close this issue after making a note that I should have interpreted this literally if that is the case, however its interesting that a user is expected to stress a gpu for stressing memory coupling

I keep getting this error no matter what value I do as input. 1, 3, 8, 200, 16000, 16384, 2048, 4096 - I've tried all these values and every single one gives me this error.

Any ideas? This tool is completely unusable at the moment.

If user has tightened their RTL/IOLs, at times (especially after a bad crash or a power outage), the motherboard can simply fail to POST. If this happens, reset the RTL/IOLs back to Auto, save and let the motherboard properly POST to train, and then tighten the RTL/IOLs again.

On 12th Gen Intel, RTL/IOL might not be tweakable on certain motherboards (e.g. ASUS) or BIOS versions. Moreover, for this new generation, VCCIO is no longer available and has largely been "replaced" by VDDQ instead, which is a voltage that also has a sweet spot effect, but it tends to be at values much higher than before (instead of the average being in the 1.20-1.30V range like VCCIO was, expect to try values even up to 1.40-1.50V to gain stability and properly boot).

Starting from 11th Gen Intels, a new Gear mode has been introduced (more info here). It is similar to AMD's FCLK. Gear 1 is much faster than Gear 2 as it is 1:1 for the frequencies. However, it does softcap the max frequency of RAM to the low-mid 4,000 MHz range (currently), so Gear 2 may still be needed for extremely high frequencies. Furthermore, with 12th Gen Intels, a Command Rate of 1 is now a lot easier to achieve compared to previous generations, so it is advisable for people to retry CR1 (1T, N1, etc) if they have failed to achieve it before.

On 12th Gen Intels, due to optimizations with the CPU and IMC, you can often achieve the same timings you've achieved before, but potentially at a lower VDIMM while also having more headroom for pushing the overclock further (e.g. frequency). Also, unlike previous gen Intels where tightened Samsung B-die kits tend to be in the 30-40ns range for latency on AIDA64, on 12th Gen Intels, it can result in higher latencies (40-60ns) due to architecture differences. This is normal.

Side notes:

• tWR of 10 or lower may result in worse performance compared to higher values on certain kits of RAM; test to make sure there is an improvement.
• tCKE can be dropped all the way to 0 on some kits.
• Overclocking the BCLK on Intel can raise RAM frequency even further, but keep in mind that it does affect the core and cache clocks as well. (Note: AIDA64 has a bug with BCLK overclocking where it can report unrealistically high RWC values if the BCLK is too high.)

Some useful websites:
Zen Overclocking Leaderboards - Very useful for AMD users to see reference timings, voltages, as well as BIOS and AGESA versions for different motherboards to try
Ryzen Calculator with TM5 Error Diagnosis - Spreadsheet-based calculator that's maintained by Veii and some other people. Very useful reference for diagnosing TM5 error codes.
Updated BSOD Error Code Reference - Better version of the BSOD error code reference that covers a lot more codes in further clarity. Significantly helps in diagnosing issues with relation to overclocking.

Cheers :)

Hello, I'm an Intel user and I've been running my b-die kit at 18-17-17-38 for a few days until I realized "what if I first set tCWL to an even number because maybe MAYBE my mobo was setting it to an odd number and that's what caused instability".
So now I am at c15 which is WAY better. I followed each step but I think this is very important to do to find a baseline.
Something like:
On Intel:

• Set tCWL = tCAS or +1 to make it even. Using odd tCWL may cause instability.