• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Ryzen constantly switching between cores

Joined
Apr 9, 2018
Messages
781 (0.30/day)
I noticed this really odd core usage behavior when running games. Processor is a Ryzen 3 3100 and I'm running the 1usmus Ryzen Universal power plan.

This one was while running a game with a 1000ms polling rate:

Untitled2.png


And this one was from running Cinebench R15 single core benchmark with a faster 100ms polling rate:

Untitled3.png


So as you can see, the processor keeps jumping between using the CPU1+CPU3 and CPU2+CPU4 cores.
There's no issues with actual performance at all, but this just seems like a very inefficient core utilization with a lot of unnecessary data transfer over the infinity fabric bus (which is already a limiting factor on the Ryzen 3100 2+2 core layout).
I did some Google searches and can't find forum posts where other people have noticed this same pattern.
Thought?
 
Thats normal all cpus do that its to lower temps
 
Not sure its about lowering temps but rather to distribute the load - a good thing.
 
1. Your 3100 splits its cores across 2 CCX. Whereas a 3700X might be able to keep a 4-core load completely within a CCX, yours obviously cannot. This is by design and why the 3300X exists.

2. It is innate Ryzen 3000 behaviour since its launch last year to constantly shift the load between cores. Generally, the scheduler in Windows now and the CPPC2 mechanisms will *try* to keep loads within a single CCX, but it will always be shifting cores all the time no matter what. Something to do with the N7FF process, transistor and therefore thermal density, and the fact that shifting the load around will spread the thermals around a bit more evenly.

3. If there are concerns related to this behaviour, it's down to how the 3100 is designed, and why it's positioned as the entry-level Matisse part. If there are actual serious performance issues you notice as a result of this, buy a more expensive part.

4. Keep polling rates down if you're not actively testing something. It makes your idle hotter as you never really idle (because cores can't sleep/are constantly being brought out of sleep). For background monitoring (e.g. HWInfo, Afterburner), keep it to 2000ms or longer. 100ms is ridiculous unless you're actively trying to investigate something.

5. It used to be that the 1usmus plan was better than Windows or Ryzen Balanced in keeping light loads on the best cores. That isn't really the case any longer, and the scheduler behaves almost identically in all three power plans. Get on with your gaming and stop worrying about how the CPU firmware is designed.
 
Last edited:
5. It used to be that the 1usmus plan was better than Windows or Ryzen Balanced in keeping light loads on the best cores. That isn't really the case any longer, and the scheduler behaves almost identically in all three power plans. Get on with your gaming and stop worrying about how the CPU firmware is designed.
I dont think it does.

I noticed this really odd core usage behavior when running games. Processor is a Ryzen 3 3100 and I'm running the 1usmus Ryzen Universal power plan.

This one was while running a game with a 1000ms polling rate:

View attachment 172835

And this one was from running Cinebench R15 single core benchmark with a faster 100ms polling rate:

View attachment 172836

So as you can see, the processor keeps jumping between using the CPU1+CPU3 and CPU2+CPU4 cores.
There's no issues with actual performance at all, but this just seems like a very inefficient core utilization with a lot of unnecessary data transfer over the infinity fabric bus (which is already a limiting factor on the Ryzen 3100 2+2 core layout).
I did some Google searches and can't find forum posts where other people have noticed this same pattern.
Thought?
You cannot determine true core loading by monitoring discrete core clock or core usage during a task, and certainly MSI Afterburner is not qualified for this.
You must watch the "effective clock" of each core.


During idling or low/middle loads like simple tasks (browsing, watching movies) or a game, with CPU not fully loaded... the cores are entering into sleep C-States C1/C6. This cannot be declared by discrete clock or discrete core usage like Afterburner does.

The 3100 unfortunately has only 2 cores active per CCX for a total of 4. 2 cores cant satisfy any game so both CCXs must be utilized.

Look down below the 3600 with 3 cores active per CCX. Still 3 cores are not enough for gaming and this results in utilizing a whole CCX and 1 core from the second CCX. Although 1usmus's power plan is trying to keep loads in one (1st) CCX where most fast cores exist (2 out of 3).
Watch the avg clock of cores. All about the same.
Watch now the avg effective clocks of each CCX and all the cores in general. Also C-States residency indicating which cores are most active (C0) and which are in low power (C1) or lower power (C6) state.

The best scenario would be all fastest cores to exist in 1 CCX but this isnt the case for any ZEN2 CPU. Usuall they are scatterd across multiple CCXs. So 1usmus power plan tells Windows scheduler to load the fastest cores but also if more than 1 fast core are in a single CCX then tells the windows scheduler to keep most loads in that CCX.

Red: Fastest Cores
Yellow: CCXs

This is a log of ~85min of gaming

Untitled44.png
 
Last edited:
I dont think it does.


You cannot determine true core loading by monitoring discrete core clock or core usage during a task, and certainly MSI Afterburner is not qualified for this.
You must watch the "effective clock" of each core.


During idling or low/middle loads like simple tasks (browsing, watching movies) or a game, with CPU not fully loaded... the cores are entering into sleep C-States C1/C6. This cannot be declared by discrete clock or discrete core usage like Afterburner does.

The 3100 unfortunately has only 2 cores active per CCX for a total of 4. 2 cores cant satisfy any game so both CCXs must be utilized.

