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:
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.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.
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.
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?
