Increasing RAM speed leads to CPU issues and performance problems.
Increasing RAM speed leads to CPU issues and performance problems.
When I push my RAM to higher speeds, it remains stable and passes tests like MemTest86. However, the CPU struggles with Prime95 after a short time, showing signs of stress similar to overclocking or underclocking. Adjusting voltages for different components doesn’t cause issues, but tweaking RAM clock frequency or timings does. Raising the Vcore slightly has no effect, which worries me. Lowering the CPU speed also doesn’t help. The motherboard is a Gigabyte Z790 AORUS ELITE AX ATX LGA1700 with BIOS version FHe.
Run prime95 largeffts, tm5, hci memtest or any other memory test you prefer
I consider Prime95 more demanding on the IMC than typical memory testers. I've experienced systems where running memtest without issues can still trigger errors quickly. I'm curious about IMC/ram related voltages, though I'm not well-versed in them for DDR5. In the DDR4 era, I'd experiment with adjusting VCCSA and VCCIO.
I used Prime95 Large FFTs and managed to run smoothly for about 20 minutes without any issues or crashes before I stopped the test. After that, Blend froze within two minutes. For comparison, it doesn’t behave this way when RAM settings match the JEDEC specifications.
I've never tested Prime95 on a hybrid CPU before, so I'm guessing it will still attempt to run with all threads. We should check the FFT size during the crash to understand the data volume and stress levels across cores, cache, and RAM. In my copy of P95 (possibly outdated), the large value is 352k–8192k. The data size equals FFT size times 8, then multiplied by the number of threads—about 32 for a 14MHz core. The minimum working data is around 88MB, which easily goes beyond L3 and probably also L2. At very low settings like 4k FFT, it could drop to as little as 1MB, fitting comfortably in cache without hitting RAM.
Blend value = 52000. Lucas-Lehmer iterations for M5705025 with FMA3 FFT size 288K, Pass1=384, Pass2=768, clm=4. Total iterations = 36000. Lucas-Lehmer iterations for M8716289 using FMA3 FFT size 448K, Pass1=448, Pass2=1000, clm=4. Starting from 24 workers, some with 2 threads (expected total ~32).
54MB and 84MB respectively. The CPU features 32MB L2 and 36MB L3 cache, meaning the 288k FFT could reside on the CPU without needing to access RAM. It remains uncertain how much L2 contributes to determining if Prime95 is heavily accessing RAM. The issue lies in how L2 relates to cores—currently, it’s mentioned as 24 workers, suggesting roughly one per core, making it simpler to analyze. The 288k fits within a P-core L2, only slightly spilling into L3. E-cores will eventually run out of L2 and must move data to L3. It seems unlikely the program hits RAM intensely here. Does RAM speed influence cache performance? FFT is a mathematical technique often used for large number multiplication more efficiently than conventional methods. What matters is multiplying the FFT size by 8 to get the data size, then by the number of running workers for total usage.
For better understanding, when I turned on XMP at high speeds (7200MT/s, 34-45-45-115, 1.4V), large FFTs began to fail too—worker threads stopped working. MemTest86 performed normally even with adjusted timing. On the other hand, setting RAM speed to 6000MT/s in BIOS while keeping everything else unchanged caused this odd issue: only Blend failed, but neither Large FFTs nor MemTest86 were affected. I confirmed it again and ran Large FFTs for more than 25 minutes at 6000MT/s without any issues.
I suspect varying FFT sizes can affect memory access in distinct ways. I’m familiar with memtest and similar tools that use different patterns, but the sequence through the IMC might differ. P95 relies heavily on mixed reads and writes, whereas memtest and others tend to focus on one type. I think this could indicate a genuine issue, though I lack sufficient experience with DDR5 to confirm. Beyond merely reducing speed, improvements in timing or performance would be more promising. I believe 7200 is already pushing limits under good conditions, while 6000 should perform significantly better.