HYDRA DRAM LAB 1.1 - DEEP DIVE INTO DRAM OPTIMIZATION

Why HYDRA DRAM LAB Is a New Standard for Memory Testing

1. The problem with traditional DRAM benchmarks

Most popular memory tests were never designed for gamers. They were built for service tasks and pretty screenshots: maximum GB/s, a single “latency” number, long AVX copies, almost perfectly linear access patterns.

In real games, nothing looks like that:

• Memory access is small and chaotic, not one giant linear stream.

• The CPU hits AI, physics, engine systems, streaming, networking, UI all at once, each with its own pattern.

• What matters is not just “average” values, but the tail of the distribution: P95, P99, stutters, jitter.

• Ryzen architecture (Zen 3 / Zen 4 / Zen 5) with its CCD layout, Infinity Fabric, bank groups, tFAW, tRRD, refresh behavior behaves very differently from old platforms classical tests were tuned for.

Result:

• You can have a “nice” latency in a synthetic test and worse smoothness in games.

• Timings that truly affect stutters and tails are not highlighted separately.

• Overclocking becomes “feel-based”: you tweak CL/tRCD/REFI, watch AIDA/MaxxMem… and then wonder why Warzone or Apex feels worse.

HYDRA DRAM LAB was built exactly against that: as a tool that speaks the language of gaming comfort, not just marketing GB/s.

2. The philosophy of HYDRA DRAM LAB

DRAM LAB is not trying to be “just another latency X ns, read Y GB/s” benchmark.
Its goal is to show the behavior of your memory subsystem as a whole, working together with Ryzen instead of in a vacuum.

Core ideas:

• Game-like scenarios instead of lab vacuum.
  Some tests push memory in a way that resembles what modern games actually do: mixed reads/writes, multithreaded access, contention on the memory controller, chaotic access patterns.

• Focus on tails and smoothness.
  DRAM LAB exposes not only averages, but P50, P99, Game P99, Game Stut, Jitter, Bank Thrash - the exact things that answer the question:

  “Why do I have 200 FPS and still feel stuttering?”

• Different access patterns, not one magic number.
  Local / Scattered latency, MLP, R/W Turn, Bank Thrash - these are different facets of the same subsystem.
  They highlight different timing groups: sometimes tRRD/tFAW, sometimes tRFC/REFI, sometimes RD↔WR cross-timings.

• Deep adaptation to Zen 3/4/5.
  Buffer sizes, access patterns, and load behavior are designed so that:

  • the working set actually leaves L3,

  • prefetchers can’t just “fake” good results,

  • you see the behavior of the memory controller and Infinity Fabric, not just cache tricks.

The algorithms remain a black box: the user sees clean, meaningful metrics, while DRAM LAB’s internals stay unique HYDRA IP.

3. Practical advantages for gamers and overclockers

HYDRA DRAM LAB is built as a tuning lab, not a one-shot “run and forget” tool.

What this means in practice:

• One run = a full snapshot of your system.
  You get 15 metrics that probe different corners of the memory subsystem:
  from base Lat P50 to Game Stut%, Bank Thrash and MLP Eff.

• Direct link from “timing” to “feeling in-game”.
  Want to know whether it makes sense to tweak REFI / RFC? Look at Game P99 / Game Stut / Jitter.
  Want to squeeze tRRD/tFAW? Check MLP and Bank Thrash.
  DRAM LAB turns abstract numbers into clear tuning directions.

• Profile comparison and progress tracking.
  Results can be stored, compared, and shared with other enthusiasts.
  It’s no longer “I feel it’s better”, but:

  “Here are two profiles. This one has lower Game P99 and half the Game Stut - that’s the one worth keeping.”

• Part of the HYDRA ecosystem.
  DRAM LAB lives in the same world as your smart CPU/GPU OC, monitoring, and tuning logic.
  It’s not a random external utility - it’s a core part of your overclocking workspace.

4. Why it’s “better than anything else out there”

Not because a marketing slide says so, but because DRAM LAB:

• is focused on real gaming scenarios, not just synthetic benchmarks;

• speaks the language of P99, stutters, and tails, not just averages;

• is designed specifically for Ryzen Zen 3/4/5, not just “kind of works” on them;

• lets overclockers see the impact of specific timings on specific aspects of memory behavior;

• enables you to build your own DRAM methodology: profiles, tables, comparisons, community references.

HYDRA DRAM LAB is not just “yet another latency number”. It’s a tool that helps you understand why your PC suddenly starts feeling “butter smooth”, instead of just showing that some number dropped by 2 ns.

How to perceive DRAM LAB metrics

Legend for Raw Latency Distribution Histogram

What this chart shows
This is an X-ray of your latency: millions of samples sorted into bins. On the X axis you have latency in nanoseconds. On the Y axis you have how many times such latency was observed.

The more the bars are clustered to the left and tightly packed, the faster and more consistent your memory feels.

The histogram is split into access types:

• Fast Random (green)
  A “light” scenario - quick random accesses where the memory controller is still comfortable.
  You see the base DRAM latency when nothing major interferes.

• Standard Random (yellow)
  Typical random access with a mix of row hits and row misses across banks.
  Closer to what an average game does: not ideal, but not a worst-case storm either.

• Contested Random (orange)
  A scenario where memory is under pressure from multiple threads.
  More bank conflicts, more row opens/closes, more work for the controller.
  This bar shows how parallelism-related timings (RRD, FAW, RDWR/WRRD, etc.) and controller behavior affect the latency tail.

• Worst Case Hardware Latency (small bar on the far right)
  The “worst 1-2% of life” of your platform: refresh + unlucky bank + conflict + contention all at once.
  It represents the hardware worst-case latency under extreme conditions.

How to read it

• If Fast Random and Standard Random are tight and far to the left - your baseline latency profile is excellent.

• If Contested Random is not much further to the right than Standard, your memory holds up well under multi-threaded pressure.

• If Worst Case Hardware Latency sits far to the right and has a noticeable height - you’ll feel stutters in the tails even with good averages.

Timings / settings that matter most

• For Fast / Standard Random:

  • Primary: CL, tRCDRD/tRCDWR, tRP, tRAS, tRC

  • Frequencies: MCLK / UCLK / FCLK (1:1 when possible)

• For Contested Random:

  • Bank-related: tRRD_S, tRRD_L, tFAW, tRC

  • R↔W cross-timings: tRDWR, tWRRD, tWTR_S/L, tWR, tRTP

  • Controller settings that affect parallelism (MLP).

• For Worst Case Hardware Latency:

  • Refresh: tRFC, tREFI

  • Power / low-power modes: PDM and related options

  • Stability of clocks and voltages: VDIMM, VDDQ, VSOC, MC (unstable OC often inflates this tail first).

Legend for L2-L3-DRAM latency (pointer chasing) Curve

What this chart shows
This curve plots access latency vs working-set size (Sample size, MB):

• On the left you have small data that fits into caches.

• On the right you have large data that forces the CPU to go out to DRAM.

X axis - data size in MB.
Y axis - access latency in nanoseconds.

The curve typically has three regions:

1. L2 plateau - the lowest part. Very small sizes, latency of just a few ns.

2. L3 plateau - a noticeable step up, but still below DRAM latency.

3. DRAM region - once the working set exceeds L3 capacity, the curve climbs to a new, higher level.

The “knee” points of the curve show the effective cache boundaries and the point where a game starts to pay the full price of DRAM access.

How to interpret it

• The lower the DRAM plateau (right side of the curve), the better your baseline memory latency.

• The smoother the transition from L3 to DRAM, the fewer abrupt latency jumps you’ll see as scenes and working sets grow.

• The L2→L3 and L3→DRAM steps are what you feel as:

  “As soon as the scene gets heavier / more objects appear, the game starts thinking longer.”

What you can and cannot tune

• L2 region

  • Mostly defined by core architecture and CPU frequency.

  • DRAM timings hardly affect it.

