Before I start, I highly doubt this guide is perfect in every way, but I'm pretty confident I've done a decent job with what I've learned so far. For the experienced tuners out there, if you spot any mistakes or have something useful to add that I may have missed, please let me know so I can correct or improve the guide.
This guide is mainly aimed at people who are new to memory overclocking. I've tried to explain things in a way that's easy to understand without leaving out the important details.
Please have mercy on me lol.
Now, onto the guide.
I wanted to put this together as a companion to my AM4 and AM5 undervolting guide:
https://www.reddit.com/r/overclocking/s/A28wAr4VCX
Example pictures, test setups and troubleshooting screenshots:
https://postimg.cc/gallery/6G8gvnr
For full image quality, open the gallery, select a picture, then tap the picture again or use the zoom button. The smaller previews can make the timings and test results look blurry. These pictures show different stages of testing, not one profile to copy from start to finish.
The headline picture shows my personal tune, not a set of starting settings. The album includes older settings and different tests, so don't mix values from different pictures into one profile.
Memory tuning can look overwhelming when you first open the BIOS. There are plenty of screenshots showing finished settings without explaining how someone got there.
This guide explains the process, what the settings do, and how to work out whether a change actually helped. It is mainly for beginners, with some extra detail for people who already tune.
The frequency examples are aimed at desktop ryzen 7000 and 9000 systems. AM5 APUs can behave differently, so don't assume every example applies to them. You don't need the lowest timings or the highest frequency to have a good tune. You need settings that perform well, survive your actual use, and have some room for warmer days.
You don't need a high end kit to follow along. Start from settings your own hardware can handle, even if that means a lower frequency than the examples here.
Overclocking is done at your own risk. Unstable RAM can corrupt data, and excessive voltage can damage hardware. Back up anything important and learn how to recover your BIOS before starting. A successful stress test cannot guarantee hardware lifespan.
《About the headline picture》
Please don't copy my Zentimings settings as a starting point. This is my personal tuned 64 GB dual rank SK hynix A die kit. I used dedicated active RAM cooling, meaning a fan blowing directly over the sticks, while pushing voltage and refresh timings. That cooling is part of the setup behind the picture. It helps control heat, but doesn't make high voltage safe or mean another kit will handle the same settings. This is a warning about my aggressive tune, not a requirement to buy a RAM fan before starting. The refresh mode and other BIOS choices shown aren't universal recommendations either.
《1. What the names mean》
DRAM or RAM: The memory modules installed in the motherboard. A DIMM is one memory stick.
IC or die: The actual memory chips on those modules. The manufacturer, density and revision affect how they tune. A die name identifies a particular chip design, not the brand printed on the heat spreader.
IMC: Integrated memory controller, inside the CPU. It handles communication with the RAM.
MCLK: The memory clock. DDR5-6000 runs at 3000 MHz MCLK.
UCLK: The memory controller clock.
FCLK: The infinity fabric clock. It is separate from MCLK and UCLK on the desktop chiplet CPUs covered here.
MT/s: Transfers per second, in millions. This is what the 6000 in DDR5-6000 describes.
Timing: A delay or spacing between memory operations, usually measured in memory clock cycles.
Training: The process the BIOS uses to find workable settings for communication between the CPU and RAM. This is one reason a first boot after a change can take longer.
JEDEC: The standards behind the memory's normal default settings. In this guide, starting at JEDEC means using those defaults rather than an EXPO, XMP or manual overclock.
EXPO or XMP: A saved profile containing the memory manufacturer's tested settings. It is still an overclock when it goes beyond the CPU's supported specification.
CO: curve optimizer, which adjusts the CPU's voltage and frequency curve. It is a CPU setting, not a RAM voltage setting.
A useful way to follow the guide is baseline first, frequency and controller next, then FCLK, timings, refresh and final testing. The advanced ohm section is optional. You don't need to change every setting to improve your memory.
When this guide says 1:1, it means UCLK equals MCLK. It doesn't mean FCLK needs to match them.
For example, DDR5-6000 can run MCLK 3000, UCLK 3000 and FCLK 2000. At DDR5-6200, 1:1 means MCLK 3100 and UCLK 3100. In the divided mode, UCLK runs at half MCLK. Check the actual clocks after booting because auto can change the ratio.
A timing number only makes sense alongside the frequency. To convert a timing from cycles to nanoseconds, multiply it by 2000 and divide by the DDR data rate. CL30 at 6000 and CL32 at 6400 both work out to 10 ns. That only compares the CAS delay. It doesn't mean both systems have the same overall latency or performance.
《2. Identify your RAM and its limits》
Before copying settings, find out what you have. Record the exact kit part number, module revision, capacity, number of sticks, rated profile, chip manufacturer and rank arrangement. CPUZ's SPD page and a current version of Zentimings can help. They won't always tell you the exact die, so don't treat a manufacturer name as a confirmed die identification.
The brand on the heat spreader isn't necessarily the company that made the chips. corsair, g.skill and kingston sell modules using different ICs. Even the same product family can change chips between revisions.
Single rank and dual rank describe how a stick is organized. Dual channel describes the memory channels being used. Two sticks don't automatically mean dual rank, and capacity alone doesn't tell you the rank count. Newer, denser chips can change that.
More ranks and more populated slots change the load on the memory controller and the signals between it and the RAM. Two dual rank sticks or four sticks can have a different, often lower, frequency limit than two single rank sticks. Use the slots recommended in your motherboard manual, usually A2 and B2 for two sticks. Two separately purchased kits aren't a matched four stick kit, even if the labels look the same.
The die names aren't interchangeable
Sk hynix 16 Gbit A die: Commonly used for DDR5 tuning and capable of strong frequency and timing results. Your CPU, board and rank arrangement still affect what you can run.
Sk hynix 16 Gbit M die: Also very capable, but don't assume its frequency or refresh limits match A die.
Sk hynix 24 Gbit M die: Different from 16 Gbit M die. It is commonly found in 24 GB and 48 GB modules. A refresh setting from a 16 Gbit kit isn't automatically suitable here.
Samsung DDR5, including B die: This isn't the famous samsung DDR4 B die. DDR4 voltage advice and timing expectations don't carry over just because the name sounds familiar.
Micron DDR5: The revision matters. Early micron DDR5 and newer parts shouldn't all be treated as the same thing.
Other or unknown chips: Find the exact part information where possible and test from a sensible baseline. These are examples, not a complete list of every DDR5 revision. A die letter on its own isn't enough.
Gbit describes the density of an individual chip. GB describes the capacity of the module. That difference matters when comparing settings, especially refresh timings. Manufacturer specifications apply to particular parts, not every kit with the same die nickname. Your limit also depends on the module's circuit board, its power management chip called the PMIC, the motherboard, BIOS, CPU and cooling. There isn't one overclocking frequency, voltage or tRFC ceiling that applies to every kit with the same die.
DDR5's built in on die ECC doesn't make unstable settings okay. It protects data inside the memory chip, but it doesn't provide full protection for data moving between the RAM and CPU. Having no visible WHEA errors doesn't prove the RAM is stable either.
《3. Programs and what they are for》
Link to all programs located at the bottom of guide if you're too lazy to use Google.
These programs do different jobs. You don't need to buy every tester or run every workload mentioned here. Choose a mix that checks the settings you're changing. A benchmark score and an error-free stress test tell you different things.
Zentimings: Shows the applied timings, clocks and available voltage information. Save a screenshot at each important checkpoint so you know what actually changed.
HWINFO: Use it to log RAM temperatures where sensors are available, CPU temperature, effective clocks, voltages and hardware error counters. Effective clocks help show what the CPU is actually doing during a test.
Testmem5, or TM5: Checks memory using different patterns and workloads. The loaded configuration matters, so always record which one you used. My final memory testing uses anta777 extreme and absolut.
Corecycler: I use sp00n's corecycler to make testing individual CPU cores easier. It runs supported stress programs, including prime95 and y-cruncher, and moves the workload between physical cores. This is useful for checking curve optimizer and going back to a core that failed. The actual calculations are still done by the selected stress program.
Prime95: Offers different calculation sizes and instruction modes. Smaller working sets mainly test the CPU and its cache, the fast memory inside the processor. Larger working sets can involve the memory controller and RAM too. The selected size and settings matter, not just whether the test says SSE or AVX2.
Y-cruncher: Includes several workloads with different CPU and memory demands. Some mainly work inside the CPU cache, while others involve much more RAM and help check the combined CPU and memory setup. It can be used directly or through sp00n corecycler. The examples later explain how to choose a workload, rather than treating one as a must.
OCCT: Its CPU, memory and CPU + RAM tests provide different ways to check the system. CPU testing and core cycling can help investigate core instability. Memory and CPU + RAM are useful when checking memory settings and the wider CPU to memory path.
AIDA64: Useful for comparing memory bandwidth and latency. The benchmark checks performance, it doesn't prove stability. You will eventually end up chasing AIDA64 scores like the rest of us.
PYPrime 2B: Another useful performance comparison after changing memory settings. Lower completion time is better. It also depends on CPU performance, so keep CPU settings and background activity consistent. Benchmate can run and validate supported benchmark results, but that doesn't certify daily stability.
MemTest86: Runs outside windows from a bootable USB drive. Useful for checking memory for errors, or that RAM kit you bought on Facebook Marketplace for 300 dollars. If it throws errors at stock, you might have gotten ripped off, but rule out settings and the rest of the system before blaming the seller.
It isn't required for every tuning step, but a quick check before loading windows can help when your tune starts entering BSOD territory. BSOD means a blue screen crash. Keeping windows unloaded reduces the risk of corrupting operating system files. A single pass can catch obvious instability, but it doesn't prove a finished tune is stable. I've had multiple BSODs while tuning, so if you wanna play it safe, this is another option. I'd also recommend keeping a bootable windows installation/recovery USB on standby, just in case your operating system decides to completely shit itself.
Optional additions are karhu RAM test or HCI memtest for another memory workload, CPUZ for identification, and a repeatable game benchmark or capframex capture to see whether the changes help your actual games.
《What the workload names mean》
SSE, AVX, AVX2 and AVX-512 are instruction sets, different instructions the CPU can use to carry out calculations. They aren't separate tests for separate components. A test using AVX2 can stress RAM too if its working data is large enough.
For CPU and curve optimizer work, different instruction modes and core loads can expose different problems. A lighter workload can let a core boost higher, while a heavier workload checks it under different conditions. Passing one doesn't cover the other.
In y-cruncher, the small in cache tests SFTv4, SNT and SVT mainly exercise the CPU and cache. BKT and BBP are other CPU focused examples. Larger tests such as FFTv4, N63 and VT3 can put more demand on the memory path as well, depending on the workload and allocation. Their names may differ between versions.
Memory allocation is how much RAM the test is set up to use. It doesn't tell you that every selected workload uses all of it. Check the test's own Mem/Thread entry and the allocation printed when it starts. GiB and MiB are memory size units, with 1024 MiB in 1 GiB. They are slightly different from the GB and MB used in advertising.
My example pictures show y-cruncher's component stress tester from my sp00n setup, including a setup with 16 logical processors and another targeting two. They also show that different workloads use different amounts of memory. Section 13 explains the targeted run, so don't assume every picture shows the same test or allocation.
The point is to cover different loads, not pick a favourite test and declare everything stable because it passed. VT3 is one option in that pool, not a special requirement or a test that identifies a bad component by itself.
Download programs from their developers. Check the selected configuration, threads, memory allocation and error detection before starting. Leave room for windows and stop important work while testing unstable settings. If windows runs out of available RAM, it can move data to the drive, called paging, which changes the workload and slows things down.
Run the main stress tests separately. Adding GPU heat later is a deliberate check of your case temperatures, not a reason to run every stress program at once.
《4. Establish a baseline》
A baseline is a set of settings you've checked and can return to. Having one makes the rest much easier.
Back up important files, save your BIOS settings and take screenshots. Keep a record outside the BIOS profile slots, including your CPU curve and voltage settings.
Check the BIOS notes for your exact board and CPU. Use a suitable supported BIOS with the relevant fixes. Don't flash a BIOS while running an unstable tune. Save your bitlocker or device encryption recovery key before firmware changes if encryption is enabled. If you update, establish a fresh baseline afterwards.
Return curve optimizer and any other custom CPU tuning to stock while working on memory. This includes curve shaper or boost overrides if you've used them. Leave the base clock, often called BCLK, at its normal setting. Remove an uncertain GPU tune too.
Check the system at default JEDEC memory settings. If it fails there, resolve that before overclocking.
Enable the kit's normal EXPO or XMP profile if it has one, check the applied settings and test it. If your kit has no profile, use its working default settings as the starting point. Booting successfully isn't the same as being stable.
Record a few repeatable benchmark results and temperatures. Save this working setup as your baseline.
If EXPO fails, try a lower frequency with suitably relaxed timings and the kit's rated DRAM voltage. This helps you investigate frequency or controller limits before adding tight manual timings. Check what auto changed after the frequency adjustment.
For tuning, I prefer setting both memory context restore (MCR) and power down enable to disabled. Disabling MCR avoids reusing its saved training results, so expect longer starts. Disabling power down keeps the RAM from entering that idle power saving mode. It doesn't disable refresh.
Leave both disabled while working through this guide. Later, you can try MCR and power down enabled together for faster starts, then retest stability, restarts, cold starts and sleep/wake. Follow your board's guidance because their interaction can depend on the BIOS. This isn't a claim that every other combination is broken.
My personal preference is to leave both disabled after tuning. Sure, you gotta wait a bit longer for it to boot, but I prefer fresh training rather than reusing MCR results. Keeping power down disabled also avoids the delay involved in leaving that power saving state. That doesn't guarantee lower benchmark latency or higher stability, it's just how I prefer to run my system.
Give training time to finish. A black screen straight after a change doesn't always mean the settings failed. If you need to clear CMOS, follow your board's procedure and its required power state. Don't short random pins.
Keep a simple log with the BIOS version, exact change, voltages set, test configuration, RAM allocated, duration, errors and highest temperatures. If you change five settings together and it fails, you've given yourself five things to figure out.
《5. Voltages and sensible boundaries》
These voltages have different jobs. Raising all of them together makes troubleshooting harder and can make stability worse.
DRAM VDD or MEM VDD: Powers the memory chips core circuitry. Start at the kit's rated profile voltage. Some timings, especially tCL on suitable chips, can improve with more VDD. That doesn't mean they keep improving forever.
DRAM VDDQ or MEM VDDQ: Powers the RAM side of the connection to the CPU. Start at the rated value. It doesn't always have to match VDD, but the module and board can have limits on how far apart they should be.
CPU VDDIO or VDDIO MEM: Powers the CPU side of the memory interface. Check what your board calls it and what it actually applies. More isn't automatically better.
VSOC or VDDCR SOC: Supplies the SoC, including the memory controller. It can affect how high UCLK will run, but it won't fix every bad RAM timing.
CLDO VDDP: Involved in memory signaling and training. Leave it on auto initially.
VDDG CCD and IOD: Related to the fabric. Leave them on auto while getting the basic tune working.
VDD misc: Another platform voltage with behavior that depends on the board and CPU. Leave it on auto for the beginner process.
DRAM VPP: A supply used to activate rows inside the RAM. Leave it at its normal specified value. It isn't the next voltage to raise when a test fails.
Check your board's manual. DRAM VDDQ and CPU VDDIO are separate supplies, even if the names make them sound similar.
《Caution with voltages. Zentimings, BIOS monitoring and HWINFO can show different voltage readings. Always record what you set in BIOS, but remember that the setting isn't a guarantee of the exact voltage being delivered. Differences can come from the sensors being used, how the software reports them and changes under load. Some DDR5 voltage readings can also be inaccurate. A small difference doesn't automatically mean something is wrong, but don't assume every mismatch is harmless. Don't raise voltage just to make a software reading match your BIOS setting. Check large or unexpected differences before making further adjustments.》
Where I would stop as a beginner:
For a first tune, keep VDD and VDDQ at the kit's rated values. Find out what the kit can do there before considering higher voltage. A kit with only a standard JEDEC profile should start from that profile's voltage, not somebody else's EXPO voltage. Another kit being rated for 1.40 V doesn't tell you that 1.40 V is suitable for yours or for a different voltage setting.
The following SoC and VDDIO numbers are limits for how far I would take this beginner workflow, not manufacturer approved safe ranges. They aren't minimum voltages you should immediately apply.
For manual SoC tuning around 6000 to 6400, roughly 1.15 to 1.25 V is a practical range to investigate. Some systems need less, especially at lower frequencies. For this beginner process, I would stop manual increases at 1.25 V and accept a lower frequency if needed.
AMD documented a 1.30 V SoC input cap for ryzen 7000 in ryzen master during normal operation. That is a software cap, not a setting to aim for or a promise of long term safety for every AM5 CPU. Respect current firmware protections and any lower limit for your hardware.
CPU VDDIO needs its own testing. Around 1.20 to 1.35 V is a practical region to investigate on many setups near these frequencies, not a required or guaranteed safe range. For this beginner process, I would stop manual increases at 1.35 V and reassess the frequency and hardware. If the board's profile applies something different, investigate before overriding it blindly.
There isn't one universal daily overclocking ceiling for VDD, VDDQ or CPU VDDIO. Above the rated profile, you need to understand your exact chips, module and cooling. Don't unlock high voltage modes or bypass firmware protections just to copy a screenshot.
My own numbers aren't beginner targets. My recorded 6000 profile used 1.54 V DRAM VDD and 1.40 V CPU VDDIO set in the BIOS. My 6200 CL26 work needed 1.62 V VDD for that particular profile. These are personal test results, not recommendations. I was using dedicated active RAM cooling and extensive testing. A fan helps with heat, it doesn't remove the electrical risks of high voltage. Looser timings or a lower frequency are perfectly reasonable choices.
Change voltage by one small supported BIOS step, often around 0.01 V, then repeat the same test. If more stops helping, stop adding it. Sometimes a lower setting works better because it improves signaling or reduces heat. Keep the BIOS setting and software readback as separate entries in your notes.
《6. Frequency and the memory controller》
Start from the stable baseline you established, with suitably relaxed timings, default refresh settings and conservative FCLK. 6000 isn't the minimum for this guide. A kit that works at 4800, 5200 or 5600 can still be tuned, and heavily populated configurations can need lower speeds again.
That doesn't mean a lower frequency setup is defective or only useful if you buy different RAM. The CPU, board, chip revision, capacity and number of sticks all matter. Some desktop ryzen specifications list substantially lower supported speeds with four DIMMs than with two. Check your exact CPU's specification.
The CPU's official memory support, the board's advertised overclocking speeds and the kit's rated profile are different things. A motherboard advertising a high speed doesn't mean your CPU can run it with UCLK and MCLK at 1:1.
My order would be:
Validate the starting frequency before tightening timings. Use working JEDEC settings if the kit's profile isn't stable.
Increase memory frequency by one available step. Don't jump from a budget kit's baseline straight to someone else's 6400 settings.
Keep FCLK conservative and check that UCLK stayed at the intended ratio.
Preserve timing margin. The same timing in cycles becomes a shorter delay as frequency rises, so you may need to loosen timings for the frequency test.
Check the applied settings, training and a memory test. Include a combined CPU/memory check from section 7 before going further.
If the new frequency fails, return to the working setting and investigate one thing at a time. Keep the last repeatably stable frequency when the next step isn't worthwhile.
If a higher frequency fails with loose timings, look at UCLK, controller limits, signaling voltages, the number of sticks and ranks, and training. If only a lower CL fails at the same frequency, look at that timing and DRAM VDD first. These are starting points, they aren't a diagnosis by themselves.
For the lower and moderate frequencies covered here, including the usual 6000 to 6400 attempts, aim for UCLK=MCLK, or 1:1. Don't halve UCLK just to keep a higher memory speed number at these frequencies. Drop to a lower frequency your controller can run in 1:1, then work on the timings. Check Zentimings after booting so an auto setting hasn't changed the ratio.
6200 and 6400 are optional experiments for hardware with enough headroom, not promised milestones for every SK hynix kit. If 6400 won't stabilize without excessive voltage or training problems, try 6200, 6000 or a lower stable setting appropriate to your hardware. Higher memory speeds with divided UCLK are a separate tuning path, not the beginner fallback in this guide.
A well tuned lower frequency can outperform a poorly tuned higher one in some workloads. Compare the finished result rather than assuming the biggest number wins. Once you choose a frequency, build the rest of the tune around it. Changing it later means rechecking the whole profile.
《7. FCLK, stability and checking performance》
Keep FCLK on auto or at a conservative working value while establishing RAM and UCLK. Around 2000 MHz is a common comparison point near DDR5-6000 on the desktop chiplet CPUs discussed here. It isn't a minimum for lower speed setups or a requirement for every AM5 processor.
Once the memory and controller have passed their checks, change FCLK one available step at a time while leaving the other settings alone. Keep curve optimizer at stock during this stage so a CPU undervolt isn't another possible cause of failure.
Check both stability and performance. A higher FCLK that boots isn't automatically better, and a clean benchmark doesn't prove it is stable. FCLK doesn't need to match MCLK. Just because my CPU can run a certain FCLK doesn't mean yours can.
《Choose tests for the change you're making》
A TM5 pass is useful, but don't use it as the only check after changing FCLK or the memory controller. Include a combined CPU/memory workload as well. Options include OCCT CPU + RAM, appropriately configured larger prime95 workloads, or larger memory y-cruncher tests such as FFTv4, N63 and VT3.
You don't have to run every option here. Choose more than one type of workload across the final testing, and check that the configuration actually exercises RAM rather than keeping almost all its data in the CPU cache. None of these is a fabric only test, so a failure still needs investigation.
Core by core testing and testing the whole CPU put the system under different loads. A large memory test on one core can still exercise RAM, but it doesn't reproduce the traffic or CPU behaviour of a sustained run across the whole CPU. Include both types where appropriate instead of treating either as a complete replacement for the other.
During FCLK tuning, I would use around 15 to 30 minutes of a chosen combined workload as an early screen after a small change. That's a checkpoint for deciding what to investigate next, not a pass that clears the setting for daily use. At the finished setting, extend the testing using section 12.
If a calculation error, crash or new hardware error appears, the setting hasn't passed. Save the log, return to the previous FCLK and repeat the same test before touching several voltages. A repeatable fail with the new setting and pass with the old one is useful evidence. It doesn't automatically tell you which voltage to change.
Check HWINFO and the windows system log for WHEA errors too. WHEA is how windows reports certain hardware errors. Not every event is a RAM or fabric fault, and having none doesn't prove stability. Ordinary background activity can change performance, but it doesn't make a calculation mismatch an acceptable result.
《Using the y-cruncher setup in my pictures》
I use sp00n corecycler and the y-cruncher copy supplied with it. Corecycler can handle the core cycling for CPU work. The component stress tester can also be opened directly for a chosen core selection or a whole CPU run. The folder the program came from doesn't tell you which setup is currently running.
For a direct run, stop any existing corecycler test, open y-cruncher's component stress tester, choose the logical processors and select the workloads you want. Keep stop on error enabled and check the actual memory allocation when the test starts. Section 13 explains the difference between physical cores and logical processors.
Use a supported executable and leave unfamiliar options at their defaults. Menu numbers and available tests vary by version, so follow labels rather than a copied series of numbers. The CPU to memory indicator and Mem/Thread column help explain the listed tests, but aren't stability scores.
Leave enough RAM for windows. A large allocation that works on my 64 GB system isn't suitable for every PC. Start with an allocation your system can comfortably run without paging. More allocated memory doesn't automatically make every CPU test better.
In my pictures, 120 seconds per test is paired with run forever. That means each selected workload gets its turn and the sequence repeats. It doesn't mean the whole session finishes after two minutes. Check the overall runtime and how long each workload actually ran.
《Comparing performance, including VT3 speed readings》
AIDA64 and PYPrime 2B are useful for checking whether a setting improved performance. AIDA64 measures bandwidth and latency, while PYPrime gives a timed workload result. Run each several times under similar conditions and compare typical results, not just your best run. Then check a game or program you actually use.
Some stress workloads also report speed. VT3 is an example shown in my pictures, so here is how to read it without turning the speed column into a stability rule.
Keep the program version, executable, tuning profile, selected cores, thread count, memory allocation and workload the same between comparisons. Let the system warm up, compare several results, then return to your original settings for another comparison. Record temperatures and effective clocks too.
When comparing corecycler results, compare the same physical core under the same conditions. Different cores can boost differently. Core switching and planned pauses also change the load, so don't compare unrelated lines from the log as though nothing changed.
VT3 may report speed in scientific notation. For example, 1.08 times 10^10 bits/sec means 10.8 billion bits per second. A difference of 0.3 times 10^9 equals 0.03 times 10^10, both mean 300 million.
That explains the scale, not an allowed amount of variation. There is no universal 0.3 or 0.03 pass/fail rule. First establish how much your baseline normally varies, then look for a repeatable improvement or slowdown. A steady speed column doesn't prove stability, and a messy one doesn't by itself prove fabric errors.
Windows services and background programs can affect the readings. If the results are unusually noisy, repeat both settings in safe mode to reduce that interference. Safe mode can give a cleaner comparison, but it doesn't guarantee accurate or identical numbers.
You can reach safe mode through windows recovery, then troubleshoot, advanced options, startup settings and restart. Have your account password and, if applicable, your bitlocker recovery key available. Return to normal windows afterwards for final testing.
Long runs can drift as the CPU, RAM, case and room warm up. That's heat soak. Safe mode doesn't remove it or prevent CPU clock changes, so compare similar temperature periods. A good speed result never cancels out a calculation error.
《8. Primary timings》
Start from your working EXPO, XMP or JEDEC timings. Keep frequency and voltages fixed while trying one timing so you can tell what changed.
Lower timing numbers usually give RAM less time to complete an operation. That's what I mean by tightening. Loosening means allowing more time. Refresh settings have some differences, which I'll explain later.
tCL: The delay between a read command and the data becoming available under the relevant conditions. Lower it by a supported step, often two cycles, then test. Some chips respond to more VDD here, but needing a lot more voltage for a small reduction is a good reason to keep the previous value.
tRCDRD and tRCDWR: The delays between opening a row and reading or writing it. Many AMD boards let you set them separately. A low tRCDWR working doesn't mean tRCDRD can go just as low, and extra VDD won't always help.
tRP: The precharge delay involved in closing a row before another can be opened in that bank. Test it separately, it doesn't automatically need to match tRCD.
tRAS: The minimum time a row stays active in the DRAM timing model. Leave it at the working auto or profile value initially. Very low values can cause errors without giving you a useful performance improvement.
tRC: The time between starting one row cycle and starting another in the same bank. It works alongside tRAS and tRP. The BIOS and memory controller can limit how entered values are used, so the numbers alone don't tell you exactly what the RAM is doing. Leave it at a working value initially, then test it separately. Don't use my screenshot or one timing formula as proof that a setting is correct or incorrect. Check stability and whether the change actually affects performance.
If a timing fails, put it back and check that the previous setting still works. Once you find the edge, back away from it a little. The lowest number that barely passed once isn't automatically a good daily setting.
《9. Secondary and tertiary timings》
These are the other timing groups you'll see below the main timings. They can matter as much as the headline CL, but you don't need to change all of them at once. Think of banks as separate sections inside the memory chips, with banks arranged into groups. Some delays depend on whether the next operation stays in the same group or moves to another.
tRRDS and tRRDL: Control spacing between row activations. S applies to different bank groups, L applies within the same bank group.
tFAW: Limits row activations to no more than four within a moving time window for a rank.
tWTRS and tWTRL: Delays when changing from writing to reading. S applies to different bank groups, L applies within the same bank group.
tWR: The recovery time after write data before closing the row.
tRTP: The delay from a read command to precharging, or closing, the row.
tCWL: CAS write latency, related to the delay between a write command and its data.
tRDRDSCL and tWRWRSCL: Spacing between repeated reads or repeated writes to the same chip select and bank group. Often called the SCL timings. A chip select is how the controller selects a rank of memory.
tRDWR and tWRRD: Delays when switching between reads and writes.
tRDRD and tWRWR SC, SD and DD: Related to where the next read or write is going. SC means the same chip select, SD concerns different ranks on the same module, and DD concerns different modules. Which ones matter depends on your setup.
For tRRD and tFAW, lowering tFAW past what the other activation delays already allow may do nothing. You may see tFAW = 4 times tRRDS suggested, but that's a scheduling relationship, not a guaranteed stable preset. Don't force tRRDL to match tRRDS.
Try SCL changes as individual candidates. If a lower value gives errors, different training or worse performance, it isn't a useful improvement. Treat read/write turnarounds the same way, especially with dual rank memory.
Keep timings that depend on ranks on auto until you understand your stick and slot arrangement. A single rank preset isn't automatically suitable for dual rank RAM. Some settings in a screenshot may not even have been relevant to that person's setup.
Leave command rate, gear down mode and less familiar controller settings at working defaults initially. A BIOS can round, limit or ignore an entry, so check Zentimings and actual performance instead of only looking at the numbers you typed.
A practical order is primary timings, activation timings, read/write recovery, SCL and turnarounds, then refresh. Work through one setting at a time and keep checked profiles between groups. For a beginner, reducing one adjustable timing by one supported BIOS step is easier to troubleshoot than pasting a whole table of minimum values. The exact order matters less than being able to undo the change that caused a problem.
《10. Refresh timings and temperature》
RAM needs regular refreshing to keep its data. Changing refresh settings can improve performance, but it can also make a tune much more sensitive to heat.
tRFC: The time needed for the relevant refresh operation before affected memory can resume normal work. Lower usually means less waiting, but too low can cause errors straight away or much later.
tREFI: The average interval between refreshes. Higher means refreshing less often. This is an exception to the idea that lower timings are always faster. Raising it can improve performance while leaving less room for the memory to retain data reliably. Temperature and chip density affect refresh requirements.
For example, tRFC 480 at DDR5-6000 is 160 ns. At 6200, the same 480 is about 154.8 ns. Raising frequency shortened the actual refresh delay even though the BIOS number didn't change.
Keep refresh at default while finding your frequency and other timings. Then lower the active tRFC value in modest steps, test it and leave some room above the failure point. Change tREFI separately.
On boards that support them, 32768 or 50000 can be intermediate tREFI settings to investigate, not universal starting recommendations. Leave auto/default refresh in place if you don't yet understand your kit's limits. Don't jump straight to 65535 just because you saw it in a screenshot.
《Normal and mixed refresh modes》
Check which refresh mode your BIOS uses. Newer firmware can use tRFC2 and same bank tRFCsb where an older profile didn't. A copied value that previously had no effect can become important after a BIOS update.
AMD has documented mixed refresh mode as a mitigation for rowhammer attacks, which involve repeatedly accessing memory in ways that can disturb nearby data. ASUS has also explained how the change affects the active refresh timings. Keep the current supported default for the beginner process and retune the timings that are actually in use. Don't assume every board or BIOS version applies the same default.
Switching to normal just to regain an old score can remove a mitigation. Don't choose the mode from the die name alone. A screenshot showing normal mode, including mine, isn't advice to turn off a current mitigation.
Leave tRFC2 and tRFCsb on auto until you know they're active and have a reason to change them. DDR4 advice about tRFC4 doesn't automatically apply to a differently named DDR5 setting.
《How hot is too hot?》
A manufacturer's operating temperature rating doesn't promise that tight overclocked settings will work all the way up to it. The reported DIMM or SPD hub temperature also isn't a direct reading of every memory cell. Some modules don't provide a usable temperature reading at all. A missing sensor doesn't mean the RAM is cool.
Different RAM kits have different temperature tolerances. SK hynix, Samsung and Micron chips can all behave differently, even between revisions from the same manufacturer. Timings, voltage and refresh settings affect the margin too.
For heavily tuned memory, I would use roughly 45 to 50°C reported DIMM temperature as a cautious cooling target, not a guaranteed safe temperature or a stability cutoff. Some tunes fail below that, others work above it. Always test your hardware under the warmest conditions you expect to use it in. That target is my tuning preference, not a manufacturer specification.
Test with the case closed and your normal fan settings. Check realistic GPU heat too, since a memory test by itself may leave the case cooler than gaming does. Don't assume a cool memory only run covers every gaming session.
《Active cooling and aggressive settings》
Active RAM cooling means directing airflow over the sticks with a fan. I used dedicated cooling when pushing my kit's voltage and refresh timings. That's part of why the results in my pictures shouldn't be treated as settings anyone can copy.
This isn't a requirement to buy a RAM fan before trying moderate tuning. Start at rated voltage and sensible timings, then judge your actual temperatures. For an aggressive tune, plan for cooling and warm case testing instead of hoping the screenshot's settings will work without them.
More voltage can add heat, and a fan doesn't make an unsuitable voltage safe. If errors only appear once things warm up, compare refresh settings, voltage margin and airflow one at a time. Lowering tREFI or loosening tRFC may help more than adding voltage and more heat. Retest after making the change.
《11. Fast tuning for experienced users》
Do this at your own risk. I don't recommend this as a beginner's main way of tuning.
The TM5 profile named DDR5 Ryzen3D @ anta777 is useful for quickly screening changes on X3D systems. One complete cycle can be much shorter than an extreme or absolut cycle. The time depends on the system, allocation and profile version, so a particular number of minutes doesn't prove the test ran properly.
If you already understand tuning and have a tested baseline:
Change one setting and record it.
Load the intended profile and check the memory allocation.
Finish at least one complete cycle as an initial screen. Check the log, don't assume the profile automatically stops after one.
If it fails, undo or investigate that change.
Treat a pass as a candidate and run longer checks regularly before stacking more changes.
Complete section 12 before calling the tune finished.
A quick cycle can catch an obviously bad setting. It can't tell you whether that setting will survive eight hours, another workload or a hotter case. My recorded ryzen3d example shows an error on cycle 2 at 8 minutes 9 seconds. Stopping after cycle 1 would have missed it.
Other profile names you may encounter include DDR5 Intel @ anta777, Universal 2 @ LMhz and 1usmus v3. Don't rename the Intel profile as the non X3D ryzen equivalent. Use configurations suited to your testing purpose, check the files supplied with your version, and still finish with the longer checks.
Use the controls and help for your TM5 version. The coolcmd version has a settings interface that differs from older guides. Check how your version handles duration and completed cycles. Ten cycles of a short profile aren't the same as ten extreme cycles.
The problem with fast tuning is how easy it is to stack several changes that only just pass. When a long test eventually fails, you then have several possible causes to work through.
《12. Final stability testing》
For this guide, both anta777 extreme and absolut are required for the final memory checks. This is the testing standard I'm using, not a universal industry requirement or a guarantee that every possible problem has been ruled out.
The other workloads are chosen to cover the CPU and memory together, then the individual CPU cores. VT3 is an option, not a mandatory test or the deciding vote over everything else.
Here is the order I would follow:
During tuning: For beginners, run one complete extreme or absolut cycle after a timing change. Do longer checks before moving to another group. After a frequency, UCLK or FCLK change, include a combined CPU/memory screen from section 7 too.
Final memory checks: Run at least three complete cycles of extreme, then at least three complete cycles of absolut separately.
Overnight memory check: Extend at least one of those runs to roughly 8 to 12 hours at the finished settings. If three cycles take longer, let them finish. The overnight run can also count towards that profile's three cycles, you don't need to repeat the same work just to tick another box.
Combined CPU and memory checks: Choose additional workloads that use the CPU and memory path together. Examples include OCCT CPU + RAM and larger memory y-cruncher workloads. Around 1 to 2 hours of a chosen setup is a useful checkpoint, not a universal pass threshold. Add a different workload rather than relying entirely on one algorithm. If a suite rotates tests, record how long each actually ran, not just the total session time.
FCLK and controller changes: Make sure these combined checks include sustained activity across the CPU with a working set large enough to involve RAM. A tiny memory run or a quick benchmark doesn't cover that situation. The test name matters less than verifying the settings and understanding what the test is doing.
CPU curve checks: Restore your saved curve optimizer settings and use sp00n corecycler with more than one supported workload. Include different core loads and instruction modes, plus idle and light use. Check the time each core actually received, not just how long the whole program was open.
Finished settings together: Repeat the important memory and combined checks with your finished CPU tune enabled. Do the final overnight memory run on that combined setup. Passing the RAM tune with CO off and the CPU tune with different RAM settings isn't the same as testing the finished configuration.
Everyday checks: Test cold starts, restarts, sleep and wake, long gaming or work sessions, and normal GPU heated case conditions. Test a full shutdown and fresh start as well as a restart. Don't repeatedly cut power while windows is running.
These durations are practical targets, not magic numbers. Extend testing when earlier failures took longer or a setting is close to its limit. Write down the configuration, allocation, cycles, time and temperatures. A run still in progress is error free so far, not a completed final pass.
Why run for so long?
Some errors need a particular pattern or sequence of operations before they show up. Others are intermittent or become more likely as temperatures change. Longer runs give those problems more chances to appear. It isn't because RAM always takes eight hours to reach its hottest point.
Different tests use different patterns, working sets, CPU instructions and loads. Passing one for hours doesn't make an error in another unimportant. Adding more programs isn't helpful if they were all run with unsuitable settings or barely any memory allocated.
My recorded extreme example shows one error on cycle 6 after 4 hours 14 minutes 24 seconds. During this tuning project I also traced late errors to insufficient DRAM VDD. The picture alone doesn't prove that was the cause of that particular failure, other settings were being investigated too. Heat, refresh settings, controller margin, training and an aggressive CPU curve can give similar symptoms.
One calculation or memory error means that run hasn't passed. Save the log and conditions, then investigate. There's no need to keep a clearly failing setup running just to collect more errors. A TM5 test number tells you where the mismatch was detected, it doesn't identify one exact bad timing or voltage. A program launch or allocation error is a setup issue to resolve, not automatically a hardware fault.
If you add karhu or HCI, record the memory allocation and coverage as well as time. Coverage percentages mean different things between programs, so don't compare them as if they're the same measurement.
《13. Retesting curve optimizer with sp00n corecycler》
Once RAM, IMC and FCLK pass with the CPU at stock settings, restore your saved curve. Then check the combined setup again as described in section 12.
Changing memory performance can expose a weak spot in a CPU curve that seemed fine before. Don't automatically blame the RAM because curve optimizer passed an earlier test.
I use sp00n corecycler to run different workloads across individual CPU cores. My examples include prime95 SSE and AVX2 tests, plus workloads in y-cruncher. In my own tuning, a core passed other loads but failed VT3, so I had to make its negative curve less aggressive. That is a personal troubleshooting example, not a reason everyone has to use VT3 or dismiss their other tests.
If a failure repeatedly happens while testing one core, start by reproducing that failure. When CO looks responsible, make it a little less negative, for example -25 to -23, then repeat the same workload. If the cause is unclear, compare with CO at stock while leaving the memory settings unchanged.
《Physical cores and logical processors》
A physical core is an actual CPU core. SMT allows it to run two hardware threads, which windows lists as two logical processors. My 8 core CPU shows 16 logical processors with SMT enabled. Curve optimizer is adjusted per physical core, not separately for its two SMT threads.
My earlier failure examples named logical processor 10 in one run and 11 in another. Those can belong to the same physical core. Check the mapping shown by corecycler and its logs rather than assuming the numbering is identical on every CPU.
The processor named in an error is a clue, not proof that only that physical core is at fault. RAM, fabric and controller settings can still be involved.
《Targeting a core with corecycler》
Open the active config.ini in your sp00n corecycler folder. If useConfigFile selects a preset, edit that selected file or deliberately switch back to your main configuration. Don't edit default.config.ini as your working file.
For an example using VT3 to reproduce a failure on physical core 5, the relevant entries are:
[General]
stressTestProgram = YCRUNCHER
coreTestOrder = 5
[yCruncher]
tests = VT3
These are edits to an existing configuration, not a complete replacement file. Keep the setting names as the developer writes them, even though the surrounding guide uses casual capitalization. To investigate another workload, use its supported settings instead.
Core numbering starts at zero, so core 5 is the sixth physical core. Setting coreTestOrder = 5, 2 tests those two physical cores in sequence. Check coresToIgnore and confirm the intended cores in the log. Logical processors 10 and 11 don't belong in that physical core list just because they appeared in a y-cruncher error.
Keep the executable mode, numberOfThreads, memory allocation and workload settings the same when reproducing a failure. One thread and two threads create different loads, neither replaces the other. Don't change the thread count halfway through a comparison and call it the same test.
Use a supported mode from the comments in your installed configuration. The mode selects which executable corecycler launches. Beginners don't need to guess which binary has the best sounding name. Check what actually launched in the log.
《Check the allocation, don't assume the default》
Some corecycler configurations use a small y-cruncher working set measured in tens of MB. That can be useful for CPU/core testing, but it isn't a test of most of your installed RAM. Other configurations allocate much more. Read the allocation shown by the running test, not just the name VT3 or y-cruncher.
The two thread picture in my album is a large memory example. It shows VT3 allocating about 26.9 GiB to logical processor 10 and another 26.9 GiB to 11, roughly 53.8 GiB total. That picture doesn't show a tiny default allocation, and it doesn't by itself show a completed stability pass.
A large allocation on two threads still isn't the same workload as using all 16 logical processors. Keep both the memory use and CPU load in mind when deciding what you've checked. Don't copy my allocation onto a system with less RAM.
After adjusting a failing core, restore the full core list and your other workloads. Include idle, browsing, game loading and sleep/wake. Passing only the core that originally failed doesn't finish the job.
《Optional: selecting processors directly in y-cruncher》
The same y-cruncher program can be opened directly from your sp00n package. Stop corecycler first, then use the component stress tester's logical core selection. This is an alternative way to set up a test, not a required extra step.
For a targeted one thread run, select the verified logical processor. For a two thread run on one physical core, select both of its verified SMT threads. To reproduce a failure, match the selection used in the failing run.
Select the workload you want, check memory allocation and leave stop on error enabled. Confirm the selected processors in the allocation/output lines. Setting the thread count to two doesn't automatically mean the program will use the particular pair you intended. Follow menu labels because numbers can change between versions.
《14. Advanced ohm and training settings》
This section is optional. Leave these settings on auto until you understand the normal frequency, timing and voltage work. Most beginners don't need to touch them.
ProcODT, DRAM RTT settings and drive strengths affect how signals travel between the CPU and RAM. Termination helps control unwanted signal reflections. Some settings are shown in ohms, which measure resistance, and others use a fraction of a reference value called RZQ. A lower number isn't automatically faster or better.
The useful setting depends on the board layout, the memory module's circuit board, ranks, frequency and CPU. Something that helps one system can make another train worse. There isn't a universal ohm preset to copy.
If you get to this point, save the working auto or trained values. Change one control by one available step, retrain, then test repeated cold boots as well as stability. Keep timings and voltages unchanged during that comparison. Undo changes that don't give a repeatable benefit.
AMD nitro and related training settings are also advanced. More aggressive settings can leave less room for stable operation, while more thorough training can make booting take longer. A copied nitro preset isn't a free improvement. Keep the defaults until you understand the specific problem you're trying to solve.
《15. Troubleshooting and recording results》
Won't POST after a change: POST is the startup check before windows loads. Give training time to finish. If the board still won't complete startup, restore the last working profile or follow its recovery procedure.
Errors straight after adjusting voltage or a timing: Put that setting back first and repeat the same test.
Higher frequency fails with loose timings: Check UCLK, controller and signaling settings, the number of sticks and ranks, and training. Compare with the previous frequency.
Errors after increasing FCLK: Return to the previous FCLK with the other settings unchanged, then repeat the failing workload. Don't start increasing every voltage together.
Errors only after hours or with GPU heat: Compare temperature logs, refresh settings, DRAM voltage margin and the CPU curve one at a time.
Memory tests pass but core cycling fails: Investigate CO. Compare with stock CPU settings and try to reproduce the failure on the affected core. Don't assume a reported core rules out shared memory or fabric settings.
A benchmark or stress test speed reading becomes inconsistent: Check background activity, temperatures, clocks, selected cores and test settings. Repeat the baseline and new setting under the same conditions. Safe mode can reduce interference for a comparison, but it doesn't prove stability. Return to normal windows for final testing.
A warm boot works but cold starts fail: Check training and whether saved training is being reused. A daily tune needs to work after a fresh start too.
A BIOS update breaks an old profile: Check the active timings, refresh mode, training defaults and voltage readings. Keep screenshots and written settings outside the BIOS. Don't assume old saved profiles will remain available or be compatible with the new version. Reenter settings from a checked baseline and retest, even if the BIOS offers to import an old profile.
Don't blame RAM for every crackle, crash or stutter. Drivers, GPU settings and other hardware can cause similar problems. Comparing against a saved working baseline is more useful than changing voltages at random.
For screenshots, show Zentimings, the test profile, allocated memory, elapsed time, cycles, errors and temperatures. A late failure and the corrected run are useful examples. The error shows there was a problem, the changes and retesting explain how you worked out the cause.
The example album linked at the start shows the process and why I don't rely on quick passes alone.
Treat the settings as specific to the hardware shown. The intel benchmate picture is a program example. Label older configurations separately from the current tune, and label an unfinished test as error free so far rather than a completed pass.
Label your baseline, settings still being tested and finished profiles clearly. After changing the CPU, BIOS, memory capacity, cooling or major memory settings, go back through the relevant checks.
When asking for help, include your CPU, motherboard and BIOS, kit and ranks, timings, BIOS voltage settings, test versions and configurations, how long it took to fail and the temperatures. For corecycler, include the selected core, executable mode, thread count and allocation from its logs.
Take your time. There is nothing wrong with keeping a slightly looser tune that works every day. If a change doesn't give you a repeatable benefit, you don't have to keep it just because the number looks better.
《Programs and further reading》
The test durations, beginner voltage stopping points and cooling target are the approach used in this guide, not manufacturer certifications. The personal examples are from my own tuning. Use the documentation for the program version and hardware you actually have.
《Monitoring and identification》
Zentimings: https://github.com/irusanov/ZenTimings
HWINFO: https://www.hwinfo.com/
CPUZ: https://www.cpuid.com/softwares/cpu-z.html
《Testing and performance comparisons》
Testmem5, CoolCmd version and releases: https://github.com/CoolCmd/TestMem5
Sp00n corecycler, instructions and presets: https://github.com/sp00n/corecycler
Corecycler reference configuration: https://github.com/sp00n/corecycler/blob/master/configs/default.config.ini
Y-cruncher, downloads and documentation: https://www.numberworld.org/y-cruncher/
Y-cruncher workload/version changes: https://www.numberworld.org/y-cruncher/version_history.html
Prime95: https://www.mersenne.org/download/
OCCT and test descriptions: https://www.ocbase.com/
MemTest86: https://www.memtest86.com/
Karhu RAM test: https://www.karhusoftware.com/
HCI memtest instructions: https://hcidesign.com/memtest/manual.html
AIDA64 cache and memory benchmark: https://www.aida64.com/user-manual/benchmarks/cache-memory-benchmark
Benchmate and supported benchmarks, including PYPrime: https://www.benchmate.org/en
《Technical background》
AMD timing definitions: https://docs.amd.com/r/en-US/68886-ryzen-master-user-guide/DRAM-Timing-Configuration
AMD voltage controls: https://docs.amd.com/r/en-US/68886-ryzen-master-user-guide/Voltage
AMD ryzen master notes documenting the ryzen 7000 SoC input cap: https://www.amd.com/en/resources/support-articles/release-notes/RN-RYZEN-MASTER-2-10-3-2518.html
AMD mixed refresh security mitigation: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7048.html
ASUS refresh mode explanation: https://rog-forum.asus.com/t5/technologies-explained/amd-am5-memory-refresh-update-bank-refresh-mode-explained/ba-p/1135076
MSI explanation of memory context restore: https://www.msi.com/faq/10883
HWINFO developer on DDR5 voltage readings: https://www.hwinfo.com/forum/threads/unstable-memory-voltage.8579/
MemTest86 on on die ECC: https://www.memtest86.com/ecc.htm
MemTest86 on investigating errors: https://www.memtest86.com/troubleshooting.htm
Corsair on compatibility and mixing kits: https://help.corsair.com/hc/en-us/articles/4414608785549-RAM-Why-won-t-my-old-high-end-kit-work-at-its-rated-speed-on-a-new-motherboard-or-vice-versa
Microsoft safe mode instructions: https://support.microsoft.com/en-gb/windows/experience/startup-boot/windows-startup-settings?nochrome=true
Use your own motherboard manual for BIOS labels, recommended slots and recovery instructions. Check the exact CPU and memory specifications rather than treating somebody else's hardware limits as your own.
