Measuring keyboard input lag

[ad8e]

The three approaches I think are best all have in common a test platform capable of both GPIO and USBHost.

The easy way I can think of is to slam the mouse button into a keyboard button at high speed. This causes some delay from physical key pressing speed, which is acceptable because humans have delay from pressing keys too. The computer times these events accurately on both Windows and Linux, and on a variety of tested consumer PCs/laptops. Choosing a good mouse button is important.

The problem is there isn't a good baseline for mouse latency. At least so far all I've seen are mice compared with other mice. Repeatability might also be an issue. There's also the uncertainty added by the USB polling interval. At best you're looking at a couple ms uncertainty in either direction on the relative measurement, without an absolute baseline.

I have some data on latency testing; see the attached zip.

USB polling interval is a true, accurate 1000Hz. My computer accurately captures my 1000Hz mouse movement. Also see "keyboard latency namenlos 1.png" in the zip; the Dell measures very consistently. Most devices have problems on the order of >8ms, so the USB polling rate becomes unimportant.
The reason I expect the mouse button to work is that bumping devices together gives bounds on the jitter of both devices, assuming no correlation (a somewhat big assumption). If device A has jitter range 5ms and device B has jitter range 7 ms, bumping them together will give 12ms jitter range.

Your arduino is better than a mouse, the mouse just takes less effort.

Mice have been tested extensively, both through bumping and through more rigorous video: https://www.gamersnexus.net/guides/2594 ... s-vs-wired http://archagon.net/blog/2017/05/24/mx- ... surements/ Many other measurements exist, although I can't find them now. Mice usually suck, but some of them don't and are worth using to measure against. The ones near the top of this list are probably better, since jitter adds latency, so less latency loosely implies less jitter. You'd still have to account for the mouse button jitter, but short of electronic measurement or video measurement, bumping objects is the next best method, mainly because it is easy and accessible.
There are some other good sources in the folder, like "keyboard input lag.jpg". The bottom of the image is the Corsair Rapidfire K70, with known <=8ms jitter range.

EDIT: the max upload size got me. I had to remove most stuff from the zip.

[Sparky]

The three approaches I think are best all have in common a test platform capable of both GPIO and USBHost.

The easy way I can think of is to slam the mouse button into a keyboard button at high speed. This causes some delay from physical key pressing speed, which is acceptable because humans have delay from pressing keys too. The computer times these events accurately on both Windows and Linux, and on a variety of tested consumer PCs/laptops. Choosing a good mouse button is important.

The problem is there isn't a good baseline for mouse latency. At least so far all I've seen are mice compared with other mice. Repeatability might also be an issue. There's also the uncertainty added by the USB polling interval. At best you're looking at a couple ms uncertainty in either direction on the relative measurement, without an absolute baseline.

I have some data on latency testing; see the attached zip.

USB polling interval is a true, accurate 1000Hz. My computer accurately captures my 1000Hz mouse movement. Also see "keyboard latency namenlos 1.png" in the zip; the Dell measures very consistently. Most devices have problems on the order of >8ms, so the USB polling rate becomes unimportant.
The reason I expect the mouse button to work is that bumping devices together gives bounds on the jitter of both devices, assuming no correlation (a somewhat big assumption). If device A has jitter range 5ms and device B has jitter range 7 ms, bumping them together will give 12ms jitter range.

Your arduino is better than a mouse, the mouse just takes less effort.

Mice have been tested extensively, both through bumping and through more rigorous video: https://www.gamersnexus.net/guides/2594 ... s-vs-wired http://archagon.net/blog/2017/05/24/mx- ... surements/ Many other measurements exist, although I can't find them now. Mice usually suck, but some of them don't and are worth using to measure against. The ones near the top of this list are probably better, since jitter adds latency, so less latency loosely implies less jitter. You'd still have to account for the mouse button jitter, but short of electronic measurement or video measurement, bumping objects is the next best method, mainly because it is easy and accessible.
There are some other good sources in the folder, like "keyboard input lag.jpg". The bottom of the image is the Corsair Rapidfire K70, with known <=8ms jitter range.

EDIT: the max upload size got me. I had to remove most stuff from the zip.

The gamersnexus link is a good test method.

The high speed video method works a lot better if you use a full screen program running at several thousand fps with vsync off. as is, the error from the refresh rate of the monitor, and graphics pipeline, is bigger than the signal you're trying to measure. uncertainty would exceed 17ms. With a CRT, high framerates, and vsync off, this method can get you within a couple ms.

As for latency and jitter from the perspective of designing a mouse, for movement you're pretty much at the mercy of your chosen sensor, but for click latency there isn't a good excuse to take more than 1ms.

