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

Citeren Arnaud Quette <aquette op 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.

Best regards, Arjen
-- 
Please keep list traffic on the list

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/

Citeren Arnaud Quette <aquette.dev op gmail.com>:
> I have another incomplete reflexion in mind for a long time, linked to:
> - having 2 poll_interval: 1 for OL and 1 for OB,
Why? I know that we make this difference for the upsmon client, but  
what is the benefit of doing this in the drivers as well?
> - having per driver poll_interval*s* specification (ie in
> upsdrv_info), and #define DEFAULT_POLL_INTERVAL 10
That might be a good idea, to make this explicit in the drivers.

Best regards, Arjen
-- 
Please keep list traffic on the list