IA Power Limit vs. CPU Power reading vs. Poll period

Timur Born

Well-Known Member
Hello. Even at 20 ms poll rate I run into this situation where HWinfo's IA Limit for PL2 stays nearly *permanently* on and effective clocks shows some throttling, while the CPU Package Power reading never hits the 253 W power limit even once. Comparing via Throttlestop software shows its Power Limits going on and off except of being permanently on.

1679570360220.png
1679570747596.png
1679571274548.png

1679570431135.png1679570440482.png

Overall it seems like the power reading is not able to catch very short power spikes even at 20 ms poll rate (all high latency sensors disabled)?

Furthermore, both effective clocks and power readings are seriously shifted in values between short and long polling rates (regardless of process priority settings)? So which one do I trust?
Here is the same load as above at 1000 ms poll rate:
1679571033396.png
1679570990105.png
1679571228320.png
 
Turns out that the Folding@home load I used for this measurement allows other processes (like HWinfo) to take over CPU load and thus lower FAH's CPU time even when FAH runs at Realtime priority and HWinfo at low/idle priority. So this seems to be why fast polling of HWinfo keeps FAH from throttling the CPU.
 
Note that the throttling indication flags are sticky and persist until an application clears them.
So if you're running multiple applications reading and resetting these flags, you won't get accurate results as they both will collide when resetting the shared indicators.
 
I originally noticed this without running other applications. Throttlestop was only added later to have something to compare. And even when TS clears the flag for itself the Hwinfo flag stays semi-permanently on. At 20 ms it sometimes says "No" for a very short time (long enough to set the Minumum to No, but short enough for Hwinfo not being able to display it or my eyes not catching the single frame update).

Based on this my overall impression is that maximum power readings in HWinfo (and other software) do not represent the real maximum spikes, because the readout is not fast enough (or integrated over the poll period?), similar to voltage readings. I thought with power readings being based on VIDs (DC LL setting) that this would be faster, wrong assumption on my part. The IA Limit indicator tells us about the limit then, so this is something I can work with.
 
The hardware reports instant energy consumed [in Jules] which is converted into power [W] as ( E(t2) - E(t1) ) / ( t2 - t1 ).
So the power displayed is the average power consumption between two sampling points.
RAPL is used to calculate the "average" power consumed filtered by respective time constant. Evaluating brief power spikes might not be relevant for limits controlling total/average power consumption, but short spikes are rather relevant for power delivery circuits (i.e. Icc,max).
 
"Average between two sampling points" might then be what makes measuring Folding@home so difficult. It running into a permanent throttling power-limit while the CPU Package Power sensor reads 7-10 W *below* the power-limit was something I didn't expect/look out for. And those "short spikes" still are long enough to keep the IA Limit sensor permanently displaying "Yes".
 
Back
Top