freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freeipmi-devel] RE: ipmi-dcmi testing results


From: Liebig, Holger
Subject: [Freeipmi-devel] RE: ipmi-dcmi testing results
Date: Wed, 16 Dec 2009 11:39:25 +0100

Hi Al,
> 
> > Some more testing with the 0.8.2beta3 shows, that after 
> deactivating 
> > the power limit, the --get-power-limit is choking on the completion 
> > code 0x80 (Power Limit not active), also a --set-power-limit 
> > --power-limit-requested=350 is reading the current setting before 
> > modifying the settings and also fails when the power limit is 
> > disabled.  The typical use case is more like configure some/all 
> > settings, and then activate the power limit.
> 
> My copy of the spec says that the completion code is "No set 
> power limit" (and don't see a change in the errata), which I 
> interpret to mean that set power limit isn't supported?? 
> Skimming through the dcmitool code, it seems they do the same 
> thing as me.  They call the 'get' first then 'set' later.  I 
> guess I don't quite understand how you/Fujitsu are reading 
> the spec differently than I am.

That's quite an interesting discussion and good feedback.

Reading and making sense of the specs is not always easy and for non native 
speakers even a little bit harder ;) We've had already implemented a Power 
Monitoring and Control Mechanism when DCMI came out, so we kind of glue'd them 
together. One problem is, that DCMI knows and supports only an (enforced) Power 
Limit, while there might be other use cases for other customers, for instance 
scheduled switching between power modi.

Regarding the Get Power Limit Command completion code:
We've interpreted it the following way: The spec reads completion code 00 means 
'Power Limit (is) Active'. And there is a command to activate or deactivate the 
power limit. So, how does one know if the limit is currently activated or 
deactivated? Unfortunately there is no flag defined in the DCMI capabilities 
other than the global Power Management is supported flag and no differentiation 
is made between systems which support only Power Measurement & reporting 
(basically a sensor in the system) and systems which do support enforcing a 
power limit which requires hard or software.

Get power reading command reports only if the system is currently measuring the 
power (most DCMI with power management systems will report true). The get power 
limit reports the current settings and if (the) power limit is active. So our 
current interpretation of completion code 0x80 is a minor re-wording of 'No Set 
Power Limit' as 'No Power Limit Set' - and is used to report a deactivated 
power limit. 
Of cause, this is open to discussion and any feedback is welcome.

Also, the major source/influence/backup for the current implementation was the 
DCMI conformance test suite which came out earlier this year. In 
TestGetPwrLimit() any completion code different from 0x00 or 0x80 is 
interpreted as Power Limit not supported. And in TestSetPowerLimit(), before 
setting a power limit the power limit is actually deactivated. Interesting to 
see, that in the end dcmitool and the DCTS behave differently. 

One issue with the DCTS is that it cross checks the 'Power Measurement active' 
from the get power reading command with the 'Power Limit Active' from the get 
power limit command, which IMHO is comparing apples with oranges.

Again, thanks for the feedback and maybe Intel can provide some more 
clarification someday.

Holger



reply via email to

[Prev in Thread] Current Thread [Next in Thread]