http://www.mindspring.com/~ppokorny/power-2.png
The left part of the graph is idle, followed by starting one "while : ; do : ; done" infinite loop per integer core staggering the start by 6 sec.
The "TDP Margin" was read directly using a shell script that reads the 0xe0 register using "setpci" and decodes the result. I've included the script and data in a tarball you can get here:
http://www.mindspring.com/~ppokorny/power-2.tar.gz
You can see that the TDP Margin value varies widely (it's not scaled by the "tdp to watts" value) where there is little or no change in system power. I believe that we can't see it, but clock boost is in effect at idle and for the first few jobs. But with the boosted clock, the TDP margin is quickly consumed and throttling reduces the "clock boost" which provides increased margin without a corresponding change in the power draw.
I suggest we get some more data to correlate this "TDP Margin" value to actual power draw. I don't think it's going to be a reliable measure of power, but it's still a useful value to present to users. However, we should *stop* scaling/subtracting it from the package TDP power number and just present the scaled "TDP Margin" value instead. Perhaps provide the package TDP value in another parameter file.
Also, if you look at a system that is in a steady state, (6220 procs and PowerNow! disabled) and adjust the time average interval using "setpci" to write to 0xe0.l, you'll find that the value scales well, but that with period settings below "0xb" the very act of reading the register (with a shell script) is enough to affect the measurement. (NOTE: lower numbers on this chart is _higher_ power draw and therefore lower margin available)
http://www.mindspring.com/~ppokorny/runavg-math.png
http://www.mindspring.com/~ppokorny/runavg-math.tar.gz
So I respectfully wonder if AMD's recommendation of 9 is such a good idea. You can see in that same chart that 0xf saturates the counter. We do similar saturation detection on fan speeds and can change the fan speed divisor automatically to get a fan speed reading that is in range. Perhaps something similar here would be better. Average over the longest possible period that doesn't generate a saturation value.
On Mon, Apr 9, 2012 at 2:55 PM, Andre Przywara <andre.przywara@xxxxxxx> wrote:
On 04/09/2012 07:39 PM, Jean Delvare wrote:
On Sun, 8 Apr 2012 01:07:59 +0200, Andre Przywara wrote:
Newer BKDG[1] versions recommend a different initialization value for
the running average range register in the northbridge. This improves
the power reading by avoiding counter saturations resulting in bogus
values for anything below about 80% of TDP power consumption.
Updated BIOSes will have this new value set up from the beginning,
but meanwhile we correct this value ourselves.
This needs to be done on all northbridges, even on those where the
driver itself does not register at.
This fixes the driver on all current machines to provide proper
values for idle load.
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
