For simplicity, let’s say you have a single-CPU system that supports “dynamic frequency scaling”, a feature that allows software to instruct the CPU to run at a lower speed, commonly known as “CPU throttling”. Assume for this scenario that the CPU has been throttled to half-speed for whatever reason, could be thermal, could be energy efficiency, could be due to workload. Finally, let’s say that there’s a program that is CPU-intensive, calculating the Mandelbrot set or something.
The question is: What percentage CPU usage should performance monitoring tools report?
One theory is that this should report 100% CPU usage, because that CPU-intensive program is causing the CPU to consume all of its available cycles.
Another theory is that this should report 50% CPU usage, because even though that CPU-intensive program is causing the CPU to consume all of its available cycles, it is not consuming all off the cycles that are potentially available.
The argument for the first point of view is that if your system is acting sluggish, or you hear the fan turn on, you want go to a performance monitor tool and see that, “Oh, program X is using 100% CPU, that’s the problem.” If the system had used the second model, you would see that program X is using 50% CPU, and you would say, “Well, that’s not the problem, because there’s still 50% CPU left for other stuff,” unaware that the other 50% of CPU capacity has been turned off due to throttling.
While I sympathize with this point of view, I feel that reporting the CPU usage at 50% is a more accurate representation of the situation.
If the CPU were reported as a percentage of current available resources, then performance monitoring tools would not only have to record the history of the process’s CPU usage, but they would also have to record the history of the system’s throttling behavior, in order to get an accurate assessment of how much CPU the program was using over time.
In the above diagram, the blue line represents the maximum CPU currently available due to throttling, and the red line represents CPU usage as an absolute amount. At the start of the trace, the CPU is running at full power, and the program is using around 65% of that. The program’s CPU usage slowly drops, and when it gets low enough, the CPU is throttled down to 50% of maximum. The program’s CPU usage remains low for the remainder of the scenario, settling at around 35% of maximum CPU, or 70% of relative CPU.
What you expect to see in your CPU usage graph when analyzing the performance of the program is that it starts out using a lot of CPU (65%) and gradually drops to around 35%.
But suppose CPU usage percentage were relative to current CPU throttling. The graph would start out at around 65% like before, since the CPU is not being throttled. The CPU usage would slowly drop, as before, but when the system throttles the CPU down to 50%, the CPU usage graph would spike up, since its 35% usage of maximum CPU is 70% of available CPU. If you weren’t aware of this change in system CPU throttling, it would look like something happened in your program that caused its CPU usage to jump up suddenly, and remain high for the remainder of the scenario, when in fact the program’s CPU usage was low for the remainder of the scenario!
Here’s another way of looking at it: Suppose the program’s CPU usage was capped by something other than throttling. For example, maybe it’s in a job that is capped to 20% CPU. The program is using all the CPU it can, but the system limits it to 20% of the total. Should this be reported as a program running at 100% CPU? It’s using all of the CPU it has available to it, after all.
Related reading: Why your CPU usage is hovering at 50%.
It should track and show both.
And if there ever would be other ways in which the CPU is limited for the whole OS, that should also be tracked and shown.
Certainly if you can report both, then report both. But the question was “If you could report only one number, how would you calculate it?”
Jeff Stokes has also some experiments done: https://illuminati.services/2021/03/17/windows-10-task-manager-cpu-inaccurate-a-tale-of-two-metrics/#utm_source=rss&utm_medium=rss&utm_campaign=windows-10-task-manager-cpu-inaccurate-a-tale-of-two-metrics it looks like we can get more than 100% with Task Manager when e.g. Turbo Boost is active.
An app can use QueryProcessCycleTime and QueryThreadCycleTime to find how many CPU cycles it’s used.
Is there a way to find out the CPU frequency to relate these cycles to real time? And/or to get notification when the CPU gets (un)throttled?
This way we could give the full information to our users. 😉
If displaying "usage relative to 100% CPU" is misleading in one way, and displaying "usage relative to current CPU capability" is misleading in a different way, then we obviously are looking at the problem in the wrong way. It's not a data problem, it's a presentation problem.
In my NSH opinion, the correct way to reflect this is to keep all usages relative to 100% and to create a pseudo-task in the display that is assigned all CPU resources that have been removed from availability. That would mean that the display in your example would show 50% usage by...
The problem with this method is the reverse possibility – CPUs being boosted. There are many CPUs now that have a rated standard clock speed, and will throttle below that in times of overheat or simply low usage, but they will also boost above that clock speed when the CPU is being heavily utilized.
How do you display that? Does the “Throttling” show negative percentages? Or does the CPU running at standard clock ALWAYS show as being throttled?