2x32GB RAM at 6400mhz with CL30 stability is recommended.
2x32GB RAM at 6400mhz with CL30 stability is recommended.
I'm working with a G.Skill Flare X5 kit featuring 2x32GB RAM at 6000Mhz CL30. My goal is to push it up to 6400Mhz or even CL28. I used the Expo Profile and made several custom adjustments: speed set to 6400Mhz, DIV1 mode configured with UCLK=MEMCLK, main timings 30-38-36-40, tREFI at 65535, ARdPtrInitVal P0 at 2 (based on Buildzoid's similar setup), VDD at 1.42V, SOC at 1.25V, MCR and PowerDown enabled. For the CPU, I applied a -30 offset across all curves, set PBO limits to match motherboard and platform thermal caps, raised max boost by 100Mhz, and set FCLK to 2133. I'm using RAM OC with OC enabled but haven't stress tested the CPU yet. It failed a single test at the one-hour mark with two errors. Should I keep OC stock while testing RAM OC, or run a CPU stress test first? What adjustments should I focus on next for stability? If stable, what CL28 target would be realistic? Thanks!
Curve optimizer sometimes causes issues during memory stress tests. If the problem persists, try increasing to 1.3V SOC; otherwise, you may not be using a chip capable of 6400MT/s. Prioritize achieving at least 4+ hours of operation in Karhu and Y-Cruncher VT3 before considering further adjustments.
I'm conducting another Karhu trial with more precise clock speeds. I lowered the DRAM VDD to 1.4V and raised SOC to 1.26V. It stayed stable for an hour without errors, so I activated those options and ran it again. I'm unsure if it's fully stable now but it lasted 30 minutes past my last test without issues. I borrowed timing specs from another source with a similar RAM (same maker and specs, but a Trident Z5 instead of my Flare X5). That version had tRFC/tRFC2/tRFCsb at 472/256/208, which reminded me of a Buildzoid video about M dies not posting at 400. I think theirs is probably an A die, while mine is M. I returned to the values my motherboard set and ran this test once more, but I'm hoping for updated settings. I'll be testing Y-Cruncher VT3 next.
Checking if your TREFI remains stable at 65535 during high heat (54-56°C per stick) seems reasonable. Since Karhu isn't flagging issues, setting it near those temperatures could be a solid choice. It’s a safe bet to stick around that range.
This setup seems accurate. I've previously used M-die on AM5 before; it only becomes problematic around 550 cycles before issues arise (specific numbers vary by controller). To save time, focus on tRFC timing only—tRFC2 and tRFCsb aren't supported on that controller. There are just two points where dual rank differs from single rank: the DR/DD timings. I haven't tried dual rank M die on AM5, but with A dies, the main difference is the inability to run high-speed operations in Gear 2 at dual rank as you can with single rank. From a testing perspective, I prefer running Furmark in the background for tREFI so you stress-test both RAM and memory simultaneously. That said, 65535 typically holds up until about 70°C on Intel systems (my test), so 54-56 should be safe.
It seems unusual that posts aren't appearing even after setting the tRFC value to 600. I'm searching for the most relaxed M die timings possible for a 2x32GB system with 6400 CL at 30°C, but nothing seems to work. I often have to recharge my CMOS battery to access the BIOS and adjust settings. The system feels stable at certain temperatures, yet I'm weighing whether to keep all timings except tREF in auto mode. It appears my 9700X is capable of handling those settings, but a subpar RAM module might struggle with tighter timings even on capable hardware.
This situation seems unusual based on my background, but I haven't encountered M die issues at that speed on AM5 before. It might be that your die doesn't fully comply with TFRC 600, so try setting it to 650 and see if it works. Test one timing at a time to identify which ones cause boot failures—check if adjusting one timing improves stability. If tightening further causes instability, lower the speed to 6200 and retry, as tighter timing will help compensate for the lost performance.
I was planning to test these configurations, but I encountered a BSOD during a game. Initially, I thought it was due to my CPU's PBO-30 setting and 100MHz boost, which made me suspect memory instability. After checking with Prime 95 Large FFT, I noticed worker failures and BSODs whenever I reduced the offset. I then disabled CO/boost override, retested, and almost immediately got a BSOD with the code "MEMORY_MANAGENENT." Eventually, I switched to the default Expo profile, lowered FCLK to 2000, re-enabled -30 CO/+100MHz boost. Although not yet conclusive, I've managed 35 minutes without failures in this P95 test—about 30 minutes longer than before. This suggests my RAM OC wasn't as reliable as I believed. Running Karhu for two hours without issues supports this, though I think instability arises when CPU and RAM are stressed together. I’d like to try increasing the RAM clock to 6400MHz, but I’m unsure how much to adjust. Raising the SOC voltage or VDD seems reasonable, though I’m cautious about pushing SOC too high. The VDD was increased to 1.45V, but it didn’t help much. Buildzoid achieved 6400MHz with similar settings at 1.22V SOC on a nearly identical build.
You're aiming for a more modest primary selection, so unless you've hit a tough spot with your components, it's likely the timing isn't the main problem. Big FFT operations usually put a heavy load on the memory controller, so raising the SOC voltage to 1.3V might help. Try jumping straight up to that voltage and check performance. If that fails, lower the FCLK frequency first to avoid simultaneous overclocking, then consider reducing the memory speed to 6200MT/s.