Thanks for doing this comparison. I have attempted some software-based measurements myself and the results were garbage because of desktop GPU compositing. Much better this way.
What’s odd about this Dante (and other audio protocols) over ethernet can get to 0.25 microseconds of latency. Sure unlike keyboards it uses just as much bandwidth to transmit nothing as something, it’s just interesting (although not technically surprising) that on gigabit ether you can do better than USB.
I’m intrigued by the terminal application latency measurements. I don’t use a Mac, so I’m not sure about iTerm 2, but I do know that Kitty feels very responsive compared to the rest of the terminal emulators on my machine, especially Konsole. I alternate between using Bluetooth and USB on my keyboard (it supports both) and I don’t really notice a difference between the two (with the newest-generation desktop Magic Keyboard and the Bluetooth hardware included on my motherboard).
This is interesting and represents progress in exposing a problem. But it is end to end.
I keep wondering why the following hasn’t been measured, min/avg/max latency-wise:
(electrical) keypress to message on usb wire.
usb wire to gpio (with e.g. a SCHED_FIFO program listening to event, setting gpio on event receive, repeat the test while using the computer as a desktop for an extended amount of time to see the influence of load despite scheduling class).
My suspicion is that the electronics in keyboards themselves (I suspect dominated by firmware), and the operating system (e.g. Linux, and the UNIX-like design that makes reasoning about latency so hard it is non-tractable) do introduce a large amount of latency and jitter.
Key press to USB latency of course depends heavily on the keyboard, but you can try to detect it by doing an end to end measurement of different keyboards while holding the software end constant: https://danluu.com/keyboard-latency/
Linux keyboard processing latency can be less than 1ms
Careful. Latency does not matter every time it is low enough. This is very easy to achieve in average. Relative to achieving a low maximum latency, that is.
Maximum latency is the value that really, really matters. Because that’s the one where UX is broken.
while holding the software end constant
Linux is too jittery to be used for this measurement. This is why I was very specific (message on usb wire).
Suffers from the issue above, and from keypress being mechanical. I would argue they are measuring something else entirely, rather than the latency introduced by electronics/firmware within the keyboard.
In practice, the only times I notice extreme latency (to the point where it doesn’t feel instant) on my Linux system is when I start typing in a Google Doc before it’s loaded or something like that. In that case, the issue is that the application isn’t ready to process input, not the kernel. Even when I’m running four fuzzer instances (each locked to one of my four cores) or compiling something like Chromium, the input latency is not noticeably worse.
I know that UNIX is a conceptually inferior operating system design compared to some others, but the huge amounts of manpower going into the Linux kernel mean that issues like input latency under load are not significant. I don’t doubt that they are a noticeable issue on some Linux desktop systems, but the issue there would be the relatively poor desktop environments, not the kernel.
I agree that tail latency matters, and more like 99.9th or 99.99th percentile latency rather than maximum, but if you read the article I don’t think there’s any reason to suspect based on how things work that Linux input processing will have high tail latencies in any way that doesn’t just apply to anything running on a non-RTOS. I’m pretty convinced that USB event processing latency is dwarfed by other factors like compositor latency as long as you use a 1000hz keyboard.
Thanks for doing this comparison. I have attempted some software-based measurements myself and the results were garbage because of desktop GPU compositing. Much better this way.
What’s odd about this Dante (and other audio protocols) over ethernet can get to 0.25 microseconds of latency. Sure unlike keyboards it uses just as much bandwidth to transmit nothing as something, it’s just interesting (although not technically surprising) that on gigabit ether you can do better than USB.
I’m intrigued by the terminal application latency measurements. I don’t use a Mac, so I’m not sure about iTerm 2, but I do know that Kitty feels very responsive compared to the rest of the terminal emulators on my machine, especially Konsole. I alternate between using Bluetooth and USB on my keyboard (it supports both) and I don’t really notice a difference between the two (with the newest-generation desktop Magic Keyboard and the Bluetooth hardware included on my motherboard).
This is interesting and represents progress in exposing a problem. But it is end to end.
I keep wondering why the following hasn’t been measured, min/avg/max latency-wise:
My suspicion is that the electronics in keyboards themselves (I suspect dominated by firmware), and the operating system (e.g. Linux, and the UNIX-like design that makes reasoning about latency so hard it is non-tractable) do introduce a large amount of latency and jitter.
Oh maybe I should have linked to this in the post, it performs the second type of measurement and finds that Linux keyboard processing latency can be less than 1ms if you do it right: https://michael.stapelberg.ch/posts/2018-04-17-kinx-latency-measurement/
Key press to USB latency of course depends heavily on the keyboard, but you can try to detect it by doing an end to end measurement of different keyboards while holding the software end constant: https://danluu.com/keyboard-latency/
Careful. Latency does not matter every time it is low enough. This is very easy to achieve in average. Relative to achieving a low maximum latency, that is.
Maximum latency is the value that really, really matters. Because that’s the one where UX is broken.
Linux is too jittery to be used for this measurement. This is why I was very specific (message on usb wire).
Suffers from the issue above, and from keypress being mechanical. I would argue they are measuring something else entirely, rather than the latency introduced by electronics/firmware within the keyboard.
In practice, the only times I notice extreme latency (to the point where it doesn’t feel instant) on my Linux system is when I start typing in a Google Doc before it’s loaded or something like that. In that case, the issue is that the application isn’t ready to process input, not the kernel. Even when I’m running four fuzzer instances (each locked to one of my four cores) or compiling something like Chromium, the input latency is not noticeably worse.
I know that UNIX is a conceptually inferior operating system design compared to some others, but the huge amounts of manpower going into the Linux kernel mean that issues like input latency under load are not significant. I don’t doubt that they are a noticeable issue on some Linux desktop systems, but the issue there would be the relatively poor desktop environments, not the kernel.
I agree that tail latency matters, and more like 99.9th or 99.99th percentile latency rather than maximum, but if you read the article I don’t think there’s any reason to suspect based on how things work that Linux input processing will have high tail latencies in any way that doesn’t just apply to anything running on a non-RTOS. I’m pretty convinced that USB event processing latency is dwarfed by other factors like compositor latency as long as you use a 1000hz keyboard.