AMD Ryzen 9 3900XT Memory Scaling Performance Under 100 Different Tests

[bug77]

Even with Ryzen 1xxx CPUs RAM speed was not that important. Gaming was/is where you see differences, but only in CPU bound scenarios.

It's not only for gaming. If you have more than one CCX, they talk to each other over IF. If IF is clocked lower, latency will be higher. Still not visible in every scenario, but definitely not limited to gaming.
Just look upa 3950X or a Threadripper review on Anandtech if you don't believe, they have some pretty revealing latency charts in there

[intelfx]

High Speed JEDEC RAMs are expensive, but high speed XMP 2.0 RAMs are not.
They are mostly JEDEC DDR4-2133 overclocked at 1.35V.

What's the difference between "high-speed JEDEC" and "high-speed XMP 2.0"? How do you tell "high-speed that is not overclock" from "high-speed that is overclocked DDR4-2133"?

[zxy_thf]

What's the difference between "high-speed JEDEC" and "high-speed XMP 2.0"? How do you tell "high-speed that is not overclock" from "high-speed that is overclocked DDR4-2133"?

Standard vs Overclocking (even if official, but it's still overclocking).

Two ways to tell the difference:
1. When you have the modules: enter the BIOS and check their frequency without XMP 2.0 enabled;
Usually XMP is disabled by default, because this "official overclocking" is not that reliable for some reason i don't know.

2. When you don't have the module: check the voltage from their specifications.
XMP modules usually list 1.35V while JEDEC DDR4 requires 1.2V.
If you compare sever DDR4 rams with desktop DDR4 rams this would be a clear rule: server rams usually speced at 1.2V and desktops speced at 1.35V because the latter ones usually list the XMP specification rather than their non-overclocking specs.

For example: https://www.gskill.com/specification...-Specification
This module runs at 2133, 1.2V without XMP, or 4000, 1.35V with XMP.

[morfic]

If the only difference is the memory frequency, how was the latency considered in the lower than spec speeds? Not changing CAS or other sub timings would have this act very differently from a quality stick bought at the tested speed. (If this is amazing 4133/17 it will look different at still great 3800/17 vs 3200/17 or 3000/17 or 2666/17 and that's ignoring all the other combinations, we don't all know all XMP profiles of every module so some will fall into XMP profiles and adjusted timings and others will be manual, help us understand what speed was what (manual, XMP, jedec))

Could you add the latencies used at each frequency for clarity? It might help better understand what was tested here and to draw better conclusions from the results.

Thanks,

Daniel

[skeetre]

Michael, what were the timings used? Was it default timings which are cas 19 on these chips or did you tighten them?

[ntropy]

I'm happy for you that you have a good experience with slower RAM. Having a cooler, quieter computer is a valid trade off for higher performance, and you've made the choice that makes sense for you.

That being said, I don't think your anecdotes contradict any of the data we've seen from Phoronix and elsewhere regarding Ryzen memory performance.
1) Your computer probably saves at most a few watts running the memory controller & Infinity Fabric at lower clocks. But your cores are also going to draw less power if they're sitting idle waiting for data.
2) Code compilation is much more cache and storage bound than memory bandwidth or latency dependent, so I'm not surprised you don't see a difference in that workload.
3) Ryzen RAM speed only affects gaming if you're not already CPU bound. And unless you're running a top-top end GPU while gaming at low resolutions and high framerates, you won't see a difference.
4) Ryzen 3000 is a beast in compression/decompression workloads, but the public benchmarks I've seen are usually 7zip or WinRAR. On the same compression software, a 12 core 24 thread desktop Ryzen will crush a 6 core Intel mobile chip. If compression is a workload you use often, you may want to optimize your system and workflow -- are you using a modern compression format, are you using the multi-threaded options in your tools, etc.

I'm a tinkerer - so I'm happy to waste a few hours tuning memory speeds and timings just to see what the results are. For someone just wanting to get work done, a few percent in a select group of applications isn't going to be worth it. In your case, if you're happy with 2400Mhz RAM, good for you (though you might get some benefits leaving the RAM at 2400 and setting Infinity Fabric clock up to 1867 or 1900Mhz). In the future if you get a better GPU, or a high refresh rate monitor, the extra performance is there waiting for you.

Yes that is what I was thinking. At the moment the system is GPU-bound with a Vega 64, I like the GPU tho. It is more than capable to do 1080p gaming on ultra settings at high frame rates and still works with VR. Plus it is working bugfree on mesa by now and is overall well supported. So when Big Navi one day releases, I'ld got for the 3200 Mhz.

