Citeren Marco Chiappero <[email protected]>:
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.
What about including these ideas and functions into the netxml-ups
driver maintaining the backward compatibility
This is what I'm doing now.
We can create a single subscription connection, from which we only
need to read the BelowRemainingCapacityLimit flag (to allow the use
of the testing button) and the DelayBeforeShutdown value (about the
outlet used by the system). An alarm message reception can then
trigger a summary page scan (no need to set timings) while the
get_object page, with extended data, can be read every
"pollinterval" (the user can choose whether to have it low and
stress the NMC or not).
Something along these lines, yes.
We can also lower the summary page scans, reading more data from the
alarms, for example:
- alarm level == 1 -> update data using this alarm and read the
summary page every "pollinterval"
- alarm level == 2 -> read the summary page immediately
Does it sound reasonable?
Yes. Although it is questionable whether it makes sense to handle
different alarm levels. When polling for the summary and/or get_object
pages, you'll already get all data, so we might even skip the alarm
processing all together without losing any data. The best thing about
the subscription mode is that it will alert us if something is
happening. This means that we can increase the time between normal
polls, but do additional polls when an alarm arrives.
Moreover reading the summary page we also know when to start the
shutdown procedure on every outlet, so we have every kind of
information we need/want, with just a single subscription.
Indeed. So it wouldn't be a problem that only one NSM client can run
on the host where the upsd server lives. As long as we make sure that
only one is connected to any NMC at the same time. Otherwise, you'd
get an endless mess of reconnects... :-)
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
