Hi Raphael, At my work (PlayStation) I deal a lot with input latency and latency in general for (cloud) gaming. I can try to answer some of your questions. a) Aside from not all devices supporting such high poll rates (you would get the same data). Downsides are higher CPU overhead due to increased interrupt frequency, which also causes higher power consumption on laptops. It may also cause higher power consumption for your HID devices. Many people use wireless keyboards and mice, often using a RF dongle (e.g. Logitech). In addition not all software can handle high frequency input. For example on Linux evdev is mostly used and it buffers events. The default buffer size is 64 entries (see evdev_compute_buffer_size). If you don't poll quickly enough, old events are overwritten and you get SYN_DROPPED. For many applications the input poll rate is not that critical, but it all depends on the use case. For example in game consoles, gamepads are the main form of input. The major game consoles each have different features, but input is similar all "state based input" (e.g. XInputGetState as on windows) instead of event based. Input polling to this date is often tied to VSYNC often 60 frames a second (yes, still often 60Hz) and controlled by the game. The OS / hardware may poll more quickly, but the games only sample the state at a lower frequency. Aside from all of this if you want to get accurate in terms of variance calculations, you also need to pay attention to the kernel HZ value, which is often 250 Hz these days or sometimes even 1000 Hz depending on the Linux distribution. c) I don't know the specifics here, but I would read e.g. the xhci driver, just a quick grep on it had many references to bInterval and calculations based on 125 us. I don't know in which context, it would result in something < 1ms. Thanks, Roderick On Wed, Dec 19, 2018 at 2:49 PM Raphael Wimmer <raphael.wimmer@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Hello list, > > I would greatly appreciate your feedback on some assumptions and > findings about the latency of USB-connected input devices. > > > a) are there any known downsides to always polling USB-connected input > devices at 1000 Hz instead of polling only every bInterval ms? > > b) IF there are no known downsides: why isn't polling at 1000 Hz the > default on Linux? > > c) While the USB 3.0 standard actually seems to allow specifying polling > intervals of 0.5 ms and 0.25 ms, it seems that the Linux USB stack does > not support polling at these rates. Is this correct? > > > Background: > > For an upcoming research paper on input latency, we have characterized > the latency of 35 USB-connected input devices (mice, gamepads, > keyboards) by electrically triggering device buttons and measuring the > time until an input event arrived in the application. To this end, we > used a Raspberry Pi 2 running Raspbian (iirc). > > A major, somewhat unsurprising, finding is that device latency varies a > lot between devices but also depends to a large degree on the USB > polling rate. Both average latency and variance in latency increase with > longer polling intervals. > We also tested each device with a slightly patched kernel that activated > the equivalent of usbhid.mousepoll=1 for all input devices (when we > started with this project, jspoll and kbpoll params were not yet > supported by the kernel we used). > Polling at 1 ms resulted in significant improvements for all devices > which did not already report a bInterval of 1 (most reported 10). > The average latency dropped by 5-10 ms for every device. > The variance of the latency (max latency - min latency of 1000 > measurements) dropped consistently from ~15 ms to ~5 ms. > In our tests, no detrimental effects of 1000 Hz polling could be > observed. In an earlier experiment, a few years ago, a cheapo gamepad > became unresponsive during testing. We do not know whether this was > caused by polling at a too high rate or due to mechanical stress and do > not have it anymore. > > Feel free to check out https://hci.ur.de/projects/latency > The page does not yet contain the new results, however. We will update > it in early 2019. > > Cheers, > Raphael Wimmer
