PROCESSOR_POWER_INFORMATION.CurrentMhz no longer shows CurrentMhz

[randomascii]

Windows Build Number

Win32NT 10.0.19043.0 Microsoft Windows NT 10.0.19043.0

Processor Architecture

AMD64

Memory

32 GB

Storage Type, free / capacity

C: SSD 325 GB / 2049 GB

Relevant apps installed

UIforETW

Traces collected via Feedback Hub

n/a

Isssue description

A few years ago PROCESSOR_POWER_INFORMATION.CurrentMhz could be used to tell what frequency Windows had asked your CPU cores to run at. Now it always contains the same value as MaxMhz. This means that a valuable piece of information is no longer available.

The CurrentMhz field, together with measurements of the actual CPU frequency, was previously used to detect thermal throttling but cannot be used for that anymore. Are there any plans to fix this, or are there alternate sources for this information?

I wrote a test program to demonstrate this. Source is attached. Sample output looks like this: CurrentMHz is 2808 (for CPU 0 is 2808, MaxMhz is 2808)

The throttling detection code from UIforETW, which worked for many years but no longer works, can be found here: https://github.com/google/UIforETW/blob/main/UIforETW/CPUFrequency.cpp#L182

Steps to reproduce

Use Better Battery or Better Performance power mode - not Best Performance - so that Windows will dynamically adjust the CPU frequency based on load. The actual CPU frequency can be seen on Task Manager's performance tab. Build this tool:

https://github.com/randomascii/blogstuff/blob/main/CPUFrequency/cpu_frequency.cpp

and leave it running. Previously (circa 2016) it would display changing frequencies as the CPU demands varied - it would roughly track the frequency shown in task manager. Now it just shows MaxMhz. This is a regression.

Expected Behavior

I would like to be able to query CurrentMhz, through PROCESSOR_POWER_INFORMATION or some other mechanism. This would let me detect thermal and power throttling by comparing CurrentMhz (the frequency which the OS has asked the CPU to run at) to actual frequency. For several years UIforETW used this to detect thermal throttling, and now it doesn't work. The thermal throttling detection code can be found here:

https://github.com/google/UIforETW/blob/main/UIforETW/CPUFrequency.cpp#L182

Actual Behavior

The actual behavior is that MaxMhz is always put in the CurrentMhz field, making it useless.

[randomascii]

This appears to have changed in build 21H1 (19043) because on my 20H2 (19042) machine CurrentMHz fluctuates according to load as it used to, but on my 21H1 machine it stays locked at the same value as MaxMhz.

[randomascii]

Update: the behavior in Windows 11 is the same as in build 19043. That is, the most recent version of Windows 10 and also Windows 11 never change the value returned for CurrentMhz, making detection of thermal throttling much more difficult.

[randomascii]

Further thoughts:

1) If CurrentMhz is no longer supported then the documentation should be updated to acknowledge this. 2) My reason for wanting CurrentMhz was so that I could compare it to the actual CPU frequency in order to detect thermal throttling. If this very useful technique (which I've used for 8+ years on several investigations) is no longer going to work then it becomes all the more important for the OS to expose this information (throttling status) in some other way. At the very least there needs to be some way to get it into ETW traces. Having it available from user mode would be better. Without throttling information (thermal or power) some types of performance problems become almost impossible to diagnose. That is, some mysterious performance problems are because the CPU is running at 800 MHz due to power or thermal constraints and unless information about the throttling is in ETW traces it is very hard to understand why things are running so slowly.

[ChrisOfTheLewi]

I saw this pop up in my email and while I can't comment on the originally reported problem, I did want to say that you can get the CPU frequency from ETW traces. I don't recall the specific provider off the top of my head (it's included with the CPU and GeneralProfile profiles running last I checked), but you can see it under CPU Frequencies in WPA (which shows up under Other and is documented here: https://docs.microsoft.com/en-us/windows-hardware/test/wpt/cpu-analysis ). I also find that information invaluable in tracking down performance issues fairly often. Hopefully this can help you out while waiting on a resolution to your reported problem.

[henrikand]

I work on Chrome and would also very much appreciate if the original support in Windows was restored to enable me to use user-mode (public and documented) APIs and track when throttling happens. There is support on macOS to track the CPU_Speed_Limit metric described in https://discussions.apple.com/thread/252039204 and it would be great if we could match this on Windows.

[randomascii]

It sounds like CurrentMhz is not going to be coming back, due to changes in how the CPU and OS coordinate to choose CPU frequencies.

However the underlying issue of needing a way to detect thermal throttling remains. In order to focus on that underlying issue I filed a separate github issue at https://github.com/microsoft/Windows-Dev-Performance/issues/101

This one can probably be closed.

[AvriMSFT]

Thanks Bruce for following up. I'll close this issue and add updates to #101