While everybody is focused on mouse lag, there’s little attention to keyboard lag. I’m going to explain to you why keyboard input latency matters, what influences it, and what you can do about it.
Why keyboard input latency matters
You know that argument that people used to have about 30 fps versus 60 fps? “The human eye can’t see the difference” and you don’t need more than 30 frames per second. By now you know better.
That’s because people can perceive latencies down to 2ms or less. Moreover, the increased latency can also influence your accuracy. If you then realize that modern keyboards can still have a delay up to 60ms, you might want to be a bit more careful with your next purchase.
If you’re a competitive player then this is a no-brainer. You need to have the shortest input delay possible. You’ll see competitive CSGO players using expensive 120hz+ or old CRT screens, the most praised mouse (sensor) and complain about server tick rates or tweaking game settings for the least input latency. But they never stop to consider that keyboard lag is the biggest enemy of them all.
I’m not talking about any Windows software tweaks, or the perception that USB polling is a limiting factor that frequently appears in the CSGO community.
I’m talking about the actual keyboard hardware, because that’s where the real input lag starts.
Don’t be fooled by any marketing you see out there. Gaming companies like to make wild claims that are either deceptive or blatantly wrong. Just so that they can tell you exactly what you want to hear, not what you get.
If a product has “gaming” in its title these days, it’s for marketing, an excuse for its ridiculous design and RGB effects. It definitely doesn’t mean it’s optimized for (competitive) gaming.
Input latency versus input accuracy
There’s a difference between the input latency and accuracy of a press. If you only need the fastest reactions, you’re looking at getting the least input lag. If you only need consistency in repeated presses, you’re looking at getting the best accuracy.
In Rhythm games, like OSU, you want the fastest input speed, but also the highest accuracy. Each action in OSU has a 80ms time frame to react or less for a perfect 300 score. This needs to account for your reaction time, movement, and input lag.
Your reaction time will likely consume the most, and the best way to combat it is by tapping at a rhythm and knowing exactly what’s going to come next. That’s why practice makes perfect.
You can increase your accuracy not only with the shortest input delay but also by coupling the point of most impact with the point of activation.
I’m going to focus solely on input latency from here on out.
The parameters of input
Before we step into what exactly influences the input latency, I’m going to dissect the steps a keyboard takes for an input to PC. It’s an oversimplification that only takes the main and most easy digestible parts.
- Key input is the actual physical press of the key.
- Scan rate is the frequency at which the keyboard microcomputer chip (MCU) reads the keys.
- MCU processing is the time it takes for the microcontroller (MCU) to process the input.
- USB polling is the frequency at which the PC checks for input from the keyboard.
- PC software is the time your operating software (OS) and the particular program/game your using needs to process the input.
Input latency influence factors
Now that you understand the journey of input latency, it’s time to look at what can influence it at a digestible level.
Switch travel distance
Switch travel distance influences step 1, Key input. Travel distance can have a huge impact in reaction time. According to a project about keyboard latency by Dan Luu, travel time can account up to 10ms. This is not taking into account any adjusted behaviour to minimize travel. Such as pre-loading and not pressing till the end.
In short, you could say a combination of the shortest travel distance and highest actuation point will result in the fastest key input. Also when you repeat a key press, any travel after the actuation point is wasted time.
This means that a switch type like scissor-switch with a 1~2.5mm travel distance will often have the fastest physical key input.
To put it in a plain comparison:
|Switch type||Travel distance||Typical actuation point|
|“Low-profile” mechanical switch||~3mm||1.2mm|
|Rubber dome||3.5~4mm||At end|
But be aware, when a keyboard has rubber-dome type of switches, and any laptop with scissor switches. These are often coupled with a membrane computer board, which you should avoid at any cost if you’re into the least latency with the most reliability.
There are switches specifically made for faster key input, such as the Cherry MX speed switches. They actuate at 1.2mm and travel up to 3.4mm.
Then there are unique type of keyboards that allow you to adjust the actuation point. At time of writing, limited to the Wooting one using modified Flaretech Prism switches and Topre Realforce RGB using Topre switches.
The Topre keyboard has 3 different actuations at 1.5, 2.2 and 3mm and the Wooting keyboard can be adjusted anywhere between the 1.5-3.6mm.
It’s arguable that a higher actuation point might not be very practical at all times. You’ll accidentally press a key and experience a frustrating time typing. So it’s important to take this in consideration.
Keyboard Scan Matrix
Every key on the keyboard is connected to the MCU, the brains on the keyboard. But there’s a limit to how many connections you can make to a MCU, let alone that it’s very impractical to literally connect numerous keys. That’s why there’s a thing called a scan matrix.
A scan matrix are all the keyboard keys divided in a grid layout, so you will only need to connect the rows and columns instead of every key itself. It’s like a chess board that uses alphabetical columns and numbered rows to determine a chess piece location.
By making only 16 connections (8 rows, 8 columns), it’s able to read 64 keys. Just enough for a 60% keyboard.
In terms of input latency, a matrix layout is not ideal because it’s an extra layer of complexity. It’s vunerable to ghosting and terrible non-optimized engineering. The often misinterpreted ghosting and related key-rollover do not directly influence input latency. But It’s a tell-tale for the quality of engineering and where costs were saved. A topic for another time.
It’s near impossible to find a keyboard that doesn’t utilize a matrix layout. You rely on the manufacturer to make the most effective matrix layout that doesn’t compromise input latency for lower cost.
Wooting keyboard scanning
Scanning with a matrix layout is limited to a digital signal. It doesn’t actually read the key input itself, but by logic decides if it’s either ON or OFF.
The Wooting one needs to read every single key analog signal for analog input. Therefore it can’t rely on a matrix layout. But connecting every key to the MCU is extremely inefficient.
That’s why all the Wooting one keys are divided in 6 rows, each row connected to a multiplexer. The multiplexer is a nifty component that can connect multiple keys with a single connection to the MCU. It’s like a network switch that allows more devices to connect to your router.
You don’t often see it in a keyboard, because it’s a more expensive solution than a matrix layout.
A direct connection between a key and the MCU is optimal for the least input lag.
Keyboard scan rate
Ever wondered how a keyboard knows you pressed a key? You would expect that pressing a key would send a signal to the MCU that it’s pressed, similar to how a PS/2 connection works. But in fact, it’s more similar to USB polling.
The MCU will check all the keys every x amount of time for input. It’s literally asking every key, “hey have you been pressed yet?”. This is referred to as the keyboard scan rate.
The keyboard scan rate can happen at different frequencies, often referred to as an x amount of hertz (Hz), just like the USB polling rate. A scan rate of 1000hz is equal to 1ms. This means that the MCU will check every key, every 1ms for input.
In theory, if a key is pressed faster than the scanning rate, it won’t be detected. But in reality that’s near impossible to achieve unless you’re dealing with a real junk keyboard.
Instead, during the time that the key is in its “on” state the keyboard scan will cycle by and pick it up. The moment the keyboard scans will never be in sync with the exact moment you activate a key.
This means that once you activate a key, it needs to wait for the next scan cycle to pick it up. This adds a delay variable. The lower the frequency, the longer the cycles, the longer the input lag.
• 125hz / 8ms
• 250hz / 4ms
• 500hz / 2ms
• 1000hz / 1ms
A lot of keyboard manufacturers don’t bother to implement a scan rate of 1000hz. It takes a higher toll on the MCU and they will argue that there’s switch debounce time. But in fact, a faster cycle means that in all cases the key will be picked up faster in its next cycle.
Switch Debounce Time
Inside a mechanical switch when the two metal contacts touch each other, it has an unstable signal caused by the impact vibrations of the contacts. This is called bouncing. Debouncing is any kind of hardware or software that ensures that the signal is stable enough to read.
Often a software solution is used. The keyboard firmware will delay reading the key until the signal is stable enough. If the implemented delay is not long enough, you will get multiple inputs from a single key press, also known as key chatter.
Depending on the quality of the switch, the bouncing time will vary. The most popular Cherry MX switches have a bouncing time of up to 5ms. This means the software delay should at least be 5ms or higher.
In reality however, the manufacturer will often add a longer software delay because the switches will corrode over time and require a longer debounce time. A longer debounce time also helps them reduce the amount of defects.
Afterall, 100+ switches are installed on every single keyboard, if even one of those switches has chatter, the entire keyboard has to be returned. That’s a costly expense.
To put things into perspective.
If you buy an extremely cheap mechanical keyboard from Amazon, you can expect the following:
- The switches are from an unknown manufacturer with unknown quality.
- The switches were not sorted and tested for key chatter.
- The keyboard firmware has a very high debounce time to compensate for above.
It’s also no wonder that there isn’t a single keyboard manufacturer that will openly talk about it.
The Wooting one uses Flaretech optical switches, these have a bouncing time of 0.03ms. The Wooting one scan rate is 1000hz (1ms) and, therefore, isn’t limited to the switch bouncing time.
It’s very common for manufacturers to tout 0.2ms input latency, while in reality this only accounts the switch bouncing rate and says nothing about the actual input latency.
There are also other switch technologies with low bouncing times, but you better stay clear with anything that has a membrane computer board, like rubber dome keyboards. If you value input latency, stay clear of this. Just no.
MCU Processing Time
Your keyboard has a little chip inside called a microcomputer chip (MCU). It’s just like your computer central processing unit (CPU). It has the task to process every input into a keyboard firmware defined output.
A faster MCU can handle more processes at the same time and make calculations faster. But it’s also heavily dependent on how efficient the firmware code is written. It’s similar to how you can have the exact same gaming gear (the MCU) as a professional gamer (the firmware code), but perform nowhere as good because you’re not as efficient and effective as the pro.
Then you also have to consider that if the MCU is loaded with a lot of processes at the same time, it will slow down every other process including input latency.
Running a RGB effect/animation can take a great toll on the MCU. It requires a lot of processing power and will delay other processes. Just like when you play a game with extreme graphics while live-streaming, your CPU will get overloaded and significantly decrease your frames per second.
Better turn off those RGB effects.
USB polling versus PS/2 interruption
The connection to the PC is another point of input lag. These days all keyboards use a USB connection, previous generations used PS/2. These two connections inherently work different.
PS/2 is an interrupt type of connection. The keyboard will send a direct signal to the computer CPU interrupting any action it’s performing and tells it to execute the key input.
USB is a polling type of connection. The CPU will check every x amount of ms for input, just like the keyboard scan rate.
The theory is that PS/2 interruption is a faster input connection than USB polling. But in practice this doesn’t have to be true anymore. It’s very hard to find any PS/2 compatible keyboards and computers these days. Even if you make use of a keyboard that has it, it doesn’t guarantee it’s faster than USB polling. Modern motherboard designs and CPU’s aren’t optimized for legacy connections, such as PS/2.
You can reread the keyboard scan rate section to further understand how USB polling works. It also applies to the connection to the PC.
- 125hz (8ms) /250hz (4ms) /500hz (2ms) /1000hz (1ms) are the most common frequencies that USB will scan.
- Always aim for 1000hz (1ms) polling
- Input lag occurs when a sent signal is not in sync with the scan. It will have to wait for the next scan cycle before it’s sent.
Computer OS and Application software
Welcome to the biggest variable ever. If you read the MCU processing time section, then this same theory applies to your computer operating system (OS). When it receives the input it needs to process it to an output. Afterward, the application you’re using will process it to an output.
This part entirely depends on the efficiency of the software code and how it handles input. In general, the less your CPU is burdened, the faster the input can be processed.
The difference in input will widely differ depending on the application you’re using. That’s why it’s not only the task of your input device to be fast, but also the developer. A developer can make a huge difference in input speed by writing optimized code and increase the input cycle.
Monitor refresh rate
Update 2019-10: We’ve been informed that the monitor refresh rate is not the full picture. On modern monitors the display needs to process the frames sent from the computer, which is a big factor in the total input lag. Since this article is focussed on the keyboard part we will refer to this excellent website for the full picture on monitor input lag: https://displaylag.com/display-database/. Credits to Tyler for pointing this out.
Your monitor refresh rate doesn’t directly influence your input latency, but it does influence the moment you will visually see the input. This indirectly adds to the latency and will influence your response.
You can find (gaming) monitors ranging from 60hz up to 240hz refresh rate. This means that the monitor is capable of refreshing the graphics from 60 up to 240 frames per second (fps). Though, your computer might not be able to reach 240 fps in the majority of games.
The most common monitors have 60hz refresh rate. That’s 60 frames per second, 1 frames every 17ms. If your moment of input comes in at the start of the refresh cycle, it will need to wait 17ms before you’ll see it. In average, the input lag caused by a 60hz monitor will be 8.5ms.
On a 240hz monitor, with the ability to run a game at 240 frames per second, the input lag will average 2ms.
You can also calculate how much input lag your monitor causes.
1 / Game FPS * 1000 = maximum delay in milliseconds. If you divide it by 2, you’ll have the average.
How Wooting measures input latency
At Wooting we take input speed optimization very serious and are continuously pushing the limits but there are some limitations to what we can measure ourselves. We’re focused on what happens on the keyboard.
We use an oscilloscope to measure the frequency of the keyboard scan rate. This device can measure electric signals that vary over time. This is also how we can measure the latency with high accuracy. We have a bit more modern oscilloscope you can connect to your PC.
The oscilloscope is connected to 1 of the 6 rows in the Wooting keyboard, when a scan happens it will trigger the electric signal. After the first row, it will scan through the 5 other rows and start back at 1 again. So to measure the scan rate, which is how fast the entire keyboard is scanned for input, we calculate the time in between two triggers on the oscilloscope.
As you can see from the test results above, there’s a stable and frequent electric trigger happening every 0.96 milliseconds (ms). It’s expressed in 960 microseconds on the test result.
This means that the keyboard scan rate is just under the 1ms (0.98ms) or at a 1000hz polling rate.
This however only takes the scan rate into account and not any of other mentioned influence factors.
We are working together with several parties to get accurate and more in-depth input latency results.
For instance, there’s a researcher, Sunjun Kim, that had tested the Wooting one from keyboard input signal to the PC receiving it within 4.2ms. He was also able to deduct the keyboard scanning + MCU calculation time to 2.5ms.
Testing tools on the PC are not reliable
As a final note to input latency and their influence factors. You can’t rely on software tools from the internet or PC to accurately measure input latency. These tools will only be able to measure the latency on the PC itself and are not capable of testing input lag on your device.
For the most accurate measurements, you’ll need to rely on external devices that monitor events coming from the device.
You’re welcome to leave feedback or contribute to this post. If you have more information, references or want to challenge some of the ideas mentioned, leave a comment behind or reach out to firstname.lastname@example.org
I also have to mention that this post didn’t go into extreme depth, to keep it light and easier to understand.