Impending Input Bottle Neck in Wired Communications Protocols (USB)

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
Post Reply
User avatar
Kamen Rider Blade
Posts: 39
Joined: 19 Feb 2021, 22:56

Impending Input Bottle Neck in Wired Communications Protocols (USB)

Post by Kamen Rider Blade » 20 Feb 2021, 00:04

Since 8kHz polling rate mice has finally arrived from Razer, I'm sure all the competing vendors will bring their own versions of 8 kHz polling rate mice soon after.

On the road to 1 kHz refresh rate and above, we have another issue.

But I can see another road block ahead, one that you might not have thought of, that's the wired interface known as USB.

With USB 2.0, the lowest latency that a data packet can send with is hard limited via USB 2.0 specs at 125μs = 0.125ms

With USB 3.0, it's only slightly better.

According to what I can google and figure out:
USB 2.0 transmits SOF/uSOF at fixed 1 ms/125 μs intervals. A device driver may change the interval with small finite adjustments depending on the implementation of host and system software. USB 3.0 adds mechanism for devices to send a Bus Interval Adjustment Message that is used by the host to adjust its 125 μs bus interval up to +/-13.333 μs.
8 kHz has a polling time frame of 125 μs which is the limit for USB 2.0 and many input devices are still using USB 2.0.

Any increase in polling rate past 8 kHz is largely meaningless since the USB spec defines the lowest time frame for a packet to be around 125 μs. That's a hard limit, even with USB 3.0 only improving on that time frame by a slight bit.

Another aspect of Latency is the input devices internal polling & process speed for device inputs like your mouse click.

Dan Luu talks about it in his KeyBoard Latency article. Go goole it, it's a good read. The old Apple 2e KB was more responsive than many modern day KB's because of it's internal key scanning was at 556 Hz along with a much simpler computer that has less things to process before your keys got turned into photons. Modern KB's only internally scan at 100-125 Hz.

Anyways, internal device polling/scanning/processing/packet sending is an entirely seperate latency issue that deserves it's own topic.

The main issue I have is the connecting wired protocol, USB.

The technology to ever increasingly lower packet latency IMO is a piece of technology most of us never got to use, and the ones that got to use it, really loved it. (Especially the High End Professional Audio industry)

It's IEEE 1394, popularly known as FireWire thanks to Apple's moniker for the tech.

Old school FireWire 400 had a packet latency of 125.0 μs with a Bandwidth of 400 Mbps
Old school FireWire 800 could have had packet latency of _61.5 μs with a Bandwidth of 800 Mbps if you design the spec correctly.

Since FireWire operated Isochronously & Asynchronously, it always had a constant connection to the base controller with a constant stream of packets where each cycle guranteed a Isochronous & Asynchronous section for data packets.

With improvements on FireWire to 1600 Mbps / 3200 Mbps / 6400 Mbps, I can see the input latency from the base packet dropping down to 31.2500 µs, 15.6250 µs, 7.8125 µs eventually with spec revisions allowing for ever smaller packet latency.

If you're wondering about the packet size, @ 400 Mbps, the packets were limited to 4 KiB in size per cycle, @ 800 Mbps, the packet size increased to 8 KiB in size per cycle, plenty of room for input device data, inspite of it's inefficient 8B/10B encoding. We have far better and more efficient encoding algorithms in the modern day.

I just feel like USB being focused on Bandwidth, which is fine and dandy for general consumers and transferring data between storage and Computers, that IEEE 1394 was a avenue not traveled for input devices.

I know that US military is already using IEEE 1394 for the F-35 and other latest Fighter Jets for ultra low latency communication between parts of the plane and a super reliable connection.

Various Machine Vision and other related technologies uses this for low latency Video Links.

If you're wondering about Patents, the last of the IEEE 1394 patents expired on November 30, 2020.

So I think there is room for a Open Source, Common Standard implementation of IEEE 1394 that can push the low latency initiative and engineering to meet our gaming and low latency connection needs in the future.

And I don't think the USB forum cares about latency as much as we hard core gamers & videophiles care for Low Latency and Blur Free Video.