Keyboards are a bit more complicated, because of how keys are scanned. It's entirely possible to scan important gaming keys more frequently, though this will increase the latency of the rest of the keys. I wonder how much of a premium people would pay for a keyboard with <1ms latency, shouldn't add more than about $10 to the BOM cost to get the extra IO.

[ad8e]

The gamersnexus link is a good test method.

The high speed video method works a lot better if you use a full screen program running at several thousand fps with vsync off. as is, the error from the refresh rate of the monitor, and graphics pipeline, is bigger than the signal you're trying to measure. uncertainty would exceed 17ms. With a CRT, high framerates, and vsync off, this method can get you within a couple ms.

As for latency and jitter from the perspective of designing a mouse, for movement you're pretty much at the mercy of your chosen sensor, but for click latency there isn't a good excuse to take more than 1ms.

Keyboards are a bit more complicated, because of how keys are scanned. It's entirely possible to scan important gaming keys more frequently, though this will increase the latency of the rest of the keys. I wonder how much of a premium people would pay for a keyboard with <1ms latency, shouldn't add more than about $10 to the BOM cost to get the extra IO.

Video can be supplemented with the computer's internal clock. Each frame will record the microsecond timepoint it started rendering at, and the computer will record the millisecond click timepoint. You capture the mouse click on video and can tell where in the frame it landed. Total latency would be (video-recorded start-of-frame time) - (video-recorded click time) + (computer-recorded mouse time) - (computer-recorded start-of-frame time). This solves the 17ms uncertainty.

For mouse button latency, I agree with you. The lowest-latency mice buttons are probably at that level of 0-2ms. Building a good switch requires good electronics, tactility, and durability. Switches are usually outsourced to Huano/Omron for tactility. Omron switches often have double-click issues, but rarely ever phantom clicks, so their debounce algorithm likely has hysteresis on the wrong side (slowing down an On signal, but insufficient minimum gap between an On and Off signal). Huano switches are less popular so there's less info about any problems they have.

For a performance premium, you'd have to get past the marketing. Cherry has RealKey which third party testing disapproves of, and Bloody has Lightstrike whose differences in latency create out-of-order typing, and Corsair has Rapidfire which is the best of the lot but it still doesn't test very well. Nearly all the custom mechanical keyboards have worse behavior than rubberdome keyboards; the random dudes making them usually know nothing about either electronics, firmware, or software. The tiering is something like: Rapidfire < Romer-G < RealKey < Lightstrike < Standard mechanical < rubber dome < "Custom" mechanical. The consumers don't notice what they're buying or they believe the manufacturers' nonsense. So how would a great product make a consumer understand how great it is, that this product is the one that's actually good instead of just marketing?

I still believe it's possible. The manufacturer could publish a lot of data directly comparing their product to their competitors'. But so far, no manufacturer has been willing to do this.

[Sparky]

For mouse button latency, I agree with you. The lowest-latency mice buttons are probably at that level of 0-2ms. Building a good switch requires good electronics, tactility, and durability. Switches are usually outsourced to Huano/Omron for tactility. Omron switches often have double-click issues, but rarely ever phantom clicks, so their debounce algorithm likely has hysteresis on the wrong side (slowing down an On signal, but insufficient minimum gap between an On and Off signal). Huano switches are less popular so there's less info about any problems they have.

Debounce algorithm is decided by the person designing the mouse, not the people making the switches. Delay based debouncing is responsible for those phantom clicks, spurious double clicks, and releasing during a drag, with a tradeoff between the length of the delay, and the reliability of the debouncing. It is true that switches with different bounce characteristics need different types of delay to reliably debounce. However, you only need delay based debouncing with single throw switches, and basically all mice have double throw switches. Double throw switches don't need any complicated debounce logic, you just need to actually use the second contact to get reliable delay-free debouncing. Unfortunately a lot of mice just use a single switch contact. You can decide for yourself if it's because of incompetence, planned obsolescence, or some other reason.

If you just use a single contact on a mouse switch, there can be 100+ms of indeterminate state when you release a button, so release-only delay will start to impinge on legitimate repeated clicks.

For a performance premium, you'd have to get past the marketing. Cherry has RealKey which third party testing disapproves of, and Bloody has Lightstrike whose differences in latency create out-of-order typing, and Corsair has Rapidfire which is the best of the lot but it still doesn't test very well. Nearly all the custom mechanical keyboards have worse behavior than rubberdome keyboards; the random dudes making them usually know nothing about either electronics, firmware, or software. The tiering is something like: Rapidfire < Romer-G < RealKey < Lightstrike < Standard mechanical < rubber dome < "Custom" mechanical. The consumers don't notice what they're buying or they believe the manufacturers' nonsense. So how would a great product make a consumer understand how great it is, that this product is the one that's actually good instead of just marketing?