• L3 region and the L3→DRAM transition

  • Driven by FCLK, CCD topology, and memory controller behavior.

  • Indirectly responds to MCLK/UCLK and memory settings via interaction with Infinity Fabric.

• DRAM plateau (right side)
  Here your memory settings truly matter:

  • Primary timings: CL, tRCDRD, tRP, tRAS, tRC

  • Frequencies: MCLK / UCLK / FCLK ratios (1:1 vs 1:2, etc.)

  • Secondary timings that impact row misses and bank behavior (tRRD, tFAW, tRFC/REFI in more extreme scenarios).

The tuner’s goal is to:

• Push the DRAM plateau as low as possible,

• smooth out the steps between caches and DRAM,

• and keep the system stable while doing it.

1. Lat P50 (ns) - Baseline memory latency at idle

What it means
Lat P50 is the median (50th percentile) latency of memory access when the system isn’t heavily loaded. Imagine the game randomly pulling small chunks of data from a big scene - Lat P50 is how long that usually takes, in nanoseconds, once caches are no longer helping.

How it feels in games
Lower Lat P50 = a “tighter” and more responsive system. Menus feel snappier, background OS tasks cause fewer tiny hitches, and the CPU can pull data from DRAM quickly when it needs to.

Timings / settings that affect it most

• Primary timings

  • CL (CAS Latency) - one of the main drivers; lowering CL almost always drags Lat P50 down.

  • tRCDRD / tRCDWR - delay between row activation and read/write; important for random access.

  • tRP - time to precharge (close) a row before opening another; matters when access is not very local.

• Secondary / tertiary

  • tRAS, tRC - define the minimum open+close cycle for a row; affect average latency when there are many row misses.

  • tRRD_S / tRRD_L, tFAW - limit how quickly new rows can be activated in banks / bank groups, so they slightly touch the median.

• Platform settings

  • MCLK / UCLK / FCLK - a 1:1 memory–controller link (especially on DDR4 and early DDR5) often gives the lowest latency.

  • CMD rate (1T/2T), GDM, PDM - more aggressive modes (1T, GDM Off) can shave off a bit of latency but may hurt stability.

  • VDIMM, VSOC, memory controller / VDDQ - don’t change latency by themselves, but allow you to hold tighter timings safely.

2. Lat P99 (ns) - The tail of latency, worst 1%

What it means
Lat P99 shows how bad latency gets for the slowest 1% of memory accesses. This is not about “average”, it’s about those rare but painful slow requests - the ones that create micro-stutters.

How it feels in games
High Lat P99 = sudden hitches on top of an otherwise smooth experience. Short visible pauses when loading a texture, a small freeze when a script triggers, or a weird hiccup during quick camera turns.

What it depends on

• Primary / secondary

  • Everything that affects Lat P50 also affects P99: CL, tRCDRD, tRP, tRAS, tRC.

  • But P99 is especially sensitive to “heavy” timings and DRAM maintenance events:

    • tRFC - refresh cycle time; large tRFC = long periods where DRAM can’t respond.

    • tREFI - refresh interval; smaller tREFI = more frequent refresh → more chances for long spikes.

    • tRRD_S / tRRD_L, tFAW - limit how aggressively you can open rows across banks/bank groups.

• Platform

  • Background processes and OS scheduler - can push some accesses into the worst 1% zone.

  • MCLK/UCLK/FCLK - unstable or suboptimal combinations (e.g. odd FCLK) can increase the tail even if the median looks fine.

3. Read MT (GB/s) - Game-like multithread read bandwidth

What it means
Read MT shows how many GB/s your system can realistically read from DRAM in a multithreaded scenario with small, scattered blocks of data. This is much closer to what games do than a simple linear STREAM copy.

How it feels in games
This tells you how quickly the game can stream in maps, models, animations, and textures when the CPU is hammering memory from multiple threads. Higher Read MT = fewer situations where the GPU sits waiting for data.

Key influences

