DDR4 Memory Tuning

For this experiment I wanted to find out how much performance improvement could be achieved by conservatively overclocking the DDR4 memory in the linux PC. I worked through much-recommended DDR4 OC Guide and settled on a memory timing configuration that appears to be stable as well as measurably faster.

The DIMMs are the cheap Silicon Power 3200MT modules that are only rated to CL22 (JEDEC timings) however I was able to clock them up to 4000MT on "Auto" timings (i.e., CL26) although I eventually settled on a frequency of 3600MT since my 5700X's FCLK wouldn't boot reliably at speeds higher than 1800MHz and I desynchronizing the FCLK from MCLK/UCLK appeared to result in worse performance despite the higher MCLK (as predicted by several people online). At 3600MT I was quite pleased to be able to achieve a stable 18-18-18-18-34 timing which is comparable to more expensive modules from overclock-focused brands.

I wanted to avoid damaging my hardware or spending excessive time finding the "best possible" overclock timings as my focus at this stage is really just on learning how much might possibly be achieved through overclocking. Therefore I left the memory controller in gear-down mode (no odd-numbered timings) and didn't increase memory voltage above 1.35v.

Benchmark Results

ripgrep

The ripgrep benchmark appears to be a little inaccurate as the 3600MT Auto timings with synchronized FCLK:UCLK:MCLK should have been faster than the 3200MT Auto timings configuration, but we do at least start to see here a pattern that will persist for the rest of the results - that 4000MT Auto is faster than 3800MT Auto, but both of them are substantially slower than even 3200MT Auto timings. This is because 3800MT is the point where the motherboard decides to run FCLK at half the speed of the memory chips, and the performance degredation is so great that even clocking up to 4000MT isn't enough to compensate.

git status / git log

The "git status" benchmark provides a similar picture to ripgrep, however the slightly longer "git log" benchmark starts to show a performance pattern that will persist for the remainder of the longer-running benchmarks: the manually tuned (overclocked) 3600MT timings are measurably faster than 3200MT Auto, 3600MT Auto will be similar to 3200MT Auto, and 3800MT or 4000MT will be the slowest timings of all.

For example, in the "git log" benchmark, 3600MT Tuned is 4% faster than 3200MT Auto, and 3800MT Auto is 2% slower than 3200MT Auto.

mypy / pytest empty / pytest single

In the last 3 benchmarks we see that 3600MT Tuned timing is 3.2%, 3.5% and 3.3% faster than 3200MT Auto configuration. This is a nice improvement, but not at all noticeable in day-to-day use of the PC.

Overclocking can be a tedious and time-consuming process. Was it worthwhile overclocking at all? What about manually tuning to find the fastest possible timings? The 3600MT Auto configuration provided improvements of 0.8%, 1.0% and 0.5% over the 3200MT Auto configuration. This suggests that the total possible improvement from any memory overclocking on Zen 3 will be 3-4% and we can get a quarter of that just by finding the maximum FCLK for the CPU and running the memory + memory controller at the same speed. This latter approach is much faster than the binary search of stability tests required to find the lowest value for each timing parameter.

Conclusion

DDR4 Memory overclocking on Zen 3 CPUs seems unlikely to ever produce more than single-percentage performance improvements. A substantial part of that improvement can be achieved just by finding a maximum memory speed achieveable without desynchronizing FCLK:UCLK:MCLK. However, it has been personally very satisfying to crank a pair of budget memory modules up to speeds comparable to high-end memory modules.