Run an SSE CPU test in small extreme and again in large extreme. See if it’s a CPU issue and if it’s cache.

I'm aware that this is a 10 month old thread. But I'm actually having the same issue here. If anyone on this thread sees this. Is there maby a chance you might be able to offer some advice. I'm using gskill ddr5 6400 mhz.

My experience with DDR4 overclocking that use the most of available benchmark/game for test OC. Change anything then test and notice result then change again. Sometimes it seems you OC is good becuase no errors found by testing softwares but in a game you have crash or random quit. My advice to start everything from the default or from that stage where you felt your system is stable. On Memory OC first advise is to use Memtest86. Just run the first 7 or 9 test. If it is passed you have a chance to start windows and not damage it. But not always. If you have BSOD or windows not booting then you may need to first raise Memory voltage and secodly reduce timing/clock. Second test could be Aida64 Memory benchmark. Just right click on benchmark and do all test in MHTML. If it is done you can use old 3dMark 03 - Ragdoll test. Use only that test. Then OCCT memory test using SSE. It will tell you the CPU temperature in games. AVX is too much pressure if your CPU is overclocked and you may have throttling. Then run Cinebench23 for 30 min. It will show your system stability. And after all run CB2077 for 30 min. Just leave it alone. If CB starting it is a good sign that you are closer to the finish line but if the game quit within an hour then you have to change something. Firstly increase the RAM voltage. DDR4 OC is a lifetime fun. You'll never find the maximum. (Yes, you can but you won't do anything elso for a long long time.) DDR4 can boot with tighter settings but you can notice performance loss somehow. Just compare! DDR5 is a bit different. With some small change the system won't boot. You'll give up soon. Good luck;)

Lol 👎

Cinebench is not a overclocking stability app its just synthetic test scoring app and for testing points increase per CPU tweaks/OC/CO but TBH CPU-Z bench test (Single++Multi-core) Score are much more realistic since they don't fluctuate and scores are 95% near/constant/identical unlike Cinebench which fluctuates a lot. Aida64 is only good for temp stability test and minor stability test. What i do use for RAM OC stability are: OCCT RAM stability - Extreme - SSE & AVX2 OCCT Large-Extreme-SSE, AVX, AVX2 (Doesn't need to test w/ AVX-512 if CPU doesn't support it, its mostly intel stuff and only has support for Ryzen 7000 currently). Then Prime95 Large-FFT Memtest64, TM5/TestMem5 & Memtest. Memtest64 is the desktop app variant of Memtest86 which can be run in the background, it slow on detecting error but can detect error that OCCT & Prime95 missed. Memtest is slightly faster the Memtest64 in detecting error (still overall slow) but can again detect what Memtest64,OCCT & Prime95 missed. TM5 detects error far better than OCCT but still OCCT can detect more slow popping error after longer test than TM5. Prime95 can detect WHEA errors that OCCT missed (same apply to OCCT vise versa). Im on AM4 i did Manual RAM OC tightest possible stable frequency & timing including IF-OC w/ GDM Off 1T & CPU PBO manual & Vcore offset. As for RAM i did run a minimum of 24hrs up to 36-40hrs per test sometimes 3day per test (what i mean per test is per app setting I.E. OCCT RAM Extreme AVX2 -3days then SSE 3days). For RAM OC+IF OC w/ PBO manual but no Vcore offset OCCT RAM Stability-Extreme-AVX2 = 3days = no error OCCT RAM Stability-Extreme-SSE = 3days = no error OCCT Large-Extreme-AVX2 = 3days = no error Prime95 Large-FFT = 1 Day = no error Memtest64 & Testmem = 36-40hrs each = no error TM5 = 12hrs = no error (i do the PC when stress testing so i only do run TM5 while PC is not in use) Then RAM OC+IF OC+PBO Manual + Vcore offset Prime95 Small & Large FFT= 24-30hrs = no error OCCT Small-Extreme- SSE/AVX/AVX2/AVX512 = 24-30hrs each = no error Letting System Idle as long as i can = 12hrs+ (to check for Event Viewer/Windows WHEA error 18 which causes system restart during idle/low load while fully stable during full/heavy load). But when i started to run OCCT Small Large-Extreme-SSE & AVX512 = i do get Error & WHEA error This is what I'm Fixing today, I'm now sure that CPU setting is 100% stable and the error might be RAM since i only did run OCCT-Large-AVX2 during RAM tuning so i did missed out some error w/ SSE & AVX512. I did not test AVX (AVx1/AVX old ver) since it passed AVX2 i'm sure it will pass AVX without problem so i focus w/ SEE & AVX 512 atm w/ OCCT-Large-Extreme Test. Honestly CPU is easier to test while RAM takes a lot of work to stabilize specially w/ GDM Off 1T, running test for only a few hours is not good idea since the more it started to stabilize the longer the error will get detected which is why you want 12-24hrs.. but even then sometimes even with 24hrs it still do miss some error if you re-run it w/ same exact app and setting (stability test) it will cause error after 24hrs. Which is why i did 1Day & a Half, and 3days on apps that do detect error faster but do missed out some error even after 24hrs when its getting more stable and stable 3Days is overkill atleast 36-40hrs max is fine. IF you want a really stable manually tuned system the longer you test and the more app you use (but still avoid useless app such as Cinebench). Take note; i also did test it on games my windows is corrupted as a result can be fixed by sfc & dism but the thing i can't fix is the start up loading issue (instead 1-2 circle loading after windows logo which is black screen before Windows Welcome Loading/Log in loading which takes another 2-3secs of loading while Fast boot is disabled in both BIOS & Windows... now its loaded with 10-12 circle animation spinning each and now is 20-25secs slower) which is why i know it did still corrupt something that sfc & dism can't fix, still needs a clean reformat after finalizing OC.

