winsiderss / systeminformer

A free, powerful, multi-purpose tool that helps you monitor system resources, debug software and detect malware. Brought to you by Winsider Seminars & Solutions, Inc. @ http://www.windows-internals.com
https://systeminformer.sourceforge.io
MIT License
11.12k stars 1.41k forks source link

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

Open ageor7 opened 5 months ago

ageor7 commented 5 months ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

@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.