RAM overclocking causes CPU instability

[noname8365]

Whenever I overclock my RAM (including simply enabling XMP and doing nothing else), the RAM itself is stable (passes MemTest86) but the CPU fails Prime95 after a few minutes, with similar behavior as if I had overclocked or undervolted the CPU (typically CLOCK_WATCHDOG_TIMEOUT BSoD). Why is this?

If I set the voltages for System Agent, VDDQ TX, VDD2, VDD/VDDQ RAM, it does not crash, only after actually changing RAM clock freq or timings it does.

Increasing Vcore by +0.025V or +0.050V does nothing and I'm scared to go further. Underclocking the CPU also does not help.

 

Motherboard: Gigabyte Z790 AORUS ELITE AX ATX LGA1700 (ver 1.x, BIOS version = FHe)
CPU: Intel Core i9-14900KF
CPU Cooling: Noctua NH-D15, 2 fans
RAM: G.Skill Trident Z5 RGB 32 GB (2 x 16 GB) DDR5-7200 CL34 Memory

PSU: Corsair RM1000x (2021) 1000 W 80+ Gold Certified Fully Modular ATX Power Supply

[Somerandomtechyboi]

Try prime95 largeffts, tm5, hci memtest, or whatever other ram test

[porina]

I find Prime95 to be more of a stress on the IMC than regular mem testers are. I've also had systems in the past where you can run memtest as long as you like without error, but Prime95 gives an error in seconds.

 

I'd look at IMC/ram related voltages but I'm not familiar with them in the DDR5 era. In DDR4 era I'd try increasing VCCSA and VCCIO.

[noname8365]

33 minutes ago, Somerandomtechyboi said:

Try prime95 largeffts, tm5, hci memtest, or whatever other ram test

I tried Prime95 Large FFTs, and it survived for 20 minutes without errors or any threads crashing, after which I ended the test. Then I started Blend, and it BSoD'd in less than 2 minutes.

 

For reference, it does not do this when the RAM is at its default JEDEC timings.

[porina]

1 hour ago, noname8365 said:

Then I started Blend, and it BSoD'd in less than 2 minutes.

I've never ran Prime95 on a hybrid CPU and I'm assuming it will still try to run on all threads. Is that the case?

 

Ideally we need to see what FFT size was running when it crashed. This indicates the data size, and thus, relative stress levels of core/cache/ram. I see in my copy of P95 (might not be latest) Large is 352k-8192k. Data size is FFT size multiplied by 8, then multiply again by number of threads, which for 14900KF is 32. Minimum working data size is then 88MB which exceeds L3 easily, and L2 probably should be counted also and it exceeds that too. Blend goes as low as 4k FFT, which could be as low as 1MB data size easily fitting in the cache and at that low level would not hit ram.

[noname8365]

14 minutes ago, porina said:

I've never ran Prime95 on a hybrid CPU and I'm assuming it will still try to run on all threads. Is that the case?

 

Ideally we need to see what FFT size was running when it crashed. This indicates the data size, and thus, relative stress levels of core/cache/ram. I see in my copy of P95 (might not be latest) Large is 352k-8192k. Data size is FFT size multiplied by 8, then multiply again by number of threads, which for 14900KF is 32. Minimum working data size is then 88MB which exceeds L3 easily, and L2 probably should be counted also and it exceeds that too. Blend goes as low as 4k FFT, which could be as low as 1MB data size easily fitting in the cache and at that low level would not hit ram.

Blend = 52000 Lucas-Lehmer iterations of M5705025 using FMA3 FFT length 288K, Pass1=384, Pass2=768, clm=4
Large FFTs = 36000 Lucas-Lehmer iterations of M8716289 using FMA3 FFT length 448K, Pass1=448, Pass2=1K, clm=4

 

In both cases it starts 24 workers, some of which are using 2 threads (I assume it will total to 32).

[Somerandomtechyboi]

31 minutes ago, porina said:

I've never ran Prime95 on a hybrid CPU and I'm assuming it will still try to run on all threads. Is that the case?

 

Ideally we need to see what FFT size was running when it crashed. This indicates the data size, and thus, relative stress levels of core/cache/ram. I see in my copy of P95 (might not be latest) Large is 352k-8192k. Data size is FFT size multiplied by 8, then multiply again by number of threads, which for 14900KF is 32. Minimum working data size is then 88MB which exceeds L3 easily, and L2 probably should be counted also and it exceeds that too. Blend goes as low as 4k FFT, which could be as low as 1MB data size easily fitting in the cache and at that low level would not hit ram.

I had no idea what the heck the fft size even meant aside from large = rams small(est) = cpu

 

im curious if there are any other ram stress tests aside from tm5 and hci memtest, maybe something thatll put more stress on the rams

[porina]

2 hours ago, noname8365 said:

Blend = 52000 Lucas-Lehmer iterations of M5705025 using FMA3 FFT length 288K, Pass1=384, Pass2=768, clm=4
Large FFTs = 36000 Lucas-Lehmer iterations of M8716289 using FMA3 FFT length 448K, Pass1=448, Pass2=1K, clm=4

 

In both cases it starts 24 workers, some of which are using 2 threads (I assume it will total to 32).

54MB and 84MB respectively. I believe that CPU has 32MB L2 and 36MB L3 cache, so the 288k FFT could fit on CPU and not hit ram. Note it is a bit of an open question how much L2 counts towards deciding if Prime95 is hitting ram hard or not. Problem is L2 is more closely associated with cores. Actually, now you say it is 24 workers, that sounds like one per core so easier to consider it as such.

288k is 2.25MB of data. It almost fits in P-core L2 only spilling a little into L3. E-cores will run out of L2 and have to spill into L3. I don't think it should hit ram so at a loss why you get ram-related instability here. Does ram speed affect cache speed at all?

 

1 hour ago, Somerandomtechyboi said:

I had no idea what the heck the fft size even meant aside from large = rams small(est) = cpu

FFT is a type of mathematical operation which is widely used for a variety of purposes. In Prime95, it is used to do large number multiplication more efficiently than traditional methods. All you need to know is FFT size multiplied by 8 is the data size. Multiply by number of running workers for total usage.

[noname8365]

7 minutes ago, porina said:

I don't think it should hit ram so at a loss why you get ram-related instability here. Does ram speed affect cache speed at all?

For more reference, when I enabled XMP (7200MT/s, 34-45-45-115, 1.4V) Large FFTs started failing as well (worker threads crashing), MemTest86 is completely fine though even with tightened timings. However, if I only set the RAM speed to 6000MT/s in the BIOS, leaving everything else as default, it does this curious phenomenon where only Blend fails but neither Large FFTs nor MemTest86 does. I verified it once more and let Large FFTs run for over 25 minutes and there were no problems with 6000MT/s.

[porina]

I can only speculate that different size FFTs, when big enough to hit ram, can hit ram in different patterns. I know memtest and similar do different patterns to the ram, but the pattern going through the IMC could be different. P95 uses a lot of mixed reads and writes whereas memtest and similar tend to do one or the other. I believe this to be a real instability but don't have enough experience with DDR5 specifically to progress that, other than slowing down ram more - speed and/or timings.

 

It is my understanding 7200 is pushing it even on a good day, but 6000 should be much better.