[BUG] UsageMonitor occasionally reports too high CPU usage for individual processes
Posted: July 10th, 2018, 12:20 am
When I discovered the new UsageMonitor plugin, I immediately started playing around with it. One of the first things I tried to make was a bar meter that showed total CPU usage (using Alias=CPU), and had colored regions within it showing how much of that usage was caused by each of the top 5 processes (using the Index= option). For the most part, the skin seems to work fine. However, it will occasionally find values for those 5 top processes which add up to more than the total usage (reported by Index=0). This always only lasts until the next time the skin updates, at which point all the values return to believable levels.
The incorrect results vary wildly from occurrence to occurrence. Sometimes, the reported total is higher than any individual process, but is lower than the sum of the first 5 indexed programs (for example, Index=0 might report 55% total usage, while Index=1-5 sums to a value closer to 62%). Other times (and this actually seems to be the more common occurrence), the total usage with be reported as 100%, and at least one of the individual processes will also show at 100% usage, with the remaining processes all showing values considerably larger than the 0% they would need for that to make sense. Once, I even managed to capture Rainmeter reporting 100% usage for ALL FIVE of the individual processes I was tracking.
One thing I have noticed is that the Index=0 (total) value is never less than any of the individual process values (although it can be equal, as I said above, when both the total and some of the processes report 100%). It's only when you add together the process values that they exceed the "total".
This error seems to occur most often when there are several processes using moderate amounts of CPU and one of them suddenly spikes (ex. when I reload a tab in Chrome while my PC backup program is running in the background), although this does not always cause it to occur. This error seems to most often occur when Chrome is the program at Index=1, but that is likely just because Chrome is the program that most often occupies that slot while I am working. The erroneous results appear regardless of whether the Rollup= option is set to 0 or 1. I have been seeing this error for the past several versions (ever since I updated to 4.2), and it is still present in the 4.2 Final Release version. I have even tried rebuilding the performance counter database using the instructions on the UsageMonitor documentation page, which seemed to have no effect on the issue.
The incorrect results vary wildly from occurrence to occurrence. Sometimes, the reported total is higher than any individual process, but is lower than the sum of the first 5 indexed programs (for example, Index=0 might report 55% total usage, while Index=1-5 sums to a value closer to 62%). Other times (and this actually seems to be the more common occurrence), the total usage with be reported as 100%, and at least one of the individual processes will also show at 100% usage, with the remaining processes all showing values considerably larger than the 0% they would need for that to make sense. Once, I even managed to capture Rainmeter reporting 100% usage for ALL FIVE of the individual processes I was tracking.
One thing I have noticed is that the Index=0 (total) value is never less than any of the individual process values (although it can be equal, as I said above, when both the total and some of the processes report 100%). It's only when you add together the process values that they exceed the "total".
This error seems to occur most often when there are several processes using moderate amounts of CPU and one of them suddenly spikes (ex. when I reload a tab in Chrome while my PC backup program is running in the background), although this does not always cause it to occur. This error seems to most often occur when Chrome is the program at Index=1, but that is likely just because Chrome is the program that most often occupies that slot while I am working. The erroneous results appear regardless of whether the Rollup= option is set to 0 or 1. I have been seeing this error for the past several versions (ever since I updated to 4.2), and it is still present in the 4.2 Final Release version. I have even tried rebuilding the performance counter database using the instructions on the UsageMonitor documentation page, which seemed to have no effect on the issue.