• Frequencies

  • MCLK - base bandwidth; higher and stable is better.

  • UCLK, FCLK - the relationship between memory controller and Infinity Fabric; 1:1 or well-tuned ratios help.

• Primary / secondary timings

  • tRCDRD, tRP, tRAS, tRC - define how fast the controller can open/close rows during scattered reads.

  • tRRD_S / tRRD_L, tFAW - limit the rate of row activates across banks; very important for parallel read bursts.

  • Read-to-read tertiary timings (RDRDSCL, RDRDSC/SD/DD) - fine-tune transitions between reads in different banks/rows.

• Other

  • GDM, CMD rate - can slightly help or hurt effective bandwidth at high frequency.

  • VDIMM / VDDQ / MC voltage - allow stable aggressive timings and frequencies.

4. Write MT (GB/s) - Multithread write bandwidth

What it means
Write MT measures how fast your memory can accept data from the CPU when several threads are writing small blocks all over the buffer. This is the “how quickly we can update world state” side of memory performance.

How it feels in games
Low Write MT can show up as hitches during autosaves, heavy streaming, lots of dynamic objects, or anything that involves frequent updates to buffers and world data.

What affects it

• Primary / secondary

  • tRCDWR, tRCDRD, tRP, tRAS, tRC - core timings for row open/close during write-heavy workloads.

  • tWR (Write Recovery) - how long a row must stay open after a write before it can be precharged; very important for write throughput.

  • tWTR_S / tWTR_L, tWRRD, tRDWR - transitions between writes and reads; even in write-focused workloads, mixed operations still exist.

  • WRWR SC/SD/DD timings - micro-transitions between sequential writes in different banks.

• Frequencies / other

  • MCLK, UCLK, FCLK - the usual foundation.

  • VDIMM, VDDQ, MC voltage, VSOC - often the difference between being able to tighten write-related timings or not.

5. Local P50 (ns) - Row-hit latency when data is “already open”

What it means
Local P50 measures how fast DRAM responds when access is more local: the controller often hits already open rows (row hits). This is close to a best-case “hot row” scenario.

How it feels in games
Think of this as the “sweet spot” where your workload lines up nicely with the DRAM layout. Lower Local P50 means behavior closer to L3-like smoothness when the working set fits well into caches and into already open DRAM rows.

Most relevant timings / settings

• Primary

  • CL, tRCDRD - even with a row hit, column latency still matters.

  • tCWL - influences write paths, which indirectly interact with reads in mixed patterns.

• Tertiary / micro-timings

  • RDRDSCL, RDRDSC/SD/DD - fine-grain timings for sequential reads within “nearby” addresses; very relevant for local patterns.

  • WRWRSCL / WRWRSC/SD/DD - if the game mixes reads and writes in the same region, these show up too.

• Platform

  • MCLK / UCLK (1:1) - strong impact.

  • CMD rate, GDM - switching from 2T/GDM On to 1T/GDM Off can reduce Local P50 slightly at the cost of stability margin.

6. Scattered P50 (ns) - Row-miss latency when everything is spread out

What it means
Scattered P50 is the median latency when accesses are spread across different rows and banks, forcing the controller to constantly open and close rows. This is much closer to “open-world chaos” than to a neat, local pattern.

How it feels in games
The bigger the gap between Local P50 and Scattered P50, the more your system will suffer in badly cached, wide scenes: huge maps, crowded areas, complex streaming.

Key timings

• Primary

  • tRP - precharge time; with frequent row misses, this becomes critical.

  • tRCDRD / tRCDWR, tRAS, tRC - define the full open→read/write→close cycle for a new row. This is classic row-miss territory.

• Secondary

  • tRRD_S / tRRD_L, tFAW - control how often new rows can be activated across banks and bank groups; crucial for scattered access.

  • tRFC, tREFI - refresh events hurt even more when the pattern is already hostile to locality.

• Platform

  • MCLK/UCLK/FCLK - higher and well-tuned frequencies help DRAM recover faster from chaotic patterns.

7. MLP Eff (%) - Effective Memory-Level Parallelism

