Re: Chassis Power Supply Group. (Was "" ;-)

gallagher@quiver.enet.dec.com Mon, 20 July 1992 22:32 UTC

Return-Path: <owner-chassismib>
Received: by CS.UTK.EDU (5.61++/2.8s-UTK) id AA23053; Mon, 20 Jul 92 18:32:30 -0400
Received: from inet-gw-2.pa.dec.com by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA23049; Mon, 20 Jul 92 18:32:27 -0400
Received: by inet-gw-2.pa.dec.com; id AA11538; Mon, 20 Jul 92 15:32:02 -0700
Received: by us1rmc.bb.dec.com; id AA15873; Mon, 20 Jul 92 18:28:12 -0400
From: gallagher@quiver.enet.dec.com
Message-Id: <9207202228.AA15873@us1rmc.bb.dec.com>
Received: from quiver.enet; by us1rmc.enet; Mon, 20 Jul 92 18:30:30 EDT
Date: Mon, 20 Jul 92 18:30:30 EDT
To: chassismib@cs.utk.edu
Cc: dan@lannet.com, gallagher@quiver.enet.dec.com
Apparently-To: dan@lannet.com, chassismib@cs.utk.edu
Subject: Re: Chassis Power Supply Group. (Was "" ;-)


Howdy,

>2.I did not quite understand chasPowerSupplyStatus. When do you 
>return empty(2)?  Are your slots the same as chassis slots? If yes 
>you need not such a value, as the Chassis MIB would allow you 
>defining Power Supply as a device (using chasEntityFunction in Keith's 
>proposal) mapped on a slot.

Yea, I didn't explain that one very well.  I know Donna and Keith's
proposal put the power supplies into the chasEntityTable - treating
power supplies like any other entity.  However, I like to idea of
removing them from the chasEntityTable and putting power supplies
is their own group.  It just seems to me that power supplies aren't
like the other manageable components.  In most chassis I've seen
the component slots and power supply slots even look completely different.
Different sizes, grouped in different locations, etc.  Why group them
in with things that have IP addresses, Parties, and Community Strings?

Your chHWPSULocation fits well into the proposal where supplies are
just another component in the entity table.  Do we want to stick
with this proposal?

>3.Concerning  chasPowerSupplyPlus5,chasPowerSupplyPlus15,
>chasPowerSupplyMinus15 I assume this information includes nominal values. 
>I do not find this very useful. 
>It is redundant and even might be included in chasPowerSupplyDescr.
>Anyway, we cannot include all combinations here (what about -12V, +12V,etc.)

But is chHWPSUVoltage useful?  Voltage ain't power.
I agree with you that just dealing with +5/+15/-15 won't cut it.

>4. Your  chasPowerNPlusOne seems, well a little bit exotic for me. I would 
>rather like to know for each row in the table if the PSU is active. 
>  But maybe I do not understand well your model. In the example you give, the
>two PSU's in the chassis would supply power in paralel?

The two supplies would operate in series.
NPlus1 may be analogous to your "dormant" state but, of course, the 
supply is not physically dormant, it's just that the power supplies
are sourcing enough power so that the chassis components will not glitch
(or worse) if any one power supply fails when NPlus1 is true.
In order to support NPlus1 power redundancy you have to know how much
power is being consumed by the components in the chassis (which may
make it rather "exotic" as you say.)

							-Shawn