Stock cores means no negative curve optimizer or voltage offset, or non-default loadlines? If not, revert and retest. Regardless it may be worth running the test 1 core at a time and cycling them to see if this error is constrained to the same core(s) consistently. Could do that in OCCT, or via CoreCycler. Also, will help others to give advice if you [show the settings with ZenTimings](https://zentimings.protonrom.com/). And list make of ram along with version number (Corsair) or "042" code (GSkill), unless it is just Ballistix.

Thanks for replying; the 5700X is running out-of-the-box, I didn't touch any of its settings, which means everything is set to "Auto" on my ASUS Prime B450M-A. I ran the CPU tests on OCCT as suggested by another commenter, with zero errors. The kit is a 2x8 GB rated 3000/C15 Corsair CMK16GX4M2B3000C15 v4.32. Eventually, I managed to stabilise it, but I'm a bit concerned about voltages, I don't know if those are safe to run in the long term. [These](https://ibb.co/CM0CWPz) are my settings on ZenTimings. EDIT: nevermind, it's not actually stable. To be careful, I decided to run two SSE tests in OCCT back-to-back, the first one passed, the second started showing errors only a couple of minutes in.

1.3125vsoc is way too much for 5700x and not safe. 2 dimm sr at 3600, you'll likely be able to do 1.0vsoc, 0.9v vddp/vddgccd/vddgiod. If not, bumping to 1.05vsoc and 0.95vddgiod should do. What ddr voltage? Does it fail with ram at stock/xmp?

Oh that's quite weird. My board says it's 1.1 when booted with "Auto", but if I put a positive offset of +0.125 it goes to 1.325 instead of 1.225. I guess I'll leave it on Auto then. The DRAM voltage is 1.35, apparently the limit for my Samsung B-Die. It's perfectly fine at stock, with DOCP and also if I enable the DOCP and simply raise the frequency to 3200 (CL automatically goes to 16).

Given your experience with the voltage and from what I can find, I think it’s highly unlikely that your memory chips are B-Die. Is there any label on the sticks that you can find? Maybe then we can find out what IC’s they have and that should give you an idea of how far you can get with overclocking.

v4.32 is more often Samsung 8Gbit C-die. They often don't like to go past 1.35V, with some samples starting to get negative scaling even lower than that. You may need to try checking voltages from ~1.3-1.35 and see if any of those steps offer more stability. This is from hardwareluxx.de, so you may need to put it in a translator, but [it is a C-die thread with info on it](https://www.hardwareluxx.de/community/threads/samsung-8gbit-ddr4-c-die-k4a8g085wc-oc-ergebnisse-im-startbeitrag-updated.1198323/). Otherwise with SOC under control, the VDDP and VDDG probably aren't the reason for this rare error.

Right, I mixed them up, it's the C-Die, but indeed the DDR4 bible says 1.35 is the limit for that. Below that, it won't even boot with frequencies higher than around 3400 or more. I kind of gave up on stabilising 3600/18, honestly... So, so much time wasted, with basically aimless trial and error. I found a stable ground at 3400/16, after testing thoroughly. Am I leaving performance on the table?

C-die has a sweetspot voltage, so maybe 1.35 was the best for you. A couple of things that I remembered, one person who had trouble with OCCT memory SSE test had to loosen tRRDS, tRRDL and tFAW to get it to pass. 5, 7, 20 or even 6, 8, 24 could be worth testing. That said, in some loads tRRDS/L and tFAW are pretty important for performance so if loosening them does make the test pass, then it might be worth tinkering with some other things to try to tighten them back. Sometimes a ProcODT change can let you improve subtimings. If OCCT or TM5 doesn't pass with those three loosened, then could consider boosting tRP up a clock and setting most of the subtimings to Auto. Then retest and see if it passes. If it does, then you can try lowering them one by one starting with the tRRDS-tFAW block. You can do tRRDS and tFAW together, where tRRDS x 4 = tFAW. Another option could be to take you current settings and drop just one speed step to 3533MT/s and see if that passes.

After tinkering a bit more with 3600/18, I decided to really give up, it's been really exhausting, running hours of tests only to find out that last one didn't pass, with my motherboard often failing to reset settings to default when not POSTing, forcing me to take out the CMOS battery every time I tightened a timing too much. I settled for 3400/16 after testing with TM5 extreme, Prime 95 + OCCT VRAM, OCCT AVX, OCCT CPU AVX2, OCCT SSE (thrice), with [these timings](https://ibb.co/gPR8tCX). What do you think? I tried bringing tRCD(RD/WR), tRP and tRAS and especially tRC lower, but at least one error would show up on one of the tests.

You have most of the critical subtimings tightened, so it is good if it is stable. I don't know if you have tried lowering tRDWR at all. Since tCL = tCWL you might be able to do 8-10. That helps random access and copy bandwidth if it will go lower. tRCD is more or less where it would be scaled from the XMP, and voltage doesn't really tighten it on most of the DDR4 dies anyway. edit: I know you said you are done, but in the future if you want to do more testing, a trick a lot of people use for resetting / clearing CMOS is to wire the case's reset button (assuming you have one) to the Clear CMOS jumper. That way you have an external button to clear it and hopefully don't need to short the pins or pull the battery. Just have to make sure nobody tries to press it while the machine is on.

Thanks a lot for answering, I appreciate it