Citeren Marco Chiappero <[email protected]>:
In that case, you would indeed be able to run multiple NSM enabled
drivers in parallel. The only objection that remains then is that
putting this in the netxml-ups driver is probably not a good idea.
It would be quite a burden on the little micro controller in the
NMC 66102, since it would also require parsing the full XML data
for each instance.
Yes, if we do care about detailed info. The summary page can be
enough for that, but at this point we should introduce changes in
the netxml-driver and a new configuration key (such as "extended =
true") which is not good.
The summary page can be also quite large (depending on the model you
have) so this doesn't really help to reduce the load on the NMC. Since
the way we get information from the NMC is quite different between the
polling mode that is used by the netxml-ups driver and the subscribed
mode for NSM clients, I really don't want to combine these in one
driver.
Nonetheless there's no way out if we want many variables, we have to
read a "lot" of data from every single UPS involved and stress the
NMC, even though UDP can help.
For various reasons, using UDP for collecting data from the UPS is not
a good idea.
Maybe we can use the summary page, by default, when the management
is enabled, or use different poll intervals for management and data...
Newer versions of the netxml-ups driver already do so by default. Yet,
this still doesn't fully solve the problem and you really should not
run more than one netxml-ups driver on any single NMC (regardless of
which version you have).
If I'm not wrong the Eaton software polls the summary page every 60 seconds
and looks for new alarms every 10 seconds.
This might be an option, but for logging purposes a full poll every 60
seconds is probably not nearly enough.
If you'd make this NSM driver a separate one however, I'd be all for it.
Sorry, I don't understand this last sentence, what you mean?
Please do follow up on the NSM driver, but make this a separate one
(so don't include it in the netxml-ups driver). This not only reduces
the load on the NMC, but it will also make the code much cleaner,
since you don't have to deal with the differences between connected
and non-connected mode (it would always use connected mode). The
mapping between variables for values read from the UPS to NUT
variables would also be reduced significantly and basically you'd only
have to parse the ones from the ALARM messages.
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
