The power supply does return its current wattage. The "fans" on the HP ProLiant platforms have always been a little goofy because of Event Reading Code used. HP is looking to change this but we have to find the right time due to legacy applications.
I understand that a value returned in a discrete sensor may not make sense from an "ipmitool" or a "freeipmi" application view but for HP specific applications, this allowed a single transaction and reduces the "pounding" on the KCS ports. Since returning a value was not prohibited, it seemed to make sense to reduce the amount of CPU cycles consumed. I see what you are asking in terms of "high, low or normal". In the case of Fans and Power Supplies, any value is really normal unless the discrete "failed" bits are set. Temperatures, however, are a different class. Those we do list as analog since they do have thresholds. I still would like to see ipmitool honor the Event Reading Code rather than looking at the return value in the Get Sensor Reading command. There is only a single threshold Event Reading Code. Everything else is discrete. Or at least that is what I remember right now. Pat -----Original Message----- From: Albert Chu [mailto:ch...@llnl.gov] Sent: Tuesday, February 21, 2012 13:57 To: Schoeller, Patrick (iLO - Houston, TX) Cc: Mankovich, Jim; ipmitool-devel@lists.sourceforge.net Subject: RE: [Ipmitool-devel] Sensor display logic issues I suppose this is now related to this thread I started awhile back due to something I found on an HP machine. http://www.mail-archive.com/ipmitool-devel@lists.sourceforge.net/msg01654.html > The IPMI Specification is not clear if a discrete sensor can return > units. Agreed that it does not appear to be illegal, however to me, a discrete sensor that returns an analog reading "makes no sense". Here are some sensors on an HP machine that had a discrete event type but an analog reading (I'm using FreeIPMI's output): 6 | Power Supply 1 | Power Supply | 1200.00 | W | 'Presence detected' 10 | Fan 5 | Fan | 76.83 | % | 'transition to Running' is 1200W/76.83% high? low? normal? Al On Tue, 2012-02-21 at 11:17 -0800, Schoeller, Patrick (iLO - Houston, TX) wrote: > The IPMI Specification is not clear if a discrete sensor can return > units. I think the Event Reading Code is really the key indicator if > this is a threshold sensor or a discrete sensor. For the Discrete > Sensor, the value could be anything. Again, the IPMI Specification has > never clarified this and I agree with Jim that the Event Reading Code > should be the determining factor. > > HP ProLiant servers do return a value in the data field of the "Get > Sensor Reading" command on some discrete sensors. But the "Reading > Mask" are set correctly for the Event Reading Code. The "ipmitool" > application, however, sees a non-zero value and tries to use the > "Threshold Reading Mask" bits. > > A patch for this had been submitted upstream by Dann Frazier a couple > years ago. Not sure where it went. > > Pat > > > -----Original Message----- > From: Albert Chu [mailto:ch...@llnl.gov] > Sent: Tuesday, February 21, 2012 13:12 > To: Mankovich, Jim > Cc: ipmitool-devel@lists.sourceforge.net > Subject: Re: [Ipmitool-devel] Sensor display logic issues > > Hi Jim, > > On Tue, 2012-02-21 at 10:03 -0800, Jim Mank wrote: > > All, > > > > I've been looking a incorrect sensor display issues with the ipmitool > > that I would like > > to get some feedback on before proposing a specific solution. > > 1. ipmitool does not properly decode discrete vrs analog units > > in all cases > > 2. ipmitool does not correctly identify the Threshold Sensor > > class for Compact and > > Full sensors. > > For #1, the IPMI spec states that the sensor units are identified in > > the Full and Compact > > SDR by the setting in the "Sensor Units 1" Field bits [7:6] "Analog > > (numeric) Data Format". > > See the "Sensor Units 1" Field description on pages 522 and 528 of the > > latest IPMI spec. > > The "Sensor Units 1" Field bits [7:6] field is not used in all cases > > by the ipmitool to determine > > discrete vrs analog sensor units. > > Discrete sensors technically shouldn't have units. Do you mean that > sensors are being mis-interpreted as discrete when they should be > analog? Or vice versa? > > Al > > > For #2, both the Full and Compact SDR field "Event/Reading Type Code" > > field identifies > > whether or not a Event/Reading type is of class Threshold. This > > field should be used by both > > the Full and Compact sensor display routines to identify that the > > given sensor class is of type > > Threshold. See "Event/Reading Type Code" on pages 519 and 525 of the > > latest IPMI spec > > and Table 42-1 and Table 42-2. > > > > In working through a possible solutions to the above issues, I started > > looking in detail at the > > feasibility of merging ipmi_sdr_print_sensor_compact and > > ipmi_sdr_print_sensor_full into a > > single function. In investigating this, I found a dissimilarity in > > how these two routines treat the > > global output flags, verbose, csv_verbose and sdr_extended. I > > believe these two routines > > should be treating these global output flags in exactly the same way. > > For example, if you specify > > both csv_output and verbose (-c -v) , the full print routine will > > output csv formatted information > > and use more verbose output for certain fields, but, the compact print > > routine will not output > > csv formatted information at all. I think the compact display > > routine should be changed > > to interpret these global output flags in exactly the same was as the > > full display routine does. > > > > Here are the main questions I am looking for some feedback on: > > > > Is my interpretation of the IPMI spec with regard to #1 and #2 > > consistent with other peoples > > understandings? > > > > Can the compact sensor print routine (ipmi_sdr_print_sensor_compact) > > be changed to interpret > > the global output flags in the same way that the full sensor print > > routine interprets them? > > > > Thanks in advance, > > -- > > -- Jim Mankovich | jm...@hp.com -- > -- > Albert Chu > ch...@llnl.gov > Computer Scientist > High Performance Systems Division > Lawrence Livermore National Laboratory > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Ipmitool-devel mailing list > Ipmitool-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
