Nut upsuser - Jan 2014 - Eaton 5PX broken interrupt on usbhid-ups, also pollfreq vs pollinterval?

Linux NUT 2.7.1
Eaton 5PX usbhid-ups

It would appear that interrupts are not actually working on my 5PX using 
the usbhid-ups driver. I will be trying the serial mge-shut driver next. 
It just seemed like it was working before because of the default 
pollinterval of 2 seconds. The status update comes in during the 
pollinterval no matter what I have pollfreq set to. And I can set 
pollonly and get the same behavior.

With the driver usbhid-ups, what is the relationship between pollfreq 
and pollinterval? It looks like pollinterval overrides pollfreq.

  usbhid-ups -a ups -DDDDD -x pollfreq=30 -i 30 2>&1 | egrep 
'(update|ups.status)'
    8.580411     upsdrv_updateinfo...
    8.831572     Quick update...
    8.832351     send_to_all: SETINFO ups.status "OL CHRG"
    8.832807     upsdrv_updateinfo...
    9.084535     Quick update...
   38.833152     upsdrv_updateinfo...
   39.085481     Quick update...
(AC removed at this point)
   68.833928     upsdrv_updateinfo...
   68.844373     Full update...
   69.511072     send_to_all: SETINFO ups.status "OB DISCHRG"
(AC restored)
   98.833548     upsdrv_updateinfo...
   98.839093     Quick update...
   98.955823     send_to_all: SETINFO ups.status "OL CHRG"

Regards.

On Jan 9, 2014, at 7:37 PM, Kris Jordan wrote:
> The status update comes in during the pollinterval no matter what I have
pollfreq set to. And I can set pollonly and get the same behavior.
This should probably be clarified in the documentation, but that is mostly
expected behavior.

A bit of background: USB interrupt transfers are not like IRQs on a processor.
The USB host (PC) has to poll the USB device (UPS) every time it wants to check
for data, one transfer for each IN endpoint. The only real advantage over a
regular (bulk) transfer is that the device can short-circuit the process by
signaling that there is no new information (without timing out).

The unclear part, I think, is the overloading of "poll" and
"interrupt": NUT is using USB nomenclature for interrupts, which
implies immediate notification, and glosses over the fact that the requests are
driven by a polling loop.

NUT requests an interrupt transfer in the driver main loop (which uses
<pollinterval> for the timeout). pollinterval is, therefore, the shortest
sampling interval of any of the UPS variables.
> With the driver usbhid-ups, what is the relationship between pollfreq and
pollinterval? It looks like pollinterval overrides pollfreq.
From http://www.networkupstools.org/docs/man/usbhid-ups.html#_extra_arguments :

pollfreq=num
   Set polling frequency, in seconds, to reduce the USB data flow. Between two
polling requests, the driver will wait for interrupts (aka UPS notifications),
which are data changes returned by the UPS by itself. This mechanism allow to
avoid or reduce staleness message, due to the UPS being temporarily overloaded
with too much polling requests. The default value is 30 (in seconds).

Specifically, that means that if a HID item is not marked as HU_FLAG_QUICK_POLL
in the *-hid.c files, and the UPS does not provide it on its own, it will only
get updated once every <pollfreq> seconds, rather than every
<pollinterval>.

ups.status is constructed from HID items marked HU_FLAG_QUICK_POLL, so it should
update within <pollinterval> seconds (these are the lines following
"Quick update..." in the log).

'pollonly' is specific to usbhid-ups, and refers to the type of USB
transfer used to fetch the HID item. Most HID UPS hardware will occasionally
send back updates over the interrupt pipe (whatever item is available), but
apparently there is an issue with some newer APC units, and they only respond to
the slower EP0 control messages. I suspect[*] that CPU usage would be a bit
higher with 'pollonly' set, but I haven't benchmarked it. There are
some "#ifdef DEBUG" lines in usbhid-ups.c that can be enabled to
measure the time needed to fetch via interrupt request versus control request.

[*] well, someone else confirmed:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2013-January/008195.html

-- 
Charles Lepple
clepple at gmail