Thanks for the info Al, much appreciated :)
See my inline comments below.
On 2/23/2012 12:51 PM, Albert Chu wrote:
> Hey Jim,
>
> On Thu, 2012-02-23 at 11:01 -0800, Jim Mankovich wrote:
>> Hi Al,
>>
>> I understand what you are saying, and your thoughts about using sensor units
>> {1..3} might
>> work. I'm trying to find some other folks internally that might be able
>> to shed some light
>> on the ambiguity.
>>
>> Were the "fair number of discrete sensors that you saw 00b",
>> Threshold-based sensors identified
>> by (Event/Reading Type Code == 1) ?
> No, with discrete event-reading type codes (6fh for the sensor specific,
> and 02h-0Ch for the general discrete).
>
>> When you mention "discrete sensor w/ an analog reading" are you always
>> referring to a Threshold-based
>> sensor?
> No, a discrete event-reading-type code (02h-0Ch or 6fh). Basically what
> is on the HP motherboards that I mentioned earlier, like this:
>
> 6 | Power Supply 1 | Power Supply | Nominal | 1200.00 | W | 'Presence
> detected'
>
>> I see in Section 42.1 of the spec where it mentions a Threshold-based
>> sensors return a different
>> response to the Get Sensor Reading command than discrete sensors and that
>> they may return an
>> analog reading. I don't see any other class of sensor that is capable of
>> returning an analog reading.
>> Are there other sensors that can return analog readings? If so, where can
>> I read about these in
>> the spec?
> I think this is where it gets really confusing because there is what
> "should be" and "makes sense" vs what is "legal". Not to mention the
> possible mix up of terminology in this thread.
>
> In my opinion, a threshold sensor is event-reading-type-code = 1h. Only
> a threshold sensor should ever return an analog reading.
jim> I have the same opinion after going through the spec.
> A discrete sensor is event-reading-type-code 02h-0Ch + 6Fh. IMO, none
> of these should ever return an analog reading.
jim> agreed
>
> I think for most developers of IPMI, the above is what "makes sense" and
> "should be". I get the feeling this is what you are thinking when you
> read the spec.
jim> yup
> On atleast HP motherboards (possibly more), there are discrete sensors
> (event-reading-type-code 02h-0Ch + 6Fh) that ALSO return an analog
> reading. The sensor example listed above, it is a discrete specific
> sensor w/ event-reading-type-code 6Fh. Yet, it returns an analog
> reading of 1200 Watts.
>
> Is this a broken implementation? IMO, it's legal.
jim> So this brings us back to your idea of using sensor unit {1..3} to
determine if
jim> an analog value is returned.
>
> So for your questions:
>
>> I don't see any other class of sensor that is capable of returning an
>> analog reading. Are there other sensors that can return analog
>> readings? If so, where can I read about these in the spec?
> I think this is the situation where just because the spec doesn't say
> you can do X, doesn't mean you can't do X.
jim> Understood. Thanks for the clarification. I'm glad I wasn't totally
off base with I was
jim> seeing in the spec as well as in the code.
>
> Al
>
>> Thanks for you help on this,
>>
>> -- Jim Mankovich | jm...@hp.com --
>>
>>
>> On 2/22/2012 11:01 AM, Albert Chu wrote:
>>> Hey Jim,
>>>
>>> On Wed, 2012-02-22 at 04:58 -0800, Jim Mankovich wrote:
>>>> Al,
>>>>
>>>> I interpreted the ** statement as meaning the 8 bit "Sensor Units 1" field
>>>> should
>>>> be written with zero since the ** statement identifies the entire 8 bit
>>>> value, 00h, not
>>>> a 2 bit value 00b. But, given that the ** is next to "Analog (numeric)
>>>> Data Format" it
>>>> would seem to only apply to this 2 bit field within the 8 bit "Sensor
>>>> Units 1" field.
>>>>
>>>> "** Specifies threshold and 'analog' reading, if 'analog' reading
>>>> provided. If neither
>>>> thresholds nor analog reading are provided, this field should be written
>>>> as 00h."
>>>>
>>>> In the cases where you saw 00b in the Analog (numeric) Data Format field,
>>>> was
>>>> the value of the entire "Sensor Unit 1" field zero? An entire 8 bit
>>>> field of zero would
>>>> seem to make sense for a Discrete sensor.
>>> Yes, but an entire 8 bit field of zero for "Sensor Unit 1" would also
>>> make sense for an discrete sensor w/ an analog reading. Which is why I
>>> think your original interpretation was not safe.
>>>
>>> I'd have to think about this a tad more, but perhaps using sensor_unit_2
>>> and sensor_unit_3 in combination might make some of the guesses more
>>> valid. Here's a guess:
>>>
>>> if ((sensor_unit_1& 0xC0) == 0xC0
>>> || (sensor_unit_1 == 0
>>> && sensor_unit_2 == 0
>>> && sensor_unit_3 == 0))
>>> /* assume discrete sensor w/ no analog reading */
>>> else
>>> /* assume an analog reading */
>>>
>>> Al
>>>
>>>> -- Jim Mankovich |jm...@hp.com --
>>>>
>>>>
>>>> On 2/21/2012 4:26 PM, Albert Chu wrote:
>>>>> Hi Jim,
>>>>>
>>>>> On Tue, 2012-02-21 at 15:02 -0800, Jim Mankovich wrote:
>>>>>> Al,
>>>>>>
>>>>>> My interpretation was that 11b means discrete and all other values are
>>>>>> analog.
>>>>> But doesn't this interpretation contradict "If neither thresholds nor
>>>>> analog reading are provided, this field should be written as 00h."?
>>>>>
>>>>> The point is, how many motherboards/sensors might be incorrectly
>>>>> affected by this change? When I posted my original post, I decided to
>>>>> look at a few of the motherboards we had here. A fair number of them
>>>>> have 00b for discrete sensors that don't return an analog reading.
>>>>>
>>>>> Al
>>>>>
>>>>>> I interpreted it this way because 11b is explicit in stating "Does not
>>>>>> return
>>>>>> analog (numeric) reading" (11b == Discrete) . For Compact Sensors 11b
>>>>>> is the
>>>>>> only valid data format because Compact Sensors can only be used for
>>>>>> discrete (per
>>>>>> the table at the beginning of Section 43.1 which specifies that only
>>>>>> full records
>>>>>> can support analog readings). If anything other than 11b were Discrete,
>>>>>> these
>>>>>> values would need to be identified as valid in the Compact "Sensor
>>>>>> Units 1" Field.
>>>>>>
>>>>>> 11b Discrete, all other values Analog
>>>>>>
>>>>>> -- Jim Mankovich |jm...@hp.com --
>>>>>>
>>>>>>
>>>>>> On 2/21/2012 3:23 PM, Albert Chu wrote:
>>>>>>> Hey Jim,
>>>>>>>
>>>>>>>> I don't see why ipmtool shouldn't rely on the "analog data format"
>>>>>>>> being set correctly instead of making assumptions.
>>>>>>> Generally speaking, the spec isn't clear on this part (atleast in the
>>>>>>> version I have most recently downloaded). From 43-1 in the spec:
>>>>>>>
>>>>>>> ----
>>>>>>>
>>>>>>> [7:6] - Analog (numeric) Data Format**
>>>>>>> 00b = unsigned
>>>>>>> 01b = 1’s complement (signed)
>>>>>>> 10b = 2’s complement (signed)
>>>>>>> 11b = Does not return analog (numeric) reading
>>>>>>>
>>>>>>> ** Specifies threshold and ‘analog’ reading, if ‘analog’ reading
>>>>>>> provided. If neither thresholds nor analog reading are provided, this
>>>>>>> field should be written as 00h.
>>>>>>>
>>>>>>> ----
>>>>>>>
>>>>>>> So if this field is listed as "00b", is the sensor reading an analog
>>>>>>> "unsigned" reading? Or is it "neither threshold nor analog reading are
>>>>>>> provided"? How do I know which?
>>>>>>>
>>>>>>> Al
>>>>>>>
>>>>>>> On Tue, 2012-02-21 at 12:48 -0800, Jim Mank wrote:
>>>>>>>> Al,
>>>>>>>>
>>>>>>>> My email is directly related to your thread, but there are more issues
>>>>>>>> with incorrect
>>>>>>>> interpretation than you identified. The "event/reading type code"
>>>>>>>> must be used
>>>>>>>> to identify a Threshold vrs a Discrete sensor and the "analog data
>>>>>>>> format" flag should
>>>>>>>> be used to identify analog vrs discrete units. I agree that having a
>>>>>>>> discrete sensor
>>>>>>>> return an analog reading "makes no sense", but I don't see why ipmtool
>>>>>>>> shouldn't
>>>>>>>> rely on the "analog data format" being set correctly instead of making
>>>>>>>> assumptions.
>>>>>>>>
>>>>>>>> -- Jim Mankovich |jm...@hp.com --
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/21/2012 12:57 PM, Albert Chu wrote:
>>>>>>>>> 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
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> 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
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