But if anybody would care about lower latency packets for their input devices, it would probably be found here first.

Hopefully, this thread can start spinning some wheels in people's heads on the future of low latency input and what other bottle necks we have besides the communication protocol over copper and the internal processing speeds of their input device.

User avatar
BTRY B 529th FA BN
Posts: 322
Joined: 18 Dec 2013, 13:28

Re: Impending Input Bottle Neck in Wired Communications Protocols (USB)

Post by BTRY B 529th FA BN » 20 Feb 2021, 07:37

Great post! Very interesting!

ROG Swift 360Hz PG259QNR, Omen X 25f 240Hz, VG248QE 144Hz ; RTX 3080Ti FTW3 Ultra, GTX 1070FE

Posts: 128
Joined: 28 Feb 2020, 21:06

Re: Impending Input Bottle Neck in Wired Communications Protocols (USB)

Post by empleat » 22 Feb 2021, 21:20

To add: ... ndows.html

viewtopic.php?f=10&t=8168 ... 66/page-61 to find post from Ucode ctrl+f Interrupt Threshold Control

Intel motherboards have better USB controller, which polls interrupts more frequently. Interrupt threshold control was disabled for me on Z390, Intel i5 9600KF by default. Not sure, if on AMD mobos, this can be disabled completely too! And what are their maximal polling rate capabilities.

Biggest bottleneck for 8khz is now the timer resolution, it allows to update code to the CPU only at 0.5ms intervals. Next follows DPC latency. It is so hard to find low DPC latency mobo! Even some 500$ have 1ms + Also Windows update can fuck this up! I have currently like 34us on Wdf1000.sys, but in-game - it could be possibly higher. Tested by latencymon, which simulates load already, so it is not fit for in-game testing! I used mousetester too, but don't remember values, I think it was up to 90us, which is a lot! As you need polls to be handled <125 us, to have true 8khz. While 0.5ms timer resolution, won't allow them to be rendered that quickly anyways and will cause biggest inconsistencies. And high DPC latency will make this only worse!

BTW I would like to get rid of USB 3 drivers - Xhci. Pity firewire was never utilized! Even if you disable every USB 3 in BIOS, new motherboards have only Xhci drivers. And mouse feels bad, even in USB 2! Also if you enable only 1 USB 3 port: USB Root HUB name: changes to USB Root Hub (USB 3.0) and mouse lags even more! I couldn't manually revert it to USB 2 version of a driver via Device Manager, if I click let me pick driver, it doesn't show previous driver!

I wonder, if industry will adapt. Because right now 8khz is similar to 16000+ DPI scams. It can still operate at high polling, but I don't know how consistent it is. Since on 360hz, you can discern more inconsistencies probably! As your monitor will display mouse positions more times and more frequently. But you have also higher refresh rate, don't have it, so I don't know how good, or bad it is... And it is annoying, manufacturers underestimate DPC latency. Even ASUS mobos for 500$, they have 1ms DPC latency + LOL

E.g. I still use 500hz and 1ms timer resolution, because 1ms feels inconsistent as shit to me!

PS: I don't think industry cares, USB is already standard for input devices. Manufacturers for what they care, they will sell you 10khz mouse, but it won't work properly. They still don't give crap, even about DPC latency mostly. And they don't give gamers options to tweak their BIOS, like disable HPET. I am not expert and I wasn't following this, but I don't think firewire will be ever used, just because Apple made it its niche product. Maybe like in 5-10 years :D Given tho in 2 years 500hz monitors are expected. Do you think, they will stick to some USB 3.3, or that they could use firewire as potential candidate?

User avatar
Chief Blur Buster
Site Admin
Posts: 9272
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada

Re: Impending Input Bottle Neck in Wired Communications Protocols (USB)

Post by Chief Blur Buster » 11 Mar 2021, 19:35

This is a lot easier to do, it's a form of jitter correction for USB, but it also theoretically allows Thunderbolt or non-USB mice too:

Blur Busters Proposal
Proposed High Definition Mouse Extensions API

It includes sensor-side microsecond timestamping.
Head of Blur Busters - | | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

Post Reply