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

[Al Chu]

Hey Holger,

And I got a new beta up:

http://ftp.gluster.com/pub/freeipmi/qa-release/freeipmi-0.8.2.beta5.tar.gz

I added --interpret-oem-data into ipmi-dcmi so that it can be used for
any Fujitsu additions for the exception actions.

Al

On Wed, 2009-12-16 at 10:33 -0800, Al Chu wrote:
> Hey Holger,
> 
> > 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. 
> 
> I see.  I guess another way to view it is if the sentence "No Set Power
> Limit" is interpreted as:
> 
> No "Set Power Limit"
> 
> vs.
> 
> No set "Power Limit"
> 
> If it is the later, then I misinterpreted.
> 
> > Interesting to see, that in the end dcmitool and the DCTS behave
> > differently. 
> 
> If Fujitsu has interpreted this way (partially b/c of DCTS), I think
> it's a good chance other companies have interpreted it this way too.  So
> how about I make a special case.  If you are configuring w/
> set-power-limit, but you can't call get-power-limit, then the user must
> give values for all input fields (exception action, limit, time limit,
> etc.).  
> 
> > Again, thanks for the feedback
> 
> No problem at all.
> 
> > and maybe Intel can provide some more clarification someday.
> 
> Ultimately, that's probably what we'll need to wait for.  I'll ping
> someone from Intel I've spoken with before, maybe he can offer some
> insight.
> 
> Al
> 
> On Wed, 2009-12-16 at 11:39 +0100, Liebig, Holger wrote:
> > 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
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory