Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong CPU utilization (not accounting for CPU clock muliplier) #2093

Open
ageor7 opened this issue Jun 10, 2024 · 4 comments
Open

Wrong CPU utilization (not accounting for CPU clock muliplier) #2093

ageor7 opened this issue Jun 10, 2024 · 4 comments
Labels

Comments

@ageor7
Copy link

ageor7 commented Jun 10, 2024

It seems CPU utilisation columns and graphs don't take the cores' clock multipliers into account.
As a result, System Informer falsely suggests that the CPU works closely to 100% (therefore is near-congested), even if the multipliers are, e.g. at 11 (1100MHz), with a maximum of 24 (2400MHz).

So, while CPU utilisation is correct for the CPU's given clock, it can be far from its actual capability, allowing for the wrong impression.

Windows Task Manager and Mark Russinovich's Process Explorer don't have this issue. So CPU utilisation values are, more often than not, significantly different among SI and them, adding to the confusion…

@rbeesley
Copy link

rbeesley commented Nov 18, 2024

This aligns with my findings too, SI is not reporting the correct CPU%, although I'm seeing something different than @ageor7 and it is perhaps another related issue with how CPU utilization is being calculated.

I used the method "CPU currently used by the current process" from this stackoverflow thread: https://stackoverflow.com/questions/63166/how-to-determine-cpu-and-memory-consumption-from-inside-a-process/64166#64166, and I found that the CPU my process reported matched what Task Manager and Process Explorer were reporting. SI reports significantly lower CPU usage for the process, ~3% vs. ~12%. I also used the CPU Profiler built into Visual Studio and it was reporting ~13% for the process, so while not a perfect match, it is within the expected range, and maybe instrumentation of the process accounts for the increased overhead under the profiler.

This is running on an ARM64 installation, so perhaps this discrepancy has to do with e-cores vs. p-cores, as the clock speed seems to be about 2.9 GHz vs. 3.0 GHz, and therefore clock multiplier doesn't seem to be the most likely culprit.

@MagicAndre1981
Copy link
Contributor

Task Manager’s CPU numbers are all but meaningless
https://aaron-margosis.medium.com/task-managers-cpu-numbers-are-all-but-meaningless-2d165b421e43

@jxy-s
Copy link
Member

jxy-s commented Nov 18, 2024

I recommend giving this blog post a read for some details on the subject: https://winsiderss.github.io/si-blog/2023/02/04/arm64-cycle-based-cpu.html

@rbeesley
Copy link

rbeesley commented Nov 19, 2024

@jxy-s, that was great. I hadn't read that but it certainly explains what I'm seeing.

Edit: I had "Enable cycle-based CPU usage (experimental)" enabled when I saw the reported usage. When I disabled that, the values I saw matched what was being reported elsewhere. It at least explains the discrepancy I saw with SI versus other tools.

@MagicAndre1981, it is perfectly reasonable to suggest that these cycles are meaningless, and in some ways it is like chasing the clock speed of the late 90s; it doesn't really measure what you think it does. For my purposes it does, in that I'm building a Direct3D app which may be dependent on CPU or GPU and I wanted a way of gaging how CPU utilization changes as I write it, as I'm already counting my FPS... not GPU utilization, but it's enough to provide reference points. I added my own performance metric into the app and wanted to calibrate if it was working as expected, and I was surprised to see that SI was giving me a different measurement and hence why I commented on this open issue as I thought it might be related.

Based on the responses, I believe SI is working as it should for my purposes, and I don't know if the issue @ageor7 raised is still active or not. Thank you.

@dmex dmex added the question label Dec 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants