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

[Arnaud Quette]

Hey Kjell,

2009/10/21 Kjell Claesson <kjell.claesson at epost.tidanet.se>:
> 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

not a bad idea at all Kjell. but it needs more work on the drivers,
and not only on the common core (ie main.c).
I'll definitely be thinking about that.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/