What it means
MLP Eff tells you how well the memory controller can keep many independent DRAM requests in flight at once. 100% would mean near-perfect parallel utilization, 50% means half of the potential is wasted on waiting.

How it feels in games
This is about heavy scenes where the CPU hits lots of different data at the same time - AI, physics, streaming, shadows, effects. High MLP Eff means DRAM behaves like a wide multi-lane highway instead of a single-lane road.

What drives MLP Eff

• Bank / group timings

  • tRRD_S / tRRD_L, tFAW - hard limits on how often you can open new rows in banks and bank groups; the main knobs for parallel activation.

  • tRC - affects how quickly the controller can re-cycle through banks.

  • RDRD / WRWR, RDWR, WRRD* - cross-bank and cross-operation timings that can either help or restrict how many requests are active in parallel.

• Frequencies / fabric

  • MCLK, UCLK, FCLK - the memory controller and Infinity Fabric must be fast enough to keep the queue full; a weak FCLK or poor ratio can hurt MLP Eff even if raw bandwidth looks fine.

• Other

  • VSOC, memory-controller voltage, board-specific “OC features” - can be required to push timings and frequencies to the point MLP Eff really shines.

8. R/W Turn (GB/s) — Read/Write turnaround performance

What it means
R/W Turn measures bandwidth in a mixed scenario with frequent read ↔ write switches (roughly 1:1 ratio). This is a realistic model of a game where the engine not only reads data, but also constantly updates buffers, states, and world data.

How it feels in games
If R/W Turn is low, the memory subsystem “chokes” when switching between reads and writes. You might see stutters during intense scenes where everything is being updated and read at once.

Main influences

• Cross R↔W timings

  • tRDWR / tWRRD - core timings for switching between reading and writing; tightening them boosts R/W Turn if stable.

  • tWTR_S / tWTR_L - write-to-read delays; define how soon you can read after writing.

  • tWR, tRTP - wrap-up timings for write and read operations; part of the turnaround budget.

• Primary / frequencies

  • tRCD, tRP, tRC - the classic row cycle cost; still important in mixed scenarios.

  • MCLK, UCLK - without enough frequency, aggressive timings can’t compensate.

9. Game P99 (ns) - Latency tail under “game-like” load (worst 1%)

What it means
Game P99 shows how bad memory latency gets under realistic game-style load, where additional worker threads are hammering memory while latency is being measured. This simulates a scenario where DRAM is busy, not idle.

How it feels in games
This is basically “how hard it will hitch in the absolute worst moments”: huge battles, heavy streaming, many background tasks (browser, Discord, recording) - all at once. Lower Game P99 = much more stable experience under stress.

What it reacts to

• Same timings as Lat P99, but under load:

  • tRFC, tREFI - refresh events are more painful when the controller is already swamped.

  • tRRD_S / tRRD_L, tFAW, tRC - constraints on row activation in heavily loaded bank/bank-group patterns.

  • tRDWR, tWRRD, tWTR_S / tWTR_L - R/W mixing becomes the norm under load, so these matter even more.

• Frequencies and voltages

  • MCLK/UCLK/FCLK - strong profiles with high, stable frequencies generally push Game P99 down.

  • VDIMM, VSOC, MC/VDDQ - too low voltages can cause “silent” instability manifesting as latency spikes instead of outright errors.

• OS / background

  • Power saving modes, scheduler behavior, and background software are all visible in this metric.

10. Game Stut (%) - Percentage of “game stutters”

What it means
Game Stut is the percentage of memory accesses under game-like load that qualify as stutters - i.e. they are several times slower than the “normal” latency. The threshold is derived from the median so that only truly bad outliers are counted.

How it feels in games
This is almost a direct numeric measure of “how often the game stutters”.
0.1–0.5% feels very smooth.
2–3% and higher = you’ll notice frequent small freezes even at high FPS.

What influences it

• Same things as Game P99, plus:

  • tREFI / tRFC - they strongly control how often and how long DRAM is unavailable, which is exactly what generates stutters.

  • GDM, CMD, PDM, vendor-specific power modes - some command/bus/power modes may smooth or worsen the long-tail latency distribution.

