IMPORTANT Explaining the AMD Ryzen "Power Reporting Deviation" -metric in HWiNFO

In that case yes your board is very off in reporting Power. Even so, the CPU does not exceed its limits. Your CPU has 125W PPT limit, and on your screenshot we see a true power of just 100W (67 / 0.67 = 100)
Its not Gigabyte specific but maybe BIOS version specific. My X570 AorusPro has a 91~94% PRD.

This is under R20
PPT reports 85W with 92% PRD (85 / 0.92 = 92W)
My 3600 has a 88W PPT limit but because of low temp the CPU allow itself to go a little over 88W.

View attachment 5942
I opened a support case with Gigabyte regarding this. We’ll see what they say. I’m currently running F12 BIOS but F13 beta is already in testing. Maybe it’s just related to current BIOS/AGESA.
I don’t like my 80C temps as well but I guess that’s the best a CoolerMaster 212 can do.
 
okay i ran cinebench r23 multi core and this is the outcome while i was running it :
my pc is on stock, nothing modified on bios other than enabling xmp of the rams
1613538310030.png
 
I see...

So you're on 1.1.0.0D AGESA like my F32 BIOS version. Do you know the SMU version on that F12?

View attachment 5943
Updated to F13a BIOS. SMU is now 46.67.0 but PRD is still the same.
I haven't delved very deep into this but does the calibration from the board manufacturer affect all processors or maybe they've tweaked this differently for different processors to get the most performance out of them while playing it safe?
 
okay i ran cinebench r23 multi core and this is the outcome while i was running it :
my pc is on stock, nothing modified on bios other than enabling xmp of the rams
View attachment 5950
5600X has a PPT limit of 76W
On this 100% load PPT reports 76W with 98% PRD.
So, 76 / 0.98 = 77.5W
Its all right...

Updated to F13a BIOS. SMU is now 46.67.0 but PRD is still the same.
I haven't delved very deep into this but does the calibration from the board manufacturer affect all processors or maybe they've tweaked this differently for different processors to get the most performance out of them while playing it safe?
Cant really say how they doing it... It was an issue when first this surfaced, about board vendors trying to make their boards looking better over competition (more CPU performance)
But your CPU for sure is not pushed to limit. I cant really say if you have 3600X or 3600XT but both of them have a default PPT limit of 125W, and your CPU on your screenshot is consuming about 98~99W.
I dont know what will happen or what the results will be if you cool it further.
 
5600X has a PPT limit of 76W
On this 100% load PPT reports 76W with 98% PRD.
So, 76 / 0.98 = 77.5W
Its all right...


Cant really say how they doing it... It was an issue when first this surfaced, about board vendors trying to make their boards looking better over competition (more CPU performance)
But your CPU for sure is not pushed to limit. I cant really say if you have 3600X or 3600XT but both of them have a default PPT limit of 125W, and your CPU on your screenshot is consuming about 98~99W.
I dont know what will happen or what the results will be if you cool it further.
I got the 3600XT. I think yeah the limiting factor is temperature. That’s what’s limiting it and keeping it under PPT anyway.
 
I noticed it before that the PRD value was red. Googled it and landed here. Gigabyte reporting is pretty off.
I reached out to Gigabyte and given what I provided with screen shots, and power consumption, they believe the tool is not showing accurate numbers even when the system is under load. From my limited research and others can affirm, correct or contradict this, but I believe the tool uses an internal table to fully compute this value. That is, its quite possible that the tool is wrong and not the mother board as this is not an actual value being reported by a sensor but rather a computer deviation based on other factors.

This is what I mean by computing the value and other factors:

The weakness of this method is, that the telemetry essentially uses an undefined scale for the current (and hence power) measurements. This means that the motherboard VRM controller will send an integer between 0 - 255 to the CPU, and based the reference value known by the co-processor firmwares, this integer is converted to a figure, that represents a physical current drawn by the CPU. Based on the accurately known current flow and the voltage, it is possible to calculate to CPU power draw in Watts (V * I).

The reference value mentioned earlier is generally different for each of the motherboard make and model, unless there are boards which have an identical power circuitry. Because of that, it is on the motherboard manufacturers responsibility to find the correct value for their motherboard design through the means of calibration, and then to declare it properly in AGESA, during the bios compile time. In case the motherboard design specific, correct value differs greatly from the declared value, there will be a bias in the power consumption seen by the CPU. In case the declared value is greater than the actual value, the power consumption seen by the CPU is greater than it actually is. Likewise, if the declared value would be an understatement... the CPU would think it consumes less power than it actually does.

Now I'm not saying some motherboard makers are not trying to exploit loop holes to push performance, but rather using a metric that is inconsistent and not readily verifiable can lead to consternation, confusion and questions. I mean look at this thread, its 18 pages and going. I'm not blaming AMD or the developer but its clear something is not right when a reporting value is being displayed is not accurate unless you are in certain situations (full load) and even then, it may still be inaccurate.
 
Last edited:
HWiNFO calculates the deviation as difference between total CPU power reported (1) and power expected/estimated (2).
(1) Is the value the CPU calculates from VRM (SVI2) telemetry + some minor estimations (which are rather accurate). The SVI2 telemetry can be easily skewed by BIOS as explained here, but this is the value used by CPU/SMU on which the power management and performance decisions are made.
(2) Is a value calculated internally by the CPU using certain methods, which I cannot describe in detail as this is strictly confidential. The point here is that this estimation is pretty accurate when the cores run at full load and at stock settings (no OC, offsets, tweaks). In this case the CPU knows pretty well how much each core is consuming. The reason why this doesn't work at lower load is that in this case other effects which are insignificant during full load are starting to play a more significant role resulting in higher inaccuracy.

I'm not sure whether GIGABYTE has really investigated this, or it's just the usual Level-1 support trying to reduce the support queue by dismissing things at first attempt.
 
The point here is that this estimation is pretty accurate
Perhaps, but it seems that by providing an estimated value, this has caused more consternation

I'm not sure whether GIGABYTE has really investigated this, or it's just the usual Level-1 support trying to reduce the support queue by dismissing things at first attempt.
Not sure in all truthfulness. It's a ticket that has been active since January and I've provided details, and screen shots, their final response was
Based on the information we received from our team, HWINFO reports all AM4 boards have this Power Reporting Deviation problem (including other vendors).
It may be related to Agesa code.

I find this a bit more plausible then having an ITX board reporting a value of 60 to 75.5% under load (even throwing out the non-load values)

Edit:
One final question, you mention that your estimate is pretty accurate - what process/method are you using to confirm the accuracy since its a computed value? This is more out of curiosity then anything else.
 
my power reporting deviation looks like its going in the red...do i need to change some settings in bios? Deviation is right below line i highlighted in blue.
Asrock Steel Legend x570
bios 1.90
Ryzen 3700x
 

Attachments

  • power.jpg
    power.jpg
    606.5 KB · Views: 22
Back
Top