[Bug?] CPU Core Counts >=64 Measure=CPU & UsageMonitor Wrong

[Copteur]

Thanks everyone for the discussion and help! I have adapted my meter to use the "Processor Information/% Processor Utility" counter as suggested by Yincognite and this indeed fixed the problem.

As also noted by SilverAzide, use of this counter does result in greater than 100% utilization fairly often on my AMD EPYC 7742 System. I do not find this useful. It would be great to know the maximum possible value so I could perhaps control this using MinValue/MaxValue on the Measure UsageMonitor Plugin but don't see how to find this out.

Now that there is an identified Microsoft "official" path to measure CPU use with "Processor Information/% Processor Utility," should the basic CPU Measure transition to using this instead of "% Processor" given this 64C limitation?

[Yincognito]

Thanks everyone for the discussion and help! I have adapted my meter to use the "Processor Information/% Processor Utility" counter as suggested by Yincognito and this indeed fixed the problem.

Excellent - at least now we know that it works in practice. Thanks for confirming it!

As also noted by SilverAzide, use of this counter does result in greater than 100% utilization fairly often on my AMD EPYC 7742 System. I do not find this useful. It would be great to know the maximum possible value so I could perhaps control this using MinValue/MaxValue on the Measure UsageMonitor Plugin but don't see how to find this out.

I don't think there is a "maximum possible value", especially since we're talking about dynamic CPU frequencies and usages, in most cases. But, it seems you can have a reference point by either:

- using a PowerPlugin measure to find out the actual frequency at which the CPU operates at a given time (it works for me when I underclock the CPU from the Power options in Control Panel, I have no idea if it works for overclocked scenarios though):

Code: Select all

[MS_Power_CPUFrequency]
Measure=Plugin
Plugin=PowerPlugin
PowerState=MHz

then relate it to the "fixed" factory default value yielded by a similar Registry measure (hopefully I'm not mistaken here):

Code: Select all

[MS_Registry_CPUSpeed]
Measure=Registry
RegHKey=HKEY_LOCAL_MACHINE
RegKey=HARDWARE\DESCRIPTION\System\CentralProcessor\0
RegValue=~MHz

in order to find the ratio between the "standard" and the "actual" CPU frequency and use it to achieve your goal

- using another counter from the 'Processor Information' category, called '% of maximum frequency' (this can be read about in both the 1st and the 2nd link from the 2nd answer I linked to in my 1st reply here) to do the same and find out by how much you have to multiply 100 to get your "maximum possible value" or MaxValue, in relation to the maximum frequency (I'm not sure what is that maximum frequency though, if it's the value you can get using the Registry measure above or something else, you'd have to do a bit of testing to find out, but I believe you can also use the 'Processor Frequency' counter from the same category to find this one out)

- since, according to the description in PerfMon, the '% of maximum frequency' above can sometimes report innacurate values when the frequency is controlled outside Windows, you can use the '% Processor Performance' counter from the same category as an alternative

Other than that, if your MaxValue becomes dynamic as a result of the above, a DynamicVariables=1 line added to the measure containing it will be required so that the formula you are using in the MaxValue option can update properly.

Now that there is an identified Microsoft "official" path to measure CPU use with "Processor Information/% Processor Utility," should the basic CPU Measure transition to using this instead of "% Processor" given this 64C limitation?

This is a question for the developers. I'm not sure if they use a PerfMon based approach (like the UsageMonitor measure) to get the CPU measure values or some other C++ function instead - you can find that by checking Rainmeter's source code on GitHub -, but in theory, this would probably be the next step, yes. Brian or jsmorley might be able to better explain and weigh in just how feasible this is in practice, but for sure your confirmation on what worked is really valuable for choosing how could this be implemented further, if that's the case. At least for now, it appears one can achieve his goal using an UsageMonitor measure, though having the CPU measure adapted for more than 64 logical CPUs would be nice to have as well.

[SilverAzide]

As also noted by SilverAzide, use of this counter does result in greater than 100% utilization fairly often on my AMD EPYC 7742 System. I do not find this useful. It would be great to know the maximum possible value so I could perhaps control this using MinValue/MaxValue on the Measure UsageMonitor Plugin but don't see how to find this out.

While it is a little tedious to add even more measures (especially since you will have so many in your setup), the "Processor Information" > "% of Maximum Frequency" counter should work if you want to normalize the "% Processor Utility" counter to 100% ("% Processor Utility" / "% of Maximum Frequency" or something like that...).

I know you confirmed "Processor" > "% Processor Time" doesn't work for more than 64 cores, but did you confirm that "Processor Information" > "% Processor Time" also does not work? Because if it does you could just use that, as it that counter won't exceed 100%.

[Yincognito]

I know you confirmed "Processor" > "% Processor Time" doesn't work for more than 64 cores, but did you confirm that "Processor Information" > "% Processor Time" also does not work? Because if it does you could just use that, as it that counter won't exceed 100%.

This should work, since all counters in the 'Processor Information' category are "new ones", as in they will work for more than 64 logical CPUs. If one of those counters is confirmed to be working in practice, I see no reason why the others in the category won't. Good alternative, by the way, though choosing this would mean the OP would have to give up the very close similarity with Task Manager of '% Processor Utility' you so nicely advertised earlier (if '% Processor Time' is slightly off from the Task Manager values on his system, that is, since apparently this varies from CPU to CPU).

[SilverAzide]

This should work, since all counters in the 'Processor Information' category are "new ones", as in they will work for more than 64 logical CPUs. If one of those counters is confirmed to be working in practice, I see no reason why the others in the category won't. Good alternative, by the way, though choosing this would mean the OP would have to give up the very close similarity with Task Manager of '% Processor Utility' you so nicely advertised earlier (if '% Processor Time' is slightly off from the Task Manager values on his system, that is, since apparently this varies from CPU to CPU).

Yeah, I'm gonna go this route (i.e., UsageMonitor measure instead of CPU measure). I've rewritten my CPU Meter gadget so that -- in the next release -- on Win7 you get "Processor / % Processor Time", and on Win8 or greater you get either "Processor Information / % Processor Time" OR "Processor Information / % Processor Utility", as you prefer. So far it is working well in testing. The skin doesn't support more than 64 cores still (yet?), so it is a little bit of a moot point, but perhaps someday....

[Yincognito]

Yeah, I'm gonna go this route (i.e., UsageMonitor measure instead of CPU measure). I've rewritten my CPU Meter gadget so that -- in the next release -- on Win7 you get "Processor / % Processor Time", and on Win8 or greater you get either "Processor Information / % Processor Time" OR "Processor Information / % Processor Utility", as you prefer. So far it is working well in testing. The skin doesn't support more than 64 cores still (yet?), so it is a little bit of a moot point, but perhaps someday....

Mine supports 32 "cores" since the beginning, but somehow I didn't realize how fast this core count increased in recent years, so I might very well follow the same route too, in a future update, though I like CPU measures as well since they're so short codewise and a bit more "independent" (in terms of rebuilding the counter database). Other than that, since I like to be consistent across the skins in the suite, I wonder how to handle the fact that only the '% Processor Time' is available for the 'Process' category and whether this counter is also limited to less than 64 logical CPUs (i.e. like the global one) - maybe the OP could check this out as well, just to be sure...