[Nut-upsdev] [nut-commits] svn commit r2036 - trunk/man

[Kjell Claesson]

Hi
> 
> indeed.
> more generally, I think that the current 2 seconds polling interval
> was well adapted to dumb units, but not that much to smart ones.
> 
This is something that been on my mind also. Some high end ups'es
is giving a lot of data on each poll.
 
> I have another incomplete reflexion in mind for a long time, linked to:
> - having 2 poll_interval: 1 for OL and 1 for OB,
> - having per driver poll_interval*s* specification (ie in
> upsdrv_info), and #define DEFAULT_POLL_INTERVAL 10
> - generalizing and optimizing interrupt / trap / alarm handling (btw,
> I've a draft answer on the netnsm-ups thread) and use extrafd. This
> probably means multithreading...
> 

To share my idea. I have been thinking about two types of polls.
Many ups protocol have a status command and a info command.
Now we poll for info and get everything including status.

That is a lot of data.
Why not do:

info poll
delay after info poll.
status poll
status poll
status poll
status poll
Then start over again.

This make less data to read, and a quick response for OB LB.
The drivers and the polling need to be changed.

Maybe a bad idea, but you are free to pipe it to /dev/null

/Kjell