Citeren Marco Chiappero <[email protected]>:
Uhm are you saying we should subscribe even the netxml-ups driver to
lower NUT load? Maybe there's something I don't know yet about the
extrafd... but, shouldn't we make better to include the nsm code in
the netxml-ups driver/mge subdriver?
Yes, that's what I'm intending to do (and what I have already done for
a large part already by the way). This will reduce the latency for
changes in the power state to essentially zero. At the same time, we
can increase the pollinterval to something like 60+ seconds or so.
Receiving an alarm will then trigger a poll of the summary and/or
get_object pages, to get all available data.
However, only relevant data is sent over the NSM connection, if, for
example, "UPS.PowerConverter.Output.ActivePower" changes we're not
going to know it through alarm messages. But, at worst, it can
suffice to update that data every 60 seconds, which is reasonable.
Is it right? Is it what you meant?
Indeed. This still allows people who want to have more regular updates
of whatever variable they want to get more frequent updates, but
reduces the amount of polling we need to do when nothing critical is
happing for most of the time. In order not to be left in the dark for
too long, I intend to up the default pollinterval to something like 75
seconds in the netxml-ups driver.
I thought the NMC was using only udp broadcast messages but I'm
having some sniffing time and I discovered that, shutting down
outlet #2, much information is forwarded even to a host attached on
the main outlet. Everything but "System.Outlet[3].RunTimeToShutdown"
data (resulting in two empty messages for the connected client).
Interesting!
Yeah, this also surprised me. I too expected that the alarms where
client based, but apparently this isn't the case. At least not for the
NMC 66102 we're both using.
[TCP]
<ALARM level="1" object="UPS.PowerSummary.PercentLoad" value="39"
date="2009/11/03-11:59:46" messageID="5PAEI7"> </ALARM>
<ALARM></ALARM>
<ALARM></ALARM>
<ALARM level="1"
object="UPS.OutletSystem.Outlet[3].DelayBeforeShutdown" value="125"
date="2009/11/03-11:59:56" messageID="6ZJJFK"> </ALARM>
[UDP]
<ALARM level="1" object="UPS.PowerSummary.PercentLoad" value="39"
date="2009/11/03-11:59:46" sessionID="53950" messageCount="22"
messageID="7KIWMV"> </ALARM>
<ALARM level="3" object="System.Outlet[3].RunTimeToShutdown"
value="13" date="2009/11/03-11:59:50" sessionID="53950"
messageCount="23" messageID="1P31YU"> Group 2 system shutdown is
activated </ALARM>
<ALARM level="3" object="System.Outlet[3].RunTimeToShutdown"
value="0" date="2009/11/03-11:59:52" sessionID="53950"
messageCount="24" messageID="59XJRJ"> Group 2 system shutdown is
activated </ALARM>
<ALARM level="1"
object="UPS.OutletSystem.Outlet[3].DelayBeforeShutdown" value="125"
date="2009/11/03-11:59:56" sessionID="53950" messageCount="25"
messageID="H5RPLA"> </ALARM>
Interesting indeed.
Have to investigate a bit more to be sure that
"UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit" object
is a host specific data. Then we should have a quite clear picture
of who is reading what. Well, for a simple UPS at least...
As far as I can see, the above value is not client specific. It would
have been nice if it was (since that would allow us to easily see that
the specific outlet was about to be shutdown), but as far as I can
see, this is the global one (not outlet/client specific). What I'm not
sure about, is what happens when you sent this via the UPS Controls
page for a simulated shutdown event. It could very well be that this
would be client specific in that case, but in practice this will be of
little use for us. During an actual mains failure, it would only be
raised when the batteries are almost flat. Since we would like to shed
some loads on the two switchable outlets long before that (the whole
point of this exercise), we probably can't use that.
We know when the timers are running (through the alarms) and we
also know the shutdown duration requested on the outputs, so it
shouldn't be too problematic to insert a FSD flag. I just wish the
NMC would have used the ShutdownImminent flag that is supposed to
tell this, but for some mysterious reason it doesn't seem to be
used by the NMC.
Yes and I agree. However, a question: if we use the FSD flag, in a
redundant configuration, and that UPS was not really necessary for
the system to live, doesn't it trigger the system shutdown in any
case?
No. A FSD flag only tells that this particular power source is about
to lose power, it doesn't mean that a system that is monitoring this
must shutdown. Here is where the MINSUPPLIES value in upsmon.conf
comes into play. For instance, if you have two outlets that are
powering a host of which at least one must be available, you'd give
them a powervalue of 1 each and set MINSUPPLIES 1. During normal
operation, this would give a total powervalue of 2. Only if both would
fail, the total powervalue would drop to 0, which triggers a shutdown
on the client. If only one fails, you still have a powervalue of 1.
Best regards, Arjen
--
Please keep list traffic on the list
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
