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 [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