Look down below the 3600 with 3 cores active per CCX. Still 3 cores are not enough for gaming and this results in utilizing a whole CCX and 1 core from the second CCX. Although 1usmus's power plan is trying to keep loads in one (1st) CCX where most fast cores exist (2 out of 3).
Watch the avg clock of cores. All about the same.
Watch now the avg effective clocks of each CCX and all the cores in general. Also C-States residency indicating which cores are most active (C0) and which are in low power (C1) or lower power (C6) state.

The best scenario would be all fastest cores to exist in 1 CCX but this isnt the case for any ZEN2 CPU. Usuall they are scatterd across multiple CCXs. So 1usmus power plan tells Windows scheduler to load the fastest cores but also if more than 1 fast core are in a single CCX then tells the windows scheduler to keep most loads in that CCX.

Red: Fastest Cores
Yellow: CCXs

This is a log of ~85min of gaming

View attachment 172873
Thankfully all of this will be mitigated with the 5000 series.
 
Thankfully all of this will be mitigated with the 5000 series.
Yes of course but only partially. Still would have a meaning on 2 CCD SKUs (5900X/5950X) where low/middle loads must remain on 1 CCD mostly.
Also we are not aware if 5000 would have a core "perf order" numbering as ZEN2 has. If yes then this also has a meaning, to try to keep load mostly on best cores within the 8core CCX/CCD.
 
Yes of course but only partially. Still would have a meaning on 2 CCD SKUs (5900X/5950X) where low/middle loads must remain on 1 CCD mostly.
Also we are not aware if 5000 would have a core "perf order" numbering as ZEN2 has. If yes then this also has a meaning, to try to keep load mostly on best cores within the 8core CCX/CCD.
Makes sense I was thinking about the 5600X anyway as that is the focus of what I want.
 
Makes sense I was thinking about the 5600X anyway as that is the focus of what I want.
Also we are not aware if 5000 would have a core "perf order" numbering as ZEN2 has. If yes then this also has a meaning, to try to keep load mostly on best cores within the 6/8core CCX/CCD.
Minor importance compared to CCX crosstalks but still...
 
I hate to bring in Intel about a conversion specific to AMD and Ryzen.
But do the Intel chips do the same thing I'd like to see if there is any different on the way the cpu's handle single threads to cores.
 
But do the Intel chips do the same thing I'd like to see if there is any different on the way the cpu's handle single threads to cores.
Chances are it happens on Intel desktop CPU’s but since the cores are on the same Ring Bus there shouldn’t be as severe penalty to performance.
 
...since the cores are on the same Ring Bus there shouldn’t be as severe penalty to performance.
That...
And also there is no distinction between Intel cores, so this a Ryzen matter.
 
Thankfully all of this will be mitigated with the 5000 series.

I hope so. Refinement seems to be AMD's major letdown. Look no further than the classic saw-tooth temperature spikes that make your fan ramp up and down constantly, which makes the stock AMD coolers too annoying to use. They have issues with high idle power consumption (ref. my signature). Even the "Game Cache" approach of doubling the cache was a band-aid fix to cover up poor fetching optimization. At least the outright performance and stability is good, so it's not all bad.
 
I hope so. Refinement seems to be AMD's major letdown. Look no further than the classic saw-tooth temperature spikes that make your fan ramp up and down constantly, which makes the stock AMD coolers too annoying to use. They have issues with high idle power consumption (ref. my signature). Even the "Game Cache" approach of doubling the cache was a band-aid fix to cover up poor fetching optimization. At least the outright performance and stability is good, so it's not all bad.

I don't disagree on the firmware and polish, but call it for what it actually is. When you don't have a monolithic design, you compensate with large L3 caches. "GameCache" is a sorry excuse of a marketing term to refer to a feature of the design that has a rightful place. Ryzen 3000 has significantly worse DRAM latency than the last 2 generations, and the large L3s helped make sure that didn't overly impact the onward march of performance.

As for the fan spikes, we're almost at the launch of 5000, solutions are plentiful. Asus has the best BIOS implementation of hysteresis - use it. It's under the Monitor tab, at the bottom where Q-fan control is. You can adjust step-up and step-down intervals for every fan. Set a flatter fan curve to go with a 3-5second interval, and you're good.
 
I don't disagree on the firmware and polish, but call it for what it actually is. When you don't have a monolithic design, you compensate with large L3 caches. "GameCache" is a sorry excuse of a marketing term to refer to a feature of the design that has a rightful place. Ryzen 3000 has significantly worse DRAM latency than the last 2 generations, and the large L3s helped make sure that didn't overly impact the onward march of performance.

As for the fan spikes, we're almost at the launch of 5000, solutions are plentiful. Asus has the best BIOS implementation of hysteresis - use it. It's under the Monitor tab, at the bottom where Q-fan control is. You can adjust step-up and step-down intervals for every fan. Set a flatter fan curve to go with a 3-5second interval, and you're good.

I already run custom fan curves, but I've got a Noctua cooler now and so it's less audible than the stock AMD cooler anyway. It doesn't change the inherent Ryzen temperature spikes, so it's more or less a solution to solve a problem that shouldn't be there in the first place. I've done my build in preparation for upgrading to Ryzen 5000 so we'll see what the new generation is like.
 
I already run custom fan curves, but I've got a Noctua cooler now and so it's less audible than the stock AMD cooler anyway. It doesn't change the inherent Ryzen temperature spikes, so it's more or less a solution to solve a problem that shouldn't be there in the first place. I've done my build in preparation for upgrading to Ryzen 5000 so we'll see what the new generation is like.
No, custom fan curves don’t change spikes. But if you insert a hysteresis interval, a few seconds delay, all is different.
 
Back
Top