[Nut-upsdev] Re: A newhidups question

[arnaud.quette at mgeups.com]

> I think this question is mainly for Arnaud again:
>
> When I run my UPS directly with newhidups -D -D -D, with no data changes,
> and I then observe the interaction with my UPS (still Back-UPS ES 650
> FW:818.w1.D USB FW:w1), I see the updateinfo cycle through 3 different forms:

the 3 different forms are not linked to notifications but to "get var"
more generally.
There is 1 special type: HU_WALKMODE_INIT only use to know if
vars should be added with flags and aux (at init time)
The 2 others are the real ones:
- HU_WALKMODE_QUICK_UPDATE: only poll the most important
data (ie status...)
- HU_WALKMODE_FULL_UPDATE: polls all supported vars
Finally, the last mode is the notification one, where we wait for
the UPS to send us data that have changed.

The main idea behind is to lower usb bandwidth consumption.

To sum up:
1) at init time, we get all supported data (HU_WALKMODE_INIT)
Then in upsdrv_updateinfo()
2) we wait for interrupts, and do a quickpoll (HU_WALKMODE_QUICK_UPDATE)
during the "pollfreq" period.
3) when "pollfreq" is expired, we do a full update of all vars (HU_WALKMODE_QUICK_UPDATE)

> Here is my puzzlement: If I run with the default poll_interval (which
> first applies to dstate_poll_fds(), but indirectly also controls the
> upsdrv_updateinfo() frequency), there are updates roughly every 2 sec,
> as expected, and the three forms seem to cycle like this:
 > (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (3) ...

 this is normal. Note that the above mentioned pollfreq defaults to 30 sec.

> which has the effect that I might not get a status change for close to
> 30 sec, which doesn't seem very nice while we switch to LB (but which is
> what I have observed when running with the full set of processes).

 this part is not normal: with mge-hid, I'll wait a max of 3 sec to get
 an important data change (ie switch to battery...)

> However, if I run with a poll_interval of 1 sec, there are about 45
> updates per minute, and the three forms cycle nicely like this:
 > (1) (2) (3) ....

 yep, but you'll consume a lot of your usb bandwith, so of your
 µproc (usb isn't firewire!) and might have some "DOS" from
 your UPS when it will do its autotest. That was the first reason
 why I've made these improvements: I was borried of having
 some staleness messages when the device was busy for some
 seconds (about 15 to 20 sec)

> My question is, what happens in the HID world if the UPS generates several
> different messages, and more messages than newhidups is prepared to read,
> and what would be a good way to handle such cases? What are the HID protocol
> rules here, and what are the rules for the HID (or actually USB) API? Lots
> of questions about which I know almost nothing!

we will process what we have received. Notifications that we have
not read will be dropped (same pb as with udp frame not resent).
So is the need not to overload the USB bus / UPS / system by doing
unneeded read... But also the need to harness important data lookup
(ie my 3 ways to check for LB...) in case we missed the according
notification.

> This applies of course mainly to the case where the UPS generates multiple
> different messages, because otherwise we could probably just ignore some
> messages. However, if there are different messages, we ignore messages at
> our own peril, as the first example shows. Also note that my "fix" will
> no longer work if a UPS sends more than one message a second!

the above should have answered your questions.
having all that in mind, look back at mge-hid and check back
apc-hid... (looking at it, there is no HU_FLAG_QUICK_POLL on
ups.status at least...)

> Sorry Arnaud for causing trouble again! AG

what would be really nice is that you put all the info I gave about
extending newhidups in a small draft, so that I can include it (I
never took time to do so formaly...)

Arnaud