TR Forums

Howdy y'all. I just successfully overclocked my RAM on a new Ryzen system, but it had no effect on performance. I thought this was odd, so I wanted to see how others reacted.

CPU: Ryzen 7 2700X
Motherboard: Gigabyte X470 Gaming 7 Wifi
RAM: 2x16 GB Kingston KSM26ES8/8ME (DDR4 2666 MHz ECC CL19 single-rank Micron E)

My understanding is that Ryzen greatly benefits from higher RAM clock speeds, even if the timings have to be much looser. So as a first pass, I used my motherboard's automatic overclock ("EZOT") to overclock the RAM for me. Surprisingly, higher RAM clocks had no effect on performance.

Benchmarks are:

Default: 2666 MHz, CL 19, tRCD 19, tRP 19, tRAS 43, tRC 62, CR 1T
Blender Blenchmark: 1:30
Cinebench R15: 175 single-thread, 1774 multi-thread
Corona 1.3: 2:04; 3,890,870 rays/sec
x265 0.1.4: 38.56s (29.25 fps); 38.52s (29.29 fps); 38.53s (29.27 fps); 38.53s (29.27 fps)

OC #1: 2933 MHz, CL 20, tRCD 21, tRP 21, tRAS 47, tRC 68, CR 1T
Blender Blenchmark: 1:30
Cinebench R15: 175 single-thread, 1740 multi-thread
Corona 1.3: 2:04; 3,906,290 rays.sec
x265 0.1.4: 37.55s (30.04 fps); 37.67s (29.94 fps); 37.60s (30.00 fps); 37.68s (29.93 fps)

OC #2: 3200 MHz, CL 20, tRCD 22, tRP 22, tRAS 52, tRC 74, CR 1T
Blender Blenchmark: forgot to run at this setting
Cinebench R15: 175 single-thread, 1785 multi-thread
Corona 1.3: 2:02; 3,963,260 rays/sec
x265 0.1.4: 37.79s (29.85 fps); 37.75s (29.88 fps); 37.48s (30.10 fps); 37.52s (30.06 fps)

The reason for the failure to achieve higher performance is not that that the RAM experiencing errors (which had to be corrected by the ECC, incurring a performance penalty). Windows Event Viewer logged no errors. I know that ECC is working because when I run "cmd /k wmic memphysical get memoryerrorcorrection" the output is "MemoryErrorCorrection 6", which indicates multi-bit ECC.

I did not stress-test these RAM settings to see if errors would have eventually occurred. So there's no guarantee that these settings were stable. But since no errors occurred in the time-frame in question, we know that errors weren't reducing performance.

Therefore, I found it very interesting that overclocking my RAM from stock 2666 MHz up to 2933 or 3200 had no effect on performance. From what I had read about the Ryzen, I thought overclocking the RAM would increase overall performance by at least a single-digit percent.

Could it be that the timings are too loose? Still, the timings at higher clock speeds aren't so much looser than stock, and I'd be surprised if such small increases in timings could entirely negate the benefits of a boost in clock speed.

I'm curious if anything has any thoughts or insights. Thanks.

A few thoughts...

Maybe the memory overclock isn't taking effect for some reason? Conceivable it only takes effect on a cold boot (try power cycling after changing memory timings), or that memory OC is disabled when ECC is enabled (try disabling ECC). Also try running a synthetic memory benchmark to verify that the OC is being applied.

The fact that x265 benchmark results are all almost exactly 30 Hz is suspicious. Maybe the test you ran is locked to the native frame rate of the stream?

Maybe the tests you ran just aren't limited by memory bandwidth or Infinity Fabric performance? Ray tracing and video encode are both very CPU-bound; maybe these just don't see much benefit from improved performance of the memory subsystem.

Performance gains greatly depend on the application in use IIRC. Most rendering workloads see little to no improvement with increased RAM spead, aside from Euler and Corona (which does seem to show some performance improvement on your setup).

Check out TPU's render benchmark scaling:
https://www.techpowerup.com/reviews/AMD ... sis/7.html

I suggest you test with synthetics first to confirm that you are getting better memory speeds, and then with workloads that are known to scale with RAM speed (like games!).

Check out TPU's render benchmark scaling:
https://www.techpowerup.com/reviews/AMD ... sis/7.html

OK, so it looks like going from 2666 to 3200 on the RAM has negligible effects on these types of workloads. Even for games, it appears to be very dependent on the specific game.

just brew it! wrote:

Check out TPU's render benchmark scaling:
https://www.techpowerup.com/reviews/AMD ... sis/7.html

OK, so it looks like going from 2666 to 3200 on the RAM has negligible effects on these types of workloads. Even for games, it appears to be very dependent on the specific game.

Thanks! That article was very helpful! It looks like a few games had FPS increases, but not much.
And this statement from the conclusion seems notable: "It came as a bit of surprise to us that memory speed didn't even affect performance of CPU-intensive tests, such as video-encoding in which large data streams are being pushed in and out of the main memory."

So thanks! That was really helpful!

mikewinddale wrote:

just brew it! wrote:

Check out TPU's render benchmark scaling:
https://www.techpowerup.com/reviews/AMD ... sis/7.html

OK, so it looks like going from 2666 to 3200 on the RAM has negligible effects on these types of workloads. Even for games, it appears to be very dependent on the specific game.

Thanks! That article was very helpful! It looks like a few games had FPS increases, but not much.
And this statement from the conclusion seems notable: "It came as a bit of surprise to us that memory speed didn't even affect performance of CPU-intensive tests, such as video-encoding in which large data streams are being pushed in and out of the main memory."

So thanks! That was really helpful!

That's because video-encoders are designed to operate mostly out of cache, probably L1 or L2 cache for most of their calculations.

In particular: video encoders are set up to operate on Macroblocks (which fit in a few SIMD Registers !!). Yeah, you only need one AVX512 register to fit a 8-bit 8x8 pixel Macroblock. Needless to say, many macroblocks can fit in L1 cache, so the CPU has plenty of work to do while waiting for RAM to respond.



Note: Modern CPUs execute "in parallel" with RAM. As long as the CPU has work to do in its on-board memory (Registers, L1, L2, or L3 cache), the CPU will operate in parallel with RAM.

------------

This is NOT the case with video games, or other benchmarks. Some problems are strongly RAM-bandwidth bound instead. Simple Photoshop filters (blur) are processed very quickly by the CPU, so the CPU runs out of work to do and ends up waiting for RAM IIRC. In the case of video games or databases, the vast majority of the time the CPU is just sitting around waiting for RAM to respond.

In both cases of CPU-bound and RAM-bound code, Windows will report 100% "CPU Utilization" on the threads, which makes it confusing for some people. Yes, a RAM-bottleneck will be reported as "CPU Utilization" on both Windows and Linux.

dragontamer5788 wrote:

In both cases of CPU-bound and RAM-bound code, Windows will report 100% "CPU Utilization" on the threads, which makes it confusing for some people. Yes, a RAM-bottleneck will be reported as "CPU Utilization" on both Windows and Linux.

Indeed. And this is basically a limitation of how CPU utilization is measured. If an active thread currently has control of a given core, the core is "busy" and counts towards the utilization percentage, even if it is stalled waiting for data to be read/written from/to RAM.

For higher latency operations like I/O, the thread is suspended, and the core either idled, or given to another thread. But for RAM stalls, this isn't really feasible since the overhead of doing so would be orders of magnitude more than any gains.

An exception (sort of) is SMT/Hyperthreading. If one thread on a SMT core stalls waiting for RAM access, the other thread in that physical core may be able to execute (provided it isn't also waiting on RAM). But there's no mechanism for the OS's CPU utilization measurement to track this, since as far as the OS is concerned the two logical threads in a SMT core look like two separate (and slower, if both are busy...) cores.

Modern OSes may incorporate knowledge of SMT topology into thread scheduling decisions, but they don't have visibility into how the virtual threads in a single core are divvying things up between themselves when they're running.