You'd basically need to handhold all the reviewers through the latency measurements. As for marketing, probably start with the people that will actually notice and care, like the people that play rhythm games, and various forums dedicated to keyboards. Once you've got the core sold on pure merit, you can go after the masses with all the usual marketing bull. latency test all the competitors then say you're 4x faster than X! 10x faster than Y!! Endorsements from some carefully selected professional gamers, etc.

I still believe it's possible. The manufacturer could publish a lot of data directly comparing their product to their competitors'. But so far, no manufacturer has been willing to do this.

Well yeah, naming and shaming without being able to prove the clear advantage is kinda asking for a lawsuit.

[ad8e]

Debounce algorithm is decided by the person designing the mouse, not the people making the switches. Delay based debouncing is responsible for those phantom clicks, spurious double clicks, and releasing during a drag, with a tradeoff between the length of the delay, and the reliability of the debouncing. It is true that switches with different bounce characteristics need different types of delay to reliably debounce. However, you only need delay based debouncing with single throw switches, and basically all mice have double throw switches. Double throw switches don't need any complicated debounce logic, you just need to actually use the second contact to get reliable delay-free debouncing. Unfortunately a lot of mice just use a single switch contact. You can decide for yourself if it's because of incompetence, planned obsolescence, or some other reason.
If you just use a single contact on a mouse switch, there can be 100+ms of indeterminate state when you release a button, so release-only delay will start to impinge on legitimate repeated clicks.

You're right. I just assumed the switches had internal logic to stabilize the signal, but they don't. It's odd to me that the market has settled on only two manufacturers for a simple product. I also didn't know the bouncing time was so long.

You'd basically need to handhold all the reviewers through the latency measurements. As for marketing, probably start with the people that will actually notice and care, like the people that play rhythm games, and various forums dedicated to keyboards. Once you've got the core sold on pure merit, you can go after the masses with all the usual marketing bull. latency test all the competitors then say you're 4x faster than X! 10x faster than Y!! Endorsements from some carefully selected professional gamers, etc.

Well yeah, naming and shaming without being able to prove the clear advantage is kinda asking for a lawsuit.

I think it might work. A "definitive" table of keyboards listing only objective data like keyswitch type, latency benchmarks, actuation force, decibels, and ordering precision might draw significant attention as a central, cohesive source of information. By staying away from non-reproducible data like durability or subjective feel, it would be hard to be attacked legally. And if a manufacturer is proud of its product and can't publish results directly, your idea of handholding/sponsoring a third party through the process is an excellent one.

Keyboard enthusiasts care about their keyboards and are willing to pay major money for minor improvements. The main issue is that they're unaware of what happens inside their keyboard (me included), so they end up buying garbage. To some extent, education would serve in place of marketing.

[Kheri]

I've been looking at some sites that measure keyboard latency and even one that records key presses with a high speed camera to determine keypress travel time. It'd be nice to know how much input latency Logitech keyboards and other popular but affordable keyboards have.. Somewhat interesting stuff, imo.

[life_at_1ms]

Very useful thread. https://danluu.com/keyboard-latency/ references this thread claiming that the Apple II measured the lowest input device -> on screen latency. However, I'd like to get your take on how to achieve the lowest today. These tests claim lower latency is possible today than Dan measured in the Apple II: https://www.blurbusters.com/gsync/gsync ... ettings/3/

a) Can one have the lowest latency computer to date using the latest hardware?
b) What is the lowest latency hardware, in your view?

Secondly, there are claims of optical keyboard switches being the lowest latency. I'm trying to replace my mechanical keyboard's switches with the lowest latency - but even after asking manufacturers it is hard to get claims & benchmarks. Few seem to care about determining keyboard switch latency. Thoughts on which are the lowest? And yes, I'll be setting the keyboard to 1ms polling - and currently trying to determine how it scans the keys.

Thirdly, testers now seem to concur that the top bluetooth & wired mice are the same latency? Do you concur? If so, then what do you think is the lowest latency (in sensor & clicker) *wired* mouse?

Fourthly, is there any evidence USB4 will bring lower latency? I haven't seen any.

Fifth, Dan seems to be claiming that the latency in modern computers is partially coming from the computer between the screen & input devices. Do we have any accurate measurements of that part of the path? I don't see how it would cause more than 1ms latency (not including heavy processing needed to draw the graphics for a game, or something - I'm just talking about button presses and cursor movement).

Thanks!