• OC strategy

  • Over-aggressive timings with insufficient voltage often give you beautiful Lat P50 numbers but send Game Stut% into orbit once the system is under real load.

11. Inter-Core (ns) - Core-to-core / CCD-to-CCD latency

What it means
Inter-Core measures how long it takes for a message to travel from one core to another (especially across different CCDs). This is more about Infinity Fabric and CPU interconnect than about DRAM itself.

How it feels in games
In highly multithreaded games (big multiplayer, complex AI, heavy physics), this shows how expensive communication between threads is. High inter-CCD latency can create strange CPU usage patterns and inconsistent frame pacing.

What actually matters here

• Platform, not DRAM timings

  • FCLK - Infinity Fabric frequency is the main knob; higher FCLK usually means lower core-to-core latency.

  • VSOC - SoC voltage that helps hold higher FCLK stable.

  • Thread scheduling / CCD layout - how Windows distributes threads across CCDs.

• DRAM timings like CL/tRCD/tRP have almost no direct impact on this metric.
  Treat it more as a CPU/interconnect reference than as a direct DRAM tuning KPI.

12. Jitter RMS (ns) - Latency noise and consistency

What it means
Jitter RMS is the standard deviation of memory access latency at idle. If Lat P50 is the “center” of your latency, jitter shows how much everything wiggles around that center.

How it feels in games
Low jitter means a system that feels predictable: maybe not ultra-fast, but very consistent. High jitter is why a PC can feel “uneven” even when average FPS looks great — you feel the inconsistency, not the mean.

What shakes Jitter

• Refresh behavior

  • tRFC, tREFI - the more time DRAM spends refreshing, the more the latency distribution gets stretched, especially at the long end.

• Bank / parallelism settings

  • tRRD_S / tRRD_L, tFAW - conservative values can force the controller to wait more often, creating distinct latency bands.

• Frequencies / voltages

  • MCLK/UCLK/FCLK - aggressive OC without sufficient voltage can increase jitter because the internal behavior becomes less uniform.

  • VDIMM, VDDQ, VSOC - a cleaner signal often equals less noise in the latency distribution.

13. Bank Thrash (GB/s) - Bandwidth under worst-case bank thrashing

What it means
Bank Thrash (GB/s) is bandwidth measured in a scenario that deliberately makes the memory controller’s life miserable: constant switching between banks, minimal locality, maximum conflicts.

How it feels in games
This models situations where the game accidentally generates a very hostile access pattern: lots of different objects, shaders, and resources all poked in a chaotic way. High Bank Thrash bandwidth means that even in this nightmare the DRAM subsystem doesn’t completely collapse.

What’s critical

• Bank / group architecture

  • tRRD_S / tRRD_L, tFAW - the primary knobs, because they limit the rate of new row activations across banks and groups.

  • tRC, tRAS, tRP - the full row cycle still matters, but the inter-bank limits dominate in this specific pattern.

• Frequencies / MLP

  • MCLK, UCLK, FCLK - high, stable clocks plus good MLP Eff are the key to surviving thrash patterns.

• Voltages / stability

  • If you push tRRD_S / tRRD_L / tFAW too far, stability usually dies before bandwidth hits its theoretical maximum.

14. Bank Thrash (ns) - Latency under bank thrashing

What it means
Bank Thrash (ns) is the same hostile scenario as above, but instead of bandwidth it reports the average latency of a single access in this mess.

How it feels in games
This is effectively the opposite of Local P50: it tells you how painful things can get when the game pattern is as unfriendly to the memory subsystem as possible. High Bank Thrash latency means that in certain nasty scenes you can see sharp drops even if other metrics look good.

What affects it

• Same bank-related timings as Bank Thrash GB/s, but here overly conservative settings directly blow up the latency:

  • tRRD_S / tRRD_L, tFAW, tRC - if you overtighten or overslack these, bandwidth might not change much, but latency can skyrocket.

  • tRFC, tREFI - refresh is extra painful when everything is already thrashing.

