locked
Microsoft Taskmanager show wrong CPU Usage !!! RRS feed

  • General discussion

  • Hi,

    some days ago, when analyzing another problem, i stumbled upon a fatal error in the CPU performance display in the Microsoft task manager. I wrote a little bit about this problem in the following post.

    https://community.spiceworks.com/topic/2269972-weird-4gbit-s-nic-limit-without-rss?page=1#entry-8853...

    In summary: for me, the task manager as well as the resource monitor and the performance monitor do not show the correct CPU utilization.

    Here is an example.

    I start a test and the CPU display of core 0 climbs to 100% in Task Manager.



    The Resource Monitor shows the same thing.



    Only the performance monitor shows the correct load, but the display it "inconsistent".



    The processor load is normally shown up to max. 100%, but my core 0 run according to the performance monitoring with up to 120%. 😮🙃

    The Process Explorer shows the correct utilization of my core 0.


    HWiNFO also shows the load correctly.


    I suddenly had the following apprehension.
    If you cannot correctly measure the utilization of a system, so it's not possible to control its performance properly. 🤢🤮

    So I immediately opened a support ticket at Microsoft by telephone and then described the problem accordingly by email.

    A few hours later I received an email with the following text. "Dear Mr. Fuchs, your support case has been closed."

    ???
    That can not be true. 👿

    Dear Microsoft, determining and displaying the CPU load of a modern processor based on its base frequency is anything but not a wise idea today. Just take a look at this …

    https://ark.intel.com/content/www/us/en/ark/products/series/195734/10th-generation-intel-core-i7-pro...

    But this time please not only look at the base clock rate but also at the Max Turbo Frequency. 😉

    This also applies to the server processors …

    https://ark.intel.com/content/www/us/en/ark/products/series/192283/2nd-generation-intel-xeon-scalabl...

    Regards from Germany

    Alex

    Saturday, May 9, 2020 7:52 AM

All replies

  • Hi,

    I just did another test to show the consequence of the wrong CPU load calculation.
    For this test I set the CPU of my workstation to the lowest performance level that was possible for me. The background is the following, I would like to provoke load balancing via RSS due to the low CPU performance.

    According to my RSS configuration for the corresponding NIC, cores 0, 2, 4 and 6 can be used to process the network load.

    The IndirictionTable is filled, so RSS is actually configured correctly and ready for use.
    The RSS load balancing profile with "Closest" is also correctly selected for active load balancing.

    Actually it shouldn't go wrong now when I try to move some load over the 10G NIC, actually ....

    Before the test, my system load looks like this.


    I quickly generate the network load via IOmeter and you can see the result.


    As you can see, only core 5 (marked in red) is in use and the throughput hangs at ~ 5.5Gbit / s, the other three cores that are available are not used by the RSS load balancer.

    The reason for this is simple, according to the wrong performance assessment von Windows (Task Manager & Co), the core 5 is utilized at ~ 20%, so there is no reason to act from the perspective of the RSS load balancer. But that's absolutely wrong, in truth this core is currently 100% busy!

    Thus, any load balancer that depends on Windows' own CPU performance determination no longer works properly.

    In sum, this means that if the CPU runs at a lower clock rate than the base clock, then a possible overload of the CPU cores is currently not correctly recognized and may not be throttled or balanced in time. If the CPU again works with a higher clock rate than the base clock, then Windows does not correctly recognize this additional performance and may prematurely indicate a CPU overload where there is actually none.

    That is what I mean by a "fatal error". 😉

    Regards from Germany

    Alex
    Saturday, May 9, 2020 7:55 AM