I have to admit, I never touched RAM tinkering and am not so fond with it. Increasing the infinity fabric tho, sounds intresting. From what I have read the default value of FCLK is 1 Ghz when set to auto, is that true? That would mean I could clock that manually to 1200 Mhz on my 2400 Mhz config.
Besides that I use the XMP Profiles 1 and 2 to set RAM timings in my case XMP 1 with 2400 Mhz.
What else can you recommend to tinker with?

Regarding compression, I tend to see it with package compression in the Manjaro package manager. I basically download source code that compiles lightning fast, with 30 working processes and tops and then its stuck for a long time on "compressing package". Do you know of some optimisations there, I can apply in the build file?

Thanks and Greetings.

[nranger]

...
I have to admit, I never touched RAM tinkering and am not so fond with it. Increasing the infinity fabric tho, sounds intresting. From what I have read the default value of FCLK is 1 Ghz when set to auto, is that true?

FCLK defaults to 1:1 relationship with RAM data signal clock. Since DDR is literally double data rate, the clocks are halved, i.e. DDR4-2400 runs FCLK at 1200Mhz, whereas DDR4-3600 runs FCLK at 1800Mhz. Your BIOS overclocking menu (AMD CBS, CPU Power Options, etc. -- varies by motherboard) will have an option to disable that 1:1 relationship, then an option to set the FCLK. There is a RAM access latency penalty decoupling RAM and FCLK, but if your RAM is running so slowly anyway, you'll still get a benefit to core-to-core latency and L3 cache.

Linus Tech Tips tested DDR4-2133 with a de-coupled 1900MHz FCLK here: https://youtu.be/iHJ16hD4ysk?t=119

Regarding compression, I tend to see it with package compression in the Manjaro package manager. I basically download source code that compiles lightning fast, with 30 working processes and tops and then its stuck for a long time on "compressing package". Do you know of some optimisations there, I can apply in the build file?

Arch default makepkg settings use single-threaded compression commands. Details how to change that are in the wiki.

https://wiki.archlinux.org/index.php/Makepkg#Utilizing_multiple_cores_on_compression

[ermo]

I had a 2700X and I couldn't for the life of me make it stable on an ASRock Taichi X470 with 2x16GB dual rank DDR4-3200CL14 Samsung B-die RAM. Then I upgraded to a 3900X after the 3900XT was released (because who wants to pay in the region of 20+% extra for a measly +4% in single threaded performance?!) and enabled the XMP profile and everything just worked; absolutely no fuss.

I donated the 2700X to my nephew, who's now using it with a pair of reasonably inexpensive RGB LED Corsair 2x8GB single rank DDR4-3200CL16 sticks since his ASRock B450 Steel Legend motherboard has a RAM configuration profile specifically made for those sticks.

All in all this has got to be the worst memory compatibility issue I've ever encountered. Next order of business is to see if my 2x16GB sticks will run at reasonable timings at DDR4-3600 speeds. Here's hoping.

[ntropy]

FCLK defaults to 1:1 relationship with RAM data signal clock. Since DDR is literally double data rate, the clocks are halved, i.e. DDR4-2400 runs FCLK at 1200Mhz, whereas DDR4-3600 runs FCLK at 1800Mhz. Your BIOS overclocking menu (AMD CBS, CPU Power Options, etc. -- varies by motherboard) will have an option to disable that 1:1 relationship, then an option to set the FCLK. There is a RAM access latency penalty decoupling RAM and FCLK, but if your RAM is running so slowly anyway, you'll still get a benefit to core-to-core latency and L3 cache.

Linus Tech Tips tested DDR4-2133 with a de-coupled 1900MHz FCLK here: https://youtu.be/iHJ16hD4ysk?t=119



Arch default makepkg settings use single-threaded compression commands. Details how to change that are in the wiki.
https://wiki.archlinux.org/index.php...on_compression

Thanks for the hint, I have adopted the settings regarding compression, think that will be a big help and dramatically reduce my build times .

You got me curious so I enabled the 3200 Mhz clock and set FCLK to 1600. Additionally I set the xmp 2.0 profile.
The CPU runs hotter now, about 5 - 10 °C on idle and light load and the cpu fan spins up pretty quickly. But I have to say I get higher fps in StarCitizen.

So far I suffer from the problem that in some games, the gpu just does not get utilized to its full potential. Often the gpu clock is jumping around between 40% and 80% and that is not due to shader compilation. StarCitizen and as of yesterday night The Division 2 are 2 of those candidates to have this behaviour. I so far thought it could be mesa related and while on Division I still have the effect, SC runs way smoother now, way more often running around 99% GPU utilisation.

I guess I will keep these settings, you made me curious