[Nut-upsdev] newhidups and pollinterval

Alfred Ganz alfred-ganz+nut at agci.com
Mon Aug 15 23:23:42 UTC 2005


As reported earlier, my UPS burps a lot of unsolicited interrupt messages. 
I have made some experiments with the UPS using newhidups directly, and 
noticed that the poll frequency of the dstate_poll_fds() calls in main.c
can be heavily skewed by the timeout provided in the libusb_get_interrupt()
call in libhid.c (currently 5 sec!). For a UPS that provides few interrupt
messages, this may result in a behavior equivalent to a pollinterval of 5 
or more for any pollinterval settings of less than 5. 

Since pollinterval is generic for all types of UPS's, may I suggest that 
the timeout in libhid.c be significantly reduced (50 ms would affect even 
a pollinterval of 1 by at most 5 %). Unfortunately this change does not 
address a UPS that burps at more than one message per pollinterval. 

I have been able to improve things further in my case by repeating the 
HIDGetEvents() calls in newhidups.c (i.e. changing the if around the 
HIDGetEvents() call into a while) to some extent (i.e. I can now run with 
a pollinterval of 2 without loosing any burps from my UPS). BTW, with
both fixes I start loosing messages with a pollinterval of 3 (and it is
status messages that get lost first somehow!).

However, I believe the current code is inherently flawed because of the
two competing time delayed requests for both dstate_poll_fds() and 
libusb_get_interrupt(). Unfortunately I don't see a simple solution for
this situation, particularly because pollinterval is a generic parameter
for all UPS's and is handled in main.c.

I know I am causing you more trouble Arnaud, and I don't have a simple
solution either (although the two proposed fixes would help in the short

Sorry, AG

   Alfred Ganz					alfred-ganz at agci.com
   AG Consulting, Inc.				(203) 624-9667
   440 Prospect Street # 11
   New Haven, CT 06511

More information about the Nut-upsdev mailing list