• MCLK, UCLK

  • Higher clocks let the controller chew through the queue faster, even in toxic patterns, as long as the timings are in a sensible range.

15. Idle Stut (per 1M) - Stutters per million accesses at idle

What it means
Idle Stut shows how many “long” memory accesses appear per million operations in an almost idle system. It’s a normalized stutter count derived from the latency histogram in a low-load environment.

How it feels in real use
This is the “mystery” behind why you sometimes feel a tiny hitch even just on the desktop or in a very light game. If you recorded at 240 FPS and watched frame-by-frame, you’d see isolated micro-freezes caused by these outliers.

What changes Idle Stut

• Refresh timings

  • tRFC, tREFI - the main drivers: too frequent and too long refresh cycles generate the long-tail events that show up as stutters.

• Power / controller modes

  • PDM and various power-down / sleep states for the memory controller can introduce isolated long-latency events when the controller wakes back up.

• Frequencies / stability

  • MCLK/UCLK/FCLK - unstable overclocks may not always crash, but they can create rare, extremely slow accesses.

  • VDIMM, VSOC, VDDQ, memory-controller voltage - if you’re on the edge, the first thing you often lose is tail stability, not outright functionality.

Control elements

Red rectangle - the ability to compare experiments with each other. In the left drop-down list, select the latest experiment, and in the right one, the one we plan to compare it with. Please note that after you have made your selection in the left and right drop-down lists, the comparison mode will automatically be activated in the parameters table and results table.

The orange rectangle allows you to select the graph display mode: curve or histogram.

The green rectangle allows you to switch between the experiment history (each experiment is automatically saved) and the trash can icon to delete the selected experiment.

The blue rectangle is a field where you can assign your own name to the experiment (it is saved automatically).

Example of step-by-step DDR5 tuning

EXPO profile, all by default

REFI: 11677 -> 65535 (max for DDR5)
There are very significant changes.

RTP: 23 -> 16 (minimum for DDR5)
RAS: 96 -> 58 (RCDRD + RTP + 4)
RC: 134 -> 96 (RAS + RP)
No significant changes, errors within the margin of error due to background OS activity.

RRDL: 15->8 (min for DDR5)
WR: 90 -> 72
WTRS: 8 -> 7
WTRL: 30 -> 24
No significant changes, errors within the margin of error due to background OS activity.

RDRDSCL: 8- > 5
WRWRSCL: 23 -> 17
RDWR: 21 -> 16
WRRD: 8 -> 4
No significant changes, errors within the margin of error due to background OS activity.

RFC: 884 (295ns) -> 540 (180ns)
There are very significant changes.

Brief conclusions:

1. Extreme timing reductions do not yield any benefits. Forget about the presets of hype YouTubers.

2. The memory controller has the right to change the timings independently, and no diagnostic utility will inform you about this. The AM5 ecosystem is very capricious and as far removed from enthusiasts as possible.

3. All distortions with extreme timings cause ECC On-Die to work more aggressively, thereby negating any performance gains due to instability. ECC On-Die cannot be disabled.

4. REFI and RFC are the only fast and proven ways to improve memory performance. Even changing CL-RCD-RP will not provide the same growth as REFI-RFC.

5. I did not consider DDR4 because it responds perfectly to changes in each timing.

6. The weakest point of AM5 is its low FCLK frequency. You can sacrifice CL-RCD-RP, but try to increase the frequency of MCLK, UCLK, and FCLK.

7. In the Game P99 and Idle Stut results table, your best friend is lower. Less is better.

KNOWN ISSUES:

* False positive of antivirus (like always).

DOWNLOAD:

LINK  (only an early access plan)

Since piracy in recent months has become widespread early access will be in Discord. If you do not have access to Discord, make sure your Patreon profile is complete. The process of granting access is automated. Also note that pirate resources may add malicious software to the archive. Use only a proven resource.

VIRUSTOTAL:

LINK