Keyboard latency is largely ignored by everyone except gamers (and marketers targeting gamers), but I find it's much of the subjective "feel" of an editor/OS/input device stack. I'm sure others have found working in a VM unpleasant for this reason. I want to look at a source of latency nobody else seems to have examined closely: switch travel (more specifically, "pretravel").
how bad is it?
Some people have examined latency of operating systems, text editors, and terminals, and some people have examined the switch actuation to userspace end to end latency (to examine keyboard firmware). To my knowledge, nobody has compared switches themselves. There are two latency-relevant parts of this:
- actuation technology (not the subject of this blog post)
- switch travel distance (pretravel)
This graph by HaaTa shows force vs. distance of a standard switch used in mechanical keyboards: the Cherry MX Blue. Note travel at the actuation point (the pretravel): about 2.3mm. How long does it take to travel that distance?
We could measure this, but I don't have a high speed camera or a tiny accelerometer to stick on a key, or... anyway, let's estimate it with a simple model. The human's finger starts at x=0, t=0, v=0, and then a constant acceleration is applied until x=pretravel (for a Cherry MX Blue, 2.3mm). So what's the acceleration? How fast does a human finger accelerate on a keyboard? I polled IRC and the median guess was about 10g. I did a quick literature review and found a two possibly useful numbers:
- "Rate Effects on Timing, Key Velocity, and Finger Kinematics in Piano Performance" says that a pianist's finger acceleration gets up to around 10m/s^2, which seems pretty slow, but music is more about timing than reaction time. On the other hand, this is the acceleration you can get at the fingertip while applying your whole body; it's harder to accelerate from 0 with just finger motion.
- "Identification of the mechanical impedance at the human finger tip" was pretty confusing to me but I think it has a graph that shows a finger pushing something button-like with a peak of 140m/s^2, which seems very fast, but close to the intuitive estimate.
For a Cherry MX Blue, pretravel takes (at 10m/s^2) about 21ms. If we instead use 140m/s^2, it takes about 6ms. For a standard laptop keyboard with pretravel of 1.5mm, at 10m/s^2, it takes about 17ms. At 140m/s^2, it takes about 5ms.
With estimates of acceleration varying by 10x, this doesn't seem very useful. However, even if we pick the slower acceleration, the difference is about 4ms. With a "normal" end-to-end latency around 100ms, it's fair to say variance in switch travel is a modest portion of total latency. For anyone desperate for those last few ms, may I suggest Apple's much-maligned new laptops with a travel of 0.5mm? Or try out some finger exercises.
Dan Luu's keyboard latency tests imply to me that firmware is the largest factor in keyboard latency. In our context, however, we can look at two keyboards we may assume are well-programmed: Apple's low-travel membrane/scissor switch keyboard is measured as 10ms faster than Das's Cherry MX Blue keyboard. This seems to be in line with the added costs of debouncing time (5ms) + travel time (5ms), which approximately supports my estimate above.
I would like to see someone (else) do measurements specifically of pretravel time. If I revisit this topic, it will probably be focusing on measuring and optimizing firmware latency, rather than switch choice and pretravel.
Pavel Fatin's great writeup on latency in the context of text editing doesn't consider switch travel, but is a fantastic read.
Dan Luu's input lag comparison over various computers from 1977 to present (conclusion: use an Apple IIe)