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@gmail _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
