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

[Arnaud Quette]

2009/10/21 Arjen de Korte <nut+devel at de-korte.org>:
> Citeren Arnaud Quette <aquette at alioth.debian.org>:
>
>> +.SS "Repetitive timeout and staleness"
>> +
>> +Some models tends to be unresponsive with the default polling frequency.
>> +The result is that your system log will have lots of messages like:
>> +.nf
>> +       usb 2-1: control timeout on ep0in
>> +       usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq
>> 6 len 256
>> +       ret -110
>> +.fi
>> +
>> +In this case, simply modify the general parameter "pollinterval" to a
>> higher
>> +value (like 10 for 10 seconds). This should solve the issue.
>> +
>
> Should we make this the default for this driver? For instance, by adding
>
>    poll_interval = 10;
>
> in upsdrv_makevartable? It would still allow people to override this (driver
> specific) default value, but might be a safer default than the present
> default that is set in main.c and main-hal.c.

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.

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...

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/