Weird memory timings with Ryzen 5 5600X + freezing issues?

[agent_x007]

Just to confirm, did you try forcing BCLK = 100.000MHz ?
(not through D.O.C.P. but manually setting it)

 

[ShiBDiB]

Just a little interjection.

My memory was super unreliable with my 5600x UNTIL I updated my motherboard BIOS. Now the DOCP profile runs fine.

If you updating it didn't let your DOCP profile run stable/correctly then you just got bad memory. You can go play with all the random settings in the BIOS to make it stable but not ideal, or just buy new memory.

 

[cst1992]

Just a little interjection.

My memory was super unreliable with my 5600x UNTIL I updated my motherboard BIOS. Now the DOCP profile runs fine.

If you updating it didn't let your DOCP profile run stable/correctly then you just got bad memory. You can go play with all the random settings in the BIOS to make it stable but not ideal, or just buy new memory.

What Assimilator said earlier in the thread was what I observed - the Corsair sticks didn't run well at 3600 MHz as they were not certified to run together reliably, especially in a Ryzen system.

My new RAM solves that issue, plus I'm getting more stable framerates with them.

Just to confirm, did you try forcing BCLK = 100.000MHz ?
(not through D.O.C.P. but manually setting it)

It's explicitly set to that value.
It looks like in the below screenshot (not my system): https://edgeup.asus.com/wp-content/uploads/2017/01/UEFI-1.jpg

@Ketxxx New development: discharging the motherboard's capacitors completely is actually solving the issue with the bluetooth adapter, at least "temporarily".

Check out this thread: https://answers.microsoft.com/en-us...scriptor/2af8f09f-ce33-47f8-a42a-1b55e8cf60fd

I finally fixed it though. If anyone else comes across this, I drained the battery completely so that it wouldn't respond at all when I hit the power button. I then held down the power button for a minute. Plugged in, booted to windows, hard shutdown, then logged in, and now the device was an "unknown device" with a valid hardware ID. This allowed me to go in, update the driver, and it installed. Yay!

I tried (part of) this as I was also getting a "device descriptor failed" (albeit mine is not a laptop, but same principle) and the adapter works again. No doubt it might conk out again in the near future.

 

[VuurVOS]

What Assimilator said earlier in the thread was what I observed - the Corsair sticks didn't run well at 3600 MHz as they were not certified to run together reliably, especially in a Ryzen system.

My new RAM solves that issue, plus I'm getting more stable framerates with them.

Unstable frame rates could be caused by the high tRFC of 550 ns Normally it is 350 ns which is defined in your SPD & XMP profile.

 

[cst1992]

Unstable frame rates could be caused by the high tRFC of 550 ns Normally it is 350 ns which is defined in your SPD & XMP profile.

You definitely know more about that than I do, my friend.

New update.

If any of you are into software development, you must have gone through a "different error" moment. While troubleshooting something if you get a different error than what you have been unable to resolve, that in itself is some kind of achievement.

For me, I got another crash, but this time a "different" Kernel-Power event than I've been getting so far - that is "all zeros":

This time I got a non-zero BugcheckCode and BugcheckParameter1, meaning either of three things:
1. The old freezes are gone, and this is the error I'll be getting from now on
2. This is happening in addition to the old freezes
3. This is a random non-recurring event.

Bug Check Code Reference - Windows drivers

This section contains descriptions of the common bug checks, including the parameters passed to the blue screen.

learn.microsoft.com

Bug Check 0x101 CLOCK_WATCHDOG_TIMEOUT - Windows drivers

Learn how the CLOCK_WATCHDOG_TIMEOUT bug check indicates that an expected clock interrupt on a secondary processor isn't received within the allocated interval.

learn.microsoft.com

As for the error itself: if these two links are to be believed, then 257 (0x101, in other words) refers to CLOCK_WATCHDOG_TIMEOUT and parameter 1 (clock interrupt time-out interval, in nominal clock ticks) is 2 (i.e. 0x10).

What is this, an overclocking error? I am not overclocking the CPU; I'm only setting the memory DOCP profile.

 

