CPU Package Power at very high polling rates above power limit

[Timur Born]

Hello.

At very high polling rates HWinfo measures CPU Package Power higher than the power limit, sometimes even without the power limit sensors triggering.

These screenshots were made on my 13900K with the power limit set to 253 W:

Is this expected behavior?

 

[Martin]

This is most likely an issue of precision. The operating system timers might not be accurate at such high polling rates and system load. Also the hardware energy counter is most likely updated only at certain intervals.

 

[Timur Born]

I still wonder if measuring higher power than the power limit is an imprecision or the CPU not being capable of throttling fast enough to stay below the power limit? The reason why I even tried higher polling rates is because I encountered some loads where maximum power is reported considerably below the power limit while the PL trigger sensor reports "Yes" (like 220 W max at 1s polling with 253 W PL triggering). So I try to catch those triggers as power readings.

 

[Martin]

I don't have an exact answer for this, but certainly software cannot keep up with hardware in accuracy at such high polling rates. The HW is certainly quicker evaluating the conditions and it also depends on type of limit (PL1/2, etc.) and the respective tau which is used to average the instant energy snapshots. Constraints that handle more critical limits like power delivery/current spikes need to act much faster.

 

[Timur Born]

Thank you for the explanations.

Does HWinfo calculate power from other numbers (VID + current), or does it read out a CPU register where the CPU calculated power itself?

 

[Martin]

VID*current is never used, this would be terribly wrong. Intel CPUs have counters monitoring instant energy consumed (in Joules) and this delta is then divided by time-delta.
But there are also other telemetry options like direct VRM monitoring, so it really depends on system and its capabilities.

 

[Timur Born]

So I understand that for "CPU Package Power" the CPU reports Joules consumed per time-frame and HWinfo read out the value, divides by said time-frame and clears the CPU register (or it is automatically cleared upon readout)!?

Assuming that the energy consumed in Joules is correct then either the time-delta used for division can be incorrect or the CPU *does* use higher than power limit energy for short bursts before being able to throttle it back. Would be good to know which it is then, either measuring/calculation inaccuracies or throttling latency?!

 

[Martin]

Yes, just that the counter isn't cleared, it increments according to energy and its delta is used as well.
Have a read about the PL1/2 power limits and its tau to understand how RAPL works.

 

[Timur Born]

My settings are PL1 = PL2 = 253 W. So the default Tau of 56s is essentially unused, except for changing the trigger sensor from PL2 to PL1 after some time.

 

[Timur Born]

I compared average CPU Package Power at 100 ms and 1000 ms polling rate, running the same reproducible load (Handbrake encode). They match close enough, so I assume that the CPU power counter and time-delta likely are trustworthy while throttling isn't instant enough to keep power from increase over the power limit for short bursts.

The PL sensors not being reported as triggered "Yes" could be Hwinfo updating its display from top to bottom. So I may hit the screenshot button before the PL sensor output is updated. I also noticed that at very high polling rates the PL sensors' "Max" entry only gets clear after about 2 seconds when I hit the Clear button while idle, so maybe HWinfo is internally overloaded with these polling-rates and thus doesn't always output the PL sensor triggers in time!?