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) ?
When you mention "discrete sensor w/ an analog reading" are you always
referring to a Threshold-based
sensor?
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?
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