[oobymach]

Just to confirm, did you try forcing BCLK = 100.000MHz

It's explicitly set to that value.

Has it always been that way? I found in my bios (I'm not using Asus mobo like you mine is Msi) that forcing bclk to 100mhz instead of using auto caused issues, I can't remember exactly what but it was bad and going back to auto (which uses spread spectrum I think it's called) it was normal again.

Auto will not go over 100mhz and tends to stay a hair under that and changes the frequency frequently to prevent locking up.

 

[VuurVOS]

What is this, an overclocking error? I am not overclocking the CPU; I'm only setting the memory DOCP profile.

Indirectly you are doing a CPU overclock since memory is running quicker then the supported (3200MHz). Also FCLK and UCLK are running higher than designed.

Maybe it is wise to increase LLC (Load Line Calibration) in bios to value 3 or 4.

 

[Ketxxx]

@Ketxxx New development: discharging the motherboard's capacitors completely is actually solving the issue with the bluetooth adapter, at least "temporarily".

Check out this thread: https://answers.microsoft.com/en-us...scriptor/2af8f09f-ce33-47f8-a42a-1b55e8cf60fd

A stagnant charge of electricity in the capacitors can do weird things sometimes. If you haven't got one investing in a surge protector could be a good idea in your case. I'd probably be measuring how much electricity is coming from your wall socket as well and monitoring how stable that supply is. Have you had chance to open something like ZenTimings, screenshot what it says, then power down, reset the CMOS, boot up and run ZT again to see if the timings are the same? Identifying if your board is setting different timings on a CMOS reset and from a cold boot will go a long way to diagnosing the root cause(s).

Has it always been that way? I found in my bios (I'm not using Asus mobo like you mine is Msi) that forcing bclk to 100mhz instead of using auto caused issues, I can't remember exactly what but it was bad and going back to auto (which uses spread spectrum I think it's called) it was normal again.

Auto will not go over 100mhz and tends to stay a hair under that and changes the frequency frequently to prevent locking up.

AFAIK this is only true for MSI. MSI think the BCLK value should be 100MHz however a lot of other manufactures when the setting is left at "Auto" runs over that - up to about 105MHz I think, as a cheap way of making their boards look "better" in reviews. Unless you have an exceptionally picky piece of hardware then enabling or disabling spread spectrum should not impact stability at all SS is just used to potentially reduce EMI (Electro Magnetic Interference) in the system at the cost of target frequency on CPU/RAM. It's only really worth trying if experiencing EMI with nearby devices or on-board audio.

 

[A Computer Guy]

So far I gathered...
- the reinstalled os may have helped
- the new memory helped
- the bios option helped (turned off PBO Fmax Enhancer)

Someone had a suggestion of fixing BCLK to 100. Did you verify the value of BCLK somehow and that it's running somewhere 98% to 100% (inclusive) or spread spectrum enabled in UEFI?

 

[cst1992]

Has it always been that way?

Yes.

Maybe it is wise to increase LLC (Load Line Calibration) in bios to value 3 or 4.

I'll check what that is set to. I did have the option of getting 3200 RAM - was buying 3600 RAM a mistake?

@Ketxxx I saw that the command rate is set to 1T. I haven't set it to 2T yet. Do you think it could still help?

If you haven't got one investing in a surge protector could be a good idea in your case.

I'm using one. Be kinda stupid not to do so for a build this expensive.

Have you had chance to open something like ZenTimings, screenshot what it says, then power down, reset the CMOS, boot up and run ZT again to see if the timings are the same? Identifying if your board is setting different timings on a CMOS reset and from a cold boot will go a long way to diagnosing the root cause(s).

I've run ZenTimings before, not specifically like you said, but I have (also posted screenshots in this thread). I haven't seen anything I wasn't expecting, except that the values of VDIMM and MEM VTT show up as N/A.

Unless you have an exceptionally picky piece of hardware then enabling or disabling spread spectrum should not impact stability at all

SS is set to Auto at the moment.

- the reinstalled os may have helped

Maybe. But only because I guess the old one was getting corrupted (the infamous slow freezes). Most probable cause of that was the Corsair modules + (maybe) improper shutdowns due to system freezes.

- the new memory helped

Definitely.

- the bios option helped (turned off PBO Fmax Enhancer)

Yes and no. The system runs OK for 24 hours now instead of 1, 2, or 3 hours at a time. I still have no reason to believe anything is fixed long term.

Someone had a suggestion of fixing BCLK to 100. Did you verify the value of BCLK somehow and that it's running somewhere 98% to 100% (inclusive) or spread spectrum enabled in UEFI?

SS is set to Auto, and BCLK is set to 100.0000 (exactly like in this screenshot: https://edgeup.asus.com/wp-content/uploads/2017/01/UEFI-1.jpg)

 

[oobymach]

Setting the bclk manually may override spread spectrum, try setting bclk to auto just to test.

 

[VuurVOS]

I'll check what that is set to. I did have the option of getting 3200 RAM - was buying 3600 RAM a mistake?

No, I still would have bought 3600MHz for the extra bandwidth

 

[Ketxxx]

I've run ZenTimings before, not specifically like you said, but I have (also posted screenshots in this thread). I haven't seen anything I wasn't expecting, except that the values of VDIMM and MEM VTT show up as N/A.

Let me know when you have checked if any memory timings change after a CMOS reset and cold boot, that kind of thing always causes absolute mayhem and it's insane manufacturers have deemed this acceptable. Wrestling with ones own hardware at stock is not something anyone should be having to do because the hardware just "feels like doing something else".

SS is set to Auto at the moment.

Always is. Disabling it will give you a more on the nose 100MHz BCLK, whereas with SS enabled a 100MHz setting will fluctuate more, ordinarily in the range of 97-99.8MHz. I tend to disable SS as never in all my years have I come across a scenario where it has helped at all. I safely lump it in the feature creep placebo category these days.

I saw that the command rate is set to 1T. I haven't set it to 2T yet. Do you think it could still help?

It should do. Trying several things at once isn't really going to help you narrow down the exact causes though. If I were you I'd start with disabling PBO and setting an all-core multiplier of 37x, as well as disabling Gear Down and setting a 2T command rate. That way you should be able to rule out stability issues with the CPU and RAM. Just have HWinfo64 running logging every 10 seconds or so that way if the system crashes it will be easy to see the readings for voltages, temperatures, and power draw. I'd also be taking the CPU out, inspecting it and the socket and re-seating it in cases like this to be absolutely sure nothing got on the CPU pins or in the CPU socket and that the mounting for the CPU cooler is absolutely perfect. Long time ago now but I had issues not unlike you are experiencing, turned out somehow a hair had gotten on the SATA pins of the drive I was using at the time. Blew it out, connected the SATA power cable back up, and that was it. No more problems.

 

[A Computer Guy]

Yes.

I'll check what that is set to. I did have the option of getting 3200 RAM - was buying 3600 RAM a mistake?

With DOCP enabled have you tested down clocking your ram to DDR4-3200?

 

[cst1992]

I will have to do so manually - It's not in the presets.

I could only set some of the timings seen via HWInfo, but, yeah.

 

[Ketxxx]

Should be easy enough logging with HWinfo64 but finding and selecting just the important things to log will probably be a pain in the arse as the software isn't exactly well laid out like that when configuring the sensor logs. Anyway, start with setting that 2T command rate and manual 37x multiplier on the CPU. Ideally dial in the XMP timings for your memory (including subtimings) manually to ensure the board isn't doing anything funky with the timings behind your back, then it's back to testing.

 

[cst1992]

Setting the bclk manually may override spread spectrum, try setting bclk to auto just to test.

I'm looking at the BIOS settings now - there is no dropdown. There's only a field and it's inputted 100.0000 by default with a note that you can set it 96.0 - 118.0.

Now testing with the following changes:

• CPU Core Ratio hard-set to 37.00 from "Auto". Basically a hard set of maximum 3700 MHz for all cores even for benchmarking. Resulting in all-core 21% hit compared to original and 13% post setting PBO Fmax Enhancer to Disabled.
• Command Rate set to 2T.
• Gear-Down Mode set to Disabled.

If the crashing is being caused by the CPU getting set too high a clock (and not from the PBO Fmax Enhancer setting) then this should DEFINITELY not crash the computer with the CLOCK_WATCHDOG_TIMEOUT error.

This is in addition to other things such as setting PSU idle current to Typical that were done previously.

Ideally dial in the XMP timings for your memory (including subtimings) manually to ensure the board isn't doing anything funky with the timings behind your back, then it's back to testing.

Looking at those with HWInfo as well - look okay to me.

 

[VuurVOS]

@cst1992
I think you are currently wasting your time with this. You had those freezes with your Corsair memory when running 2666MHz as well during our chat in PM.
The processor was running within specs and you still had those strange freezes.

Did you already do the clean install without installing any 3rd party software as suggested on last Thursday?

 

[3x0]

The processor was running within specs and you still had those strange freezes.

There's still chance the CPU is faulty and can no longer sustain stock clocks. You'd be surprised how many Ryzen CPUs I've seen exhibiting strange instabilities. @cst1992 did choose correctly to try and exclude that possibility.

 

[VuurVOS]

There's still chance the CPU is faulty and can no longer sustain stock clocks. You'd be surprised how many Ryzen CPUs I've seen exhibiting strange instabilities. @cst1992 did choose correctly to try and exclude that possibility.

OCCT or Core Cycler would have reported errors but it didn't. CPU is very likely not the culprit for the slow freezing system issue.
Many in this thread claimed Corsair memory was the culprit for those strange slow freezing issues and replacing the memory with another brand would fix it.

His system worked fine from 30 october till 11 november after the clean install. Then those slow freezing system issue popped up on regular base again.
I conclude software was installed after some time and the culprit was reintroduced on that system.

 

[cst1992]

@VuurVOS There are multiple things at fault here. You are right that the system instabilities were the reason for the slow freezes, but those don't occur anymore after the new memory is installed. I haven't had a single slow freeze or stuttering problem after the Patriot memory switch.

Now the points of failure are the random instant freezes and the CLOCK_WATCHDOG_TIMEOUT error - Kernel Power bug code 257. I know it's a slow process because it takes 24 hours now to even check if a particular fix worked or not.
To recap what I know at this point: the instant freezes were delayed from 1-2 hours after a reboot to 8-24 hours after a reboot because of the PBO Fmax Enhancer fix. What my suspicion is is that one side effect of that fix is the max boost clocks were reduced from 4500-4700 in Cinebench to 4100. Now we've set it to hard stock (3700) to see if the issue still occurs with CLOCK_WATCHDOG_TIMEOUT.

Another suspicion is something is causing the power supply to cut out (Kernel Power event with all zero error codes). If it has to do with the BIOS e.g. C-state Control or the idle current set to Low instead of Typical which the PSU cannot handle, I want to rule that out too.

Now testing with the following changes:

• CPU Core Ratio hard-set to 37.00 from "Auto". Basically a hard set of maximum 3700 MHz for all cores even for benchmarking. Resulting in all-core 21% hit compared to original and 13% post setting PBO Fmax Enhancer to Disabled.
• Command Rate set to 2T.
• Gear-Down Mode set to Disabled.

@Ketxxx these changes didn't work. If the 2T command rate and GDM were related to memory, I think we can rule memory or the IMC out - it's simply not the issue.

 

[wNotyarD]

@cst1992 how easy would it be for you to borrow another Ryzen 5000 (or at least 3000) to test your rig with?

 

[cst1992]

Not very. I don't know anyone that uses one (except my cousin, but he lives in the US).

 

[VuurVOS]

How is the powergrid in your region? Do you have power outages or fluctuations?

 

[cst1992]

Sometimes I get an outage if they are doing some work on the grid or it's stormy outside.