Keyboard latency
danluu.com
danluu.com
Not to mention that 100 ms is musically a 16th note at 150 bpm. Being off by a 16th note even at that speed is – especially for percussive instruments – obvious.
On the other hand, if you told me to strike a key less than 100 ms after some visual stimuli, I'm sure I couldn't do it – that's what "reaction time" is.
Look at this video on Youtube from Microsoft Applied Sciences Group: High Performance Touch.
https://www.youtube.com/watch?v=vOvQCPLkPt4
You can plainly see that 100ms is an eternity. While keyboards aren't the same thing, but high latency is noticeable. I had to change a keyboard because of the near eternity of when I pressed a key and when it registered on the screen. The difference between the old and the new is quite stark.
If you want to blind A/B test yourself, run this:
DELAY='0.1'; VALUES=(0 0); VALUES[$((RANDOM % 2))]=$DELAY; alias test_a="sleep ${VALUES[0]}"; alias test_b="sleep ${VALUES[1]}"
I can get down to 24ms but no less... the weird thing is that 24ms is still completely obvious to me (clearly shorter but obvious in comparison to no delay), with a single test I can see which variable has the delay every time, but 1ms less and I can't... which makes me suspect it's being quantised due to any of the various things in between sleep and the output, display, driver, X, terminal emulator, CPU etc.
With that it's actually possible that my 24ms is larger than 24ms and is also being quantised to a larger duration (but not larger than 100 for sure).
It would be interesting to be able to test with some dedicated hardware.
It's not quite a keyboard delay test but more of a general human reaction time test.
The best I can do is 160ms after 5 tries on a 2560x1440 60hz IPS panel.
https://jsfiddle.net/zs8bncxj/1/
I can still get it right pretty much 100% of the time, but the difference does feel a lot more subtle than what I was seeing in iTerm.
(If you change the delay, you need to hit randomize to make it take.)
Edit: Also we should keep in mind that we're not testing the latency we set in either test. We're testing that delay plus the delay from I/O. So 100ms might be indistinguishable. But by the time we pile everything on, we're getting closer to 200.
The result is the same as far as UI design is concerned; don't assume that you can get away with 100ms; most of that leeway has already been wasted by the OS and hardware.
Personally I can distinguish every time at 0.06.
I find it difficult to believe the rest of the hardware loop has 40ms latency, it would be difficult for smooth rendering to occur if it did.
I suspect that part of this is 'training' yourself but also what the researchers meant. They may very well have meant that above 100ms is jarring and noticed as a delay but below 100ms is not seen as a delay rather than truly being unable to notice in an A/B test.
I suspect this test would be more difficult if it sometimes did A/A and B/B.
Why would I/O latency have any effect on the smoothness of rendering? Are you sure you aren't thinking of throughput?
Remember: TFA just told us that many keyboards on their own add more than 40ms of latency. I definitely wouldn't have guessed that, so I'm very reluctant to entertain any certainty about the rest of the system having low latency.
I'm using Alacritty, which is supposed to be really fast and everything!
Try it out.
EDIT: Which the original author said better than me:
> Another problem with this line of reasoning is that the full pipeline from keypress to screen update is quite long and if you say that it’s always fine to add 10ms here and 10ms there, you end up with a much larger amount of bloat through the entire pipeline, which is how we got where we are today, where can buy a system with the CPU that gives you the fastest single-threaded performance money can buy and get 6x the latency of a machine from the 70s.
Unfortunately, programmers/UX designers have a tendency to generalize this rule and use it to excuse slow user interfaces.
There are plenty of examples on YouTube if anyone's interested.
Similarly, limited frame rate makes it impossible to keep the image at exactly the same place on the retina during smooth pursuit eye tracking, causing perceived blur that wouldn't be seen with a real life moving object.
Seeing a difference with 1000fps video doesn't mean we have 1ms temporal resolution perception, it just means some test signals allow conversion of temporal information to spatial information by eye movement. It doesn't generalize to arbitrary visual events. To investigate keyboard latency sensitivity properly there's no substitute for ABX testing of actual keyboards.
There's a difference in constant, but consistent lag (delay) and variation of lag variance(lag)>0. If one note is a 16th note off that is lag variance.
The video game "Super Hexagon"[1] is a surprisingly interesting demonstration of this limitation, and how the mind tries to workaround the problem. The higher difficulties ("hexagonest"[2]) seem impossible at first. In the easier levels you can react, but now the time it takes to see the scree, parse the simple graphics, recognize that you need to turn left to avo##CRASH##...##GAME OVER##, You quickly learn that if you think about the game, you are guaranteed to fail due to insufficient reaction time. Winning requires a mental state possible related to meditation: don't think, let the muscle memory do it's job (maybe from a faster path limited to the spinal-chord and brain-stem?).
[1] https://www.youtube.com/watch?v=UrPXBSh4mqU
[2] I finally got a winning 62.09s a few days ago, after many months starting at a high score of 58.57
https://youtu.be/TWiMnENdcyY?t=56
At this speed the player is reacting (and hitting with correct timing) about ten notes (arrows) per second. This is possible by memorizing and reacting to group patterns instead of individual notes, but more importantly, reacting unconsciously.
A player can play at this level without conscious attention, even while holding a conversation, or while focusing at different parts of the screen, or spaced out. It feels like the fingers play by themselves.
This is so automatic that the player may have little feedback on how well they are doing. They may think they are making blunders and about to lose, while "the fingers" have correctly hit every note so far.
Definitely feels like a faster neural path was built.
The first season was played very conciously and slow. After each season, I recognized that certain patterns just came out perfectly without difficulty. Sometimes I was even surprised by myself.
However, what I wanted to say is, it was enjoyable just letting the brain do its job of processing patterns and reacting to them. It was relaxing.
I think part of the reason is from my experience as an organist: some instruments have a noticeable delay from the time that the key is pressed to when the sound reaches my ears, whether due to delays built into the control mechanism itself, as well as sound delay (the console is sometimes located on the opposite side of the hall from the pipes). I think this has caused my brain to be wired to accommodate these sorts of situations.
Chivalry, for example.
Part of the fun is learning to control the wind up correctly so that you are in the exact place (you being a moving, rotating person AND then being a moving rotating person) somewhere in the future as opposed to "close in until within range/in-scope, then immediately triggering the left-mouse button." You have to continue guiding the attack as the attack is winding up.
Another interesting one is long range sniping in simulator and quasi-simulator FPS games like say, PUBG. There's bullet drop, and people can move toward, away, and side-ways. You've got to place the shot ahead of the target, for a given targets speed (walking vs running, vs in a vehicle), and lead the appropriate amount. The amount also changes with distance (obviously) as well as different guns have different bullet velocities (less velocity = more lead), as well as different scopes (2x/4x/8x/15x) which offer drastically different required mouse movements to get the appropriate crosshair movement (even if the "lead" corrected for magnification is the same).
God, I love our brains. I would love to read a textbook on EXACTLY that kind of learning. Subconscious, neural learning.
Oh, and that's one great thing about PUBG. The combination of low-level muscle memory for maximum speed target acquisition and firing, with the constant high-level mental strain of planning 2, 3, and 20 steps ahead. Solving for "this situation right now" (shot this guy on my screen AND how do I outflank this guy walking nearby but out of sight that is also trying to kill me), solving for "what happens next" (if I fire, will it attract another, full health, group of people that will kill me?) and solving for "how do I keep getting closer to the blue zone to reach the end game without dying."
All of those circuits are absolutely required to "win" in a game with 100 players and only one winner. For the fun of it, I really should write down my other mental processes that go on. Getting further in the game (closer to 100) is all about learning to train your brain into juggling many problems at the same time as well as specifically targeting areas where you are lacking. Like if you're not good at close combat, you can get near the end by sneaking but you will eventually die. And combat at short range, medium range, and long-range combat all have different strategies and tradeoffs. Combat with groups is different that combat with 1 enemy, or a pair.
Used to play (still could if I got back to it) at that difficulty with my keyboard. Got to the point where I could have conversations while playing. I also play guitar so I stopped playing Stepmania to avoid extra strain.
Super Hexagon doesn't allow any of that. The game is randomly generated each time, making memorization impossible. It's 100% reaction against the incoming wall pattern, with no pauses. Except you don't actually have time to "react".
I recommend this[2] essay that does a much better (and more poetic) job of explaining how uniquely Supper Hexagon interacts with human perception.
[1] https://www.youtube.com/watch?v=JRUwpUqSFbI
[2] https://problemmachine.wordpress.com/2015/04/11/hexagon/
But new versions come out, with new sets of songs, and people play songs of the same approximate difficulty as well. If it was simply memorization, they wouldn't be able to play same or near difficulty songs. They'd have to "ramp up" as they memorized the new song.
Obviously, people's brains are reacting to similar patterns (each song has a "style" and many songs are of the same "style" with things like jumps, diagonals, triplets and so on), as well as other subconscious neural reactions.
When you're playing 9-step (out of 10) step songs, you're not watching individual arrows at all. It'd be impossible. You unfocus your eyes and play through your peripheral vision. Your body reacts. You don't need to think at all.
(So nobody is arguing that the Hexagon game isn't "more random" . They're arguing that it's more than just randomness at play.)
It's really no different that carrying on a conversation while playing a game of casual pong with a friend. Everyone just calls it "muscle memory." The pattern is never the same with a ball bouncing off a table. It's not rocket science.
Being able to play a prima vista is a rather specialized skill even among musicians; I've only known a handful of people who can do it really well. I don't think it has a ton of utility (at least I never found it to have a lot) and so it's not something that many people actively develop or train, though.
Rock Band 4 has a "Brutal" mode where notes are almost completely hidden save for a slice of a millisecond at the top, but although it does give a hint of an information that may be processed in the end it mostly doesn't matter, since at that point you can effectively do it blindfolded, which is as a process no different to learning to play the actual song.
First of all, players don't need to memorize the charts. Take a good player, give him an entirely new chart and he will perform much better than any beginner ever will, even with memorization. Shuffle mode, where the notes are mixed and therefore can't be memorized is just a minor handicap. Much, much easier than memorizing a whole song.
There are two things at work here.
The reaction time is actually not that short. For high level play, players typically set notes to appear about 500ms before action. At that rate, anyone can hit a single note, the difficulty is that there are lots of them.
The difference between experienced players and beginners is that experiences players recognize blocks instead of single notes, just like you read entire words rather than individual letters.
This makes Super Hexagon more a game of quick pattern recognition than reaction time.
When I play it I am generally focused at the edges of the screen to quickly identify the next pattern and only using my peripheral vision to maneuver around the walls in the center.
I can comfortably send morse code at ~25wpm, approx. 125 characters/minute. ('Comfortably' meaning others can comfortably figure out what I am trying to send)
That equals ~375 hand movements/minute, or 6.25/second.
(Granted, I cheat - I use a single lever paddle and a microcontroller to get the timing exactly right.)
I've heard people going twice as fast, though that's very rare.
However, people more skilled than I can use a straight key at up to ~35wpm or so - that's ~9 taps a second, while also getting the timing just right without the aid of a microcontroller. That, in my book, is very impressive.
Part of practice is learning how to use muscle memory to handle the fast stuff – faster than you can process at full speed – freeing up your mind to think about the broader strokes. It's interesting to think that activities such as playing music, drawing, painting or practising sports are really a combination or interaction of fast muscle memory, slower rational/strategic thinking, and guiding emotion/intuition.
You've just described how people play music in general :P the patterns trigger memory and other internal processes (whether it's recalling verbatim or dynamically based on a new pattern from some combination of scales), this escapes the limitation of input output response time because it's all internal with some arbitrary output delay which we account for by "leading" whatever the physical action is (for an exaggeration think about percussion instruments).
If you are at all musical it's fun to do a bit of introspection here... with anything slightly complicated where you do not have time to think about the position of each note (a pretty unnatural way to perform) you will realise that your fingers (or toes in some strange cases), react to a sort of stream of signals internally... it's probably not even a stream but more of a parallel matching against the pattern from which you pick a stream of notes internally because this is right brain stuff.
Disclaimer: i'm not a neuroscientists or musicologists, I just like thinking about the brain and am slightly musical.
From what I recall, to finish the final level I was relying for the most part on 'muscle memory' in relation to the familiar patterns. I would visually interpret what kind of pattern it was, my position relative to the pattern and then there seemed to be a conscious disconnect to the actions I performed to get through the pattern.
I think it's interesting because the actions I'm referring to weren't merely a sequence of button presses performed as fast as you could. There was a critical factor of very small differences in durations between actions and how long you execute actions for that seem (and I assume are) completely beyond my conscious abilities.
As for the game you played, it must have been the DDR series. You can't "finish" Stepmania since it's an open source rhythm game where the community has created thousands and thousands of songs to to play.
One game that really demonstrated this to me was Crypt of the Necrodancer. It's a rougelike where each turn is the beat of a song, and the tempo of the song for each floor is slightly faster than the previous floor, starting at 120 bpm (1/2 second per turn) on floor 1 and topping out around 180 bpm (1/3 second per turn). For the slow songs, you have enough time between beats to fully plan your next action, but at some point, as the tempo gradually increases from floor to floor, you hit a point that this is no longer possible, and your brain has to "switch modes" to planning several beats ahead and thinking in patterns instead of individual moves.
I've spent quite sometime on super hexagon myself.
[1]: http://www.press.uchicago.edu/Misc/Chicago/093185.htmlOf course there is some threshold of latency when it starts to become noticeable/disconcerting for some fraction of people and probably quite a lot more when half of all typists start to notice. Anyone can definitely feel this on terminals connected to very remote machines.
This is an interesting topic and am glad that Mr Luu is looking into it. The measurements described are absolutely a valuable first step towards understanding what latency really means for human factors in typing (first, what is the f-ing latency). I expect the folks at Logitech and other places have significant proprietary research on this stuff, but maybe not?
I can see how high latency is acceptable if you're only putting in new characters, but as soon as I have to fix a typo or anything more complex, I get really mad really fast if the latency is anything beyond (ballpark estimate) 250 ms.
https://forums.blurbusters.com/viewtopic.php?f=10&t=1134&sid...
Some people in that thread are tolerant to 10ms...
So was he rushing or dragging?
That's how it goes with my ears when recording as well. Most "Live feedback" mechanisms for guitar programs (heck even computer-made guitar hardware) have about 50ms of latency, which is quite disconcerting when you're doing something heavily timing-based. 10ms is almost imperceptible to me (sounds more like the tiniest slightest reverb delay) and 5ms might as well be realtime as far as I'm concerned.
An example, in Windows 10, I could go to the built-in mixer, turn on the "Listen to this device" and play with my guitar plugged right into the computer, and you're looking at about 100 ms or so of latency. Completely unacceptable when you're listening to a metronome to keep on time. Alternatively, I can go to the Realtek HD Audio Manager in the taskbar (because I installed the actual RealTek driver package instead of relying upon the Windows drivers) and un-mute the line in, and even with an amp and mixer board in-line before the computer, the feedback is essentially instantaneous, which allows for pre-baked instant reaction times (eg muscle memory) to work and record in time with the metronome (or backing track.)
Another fun test you can do, if you have an analog mixer, is to run some input signal into the mixer, then to the PC, and then from the PC back out, and monitor both the original input and the signal from the PC at the same time. OS-supplied drivers typically make it sound like you're in the Grand Canyon.
But even with very expensive low-latency gear, you can still tell if you put one signal into the left headphone channel and another into the right. If there's actually zero latency, you'll perceive the sounds as coming from directly in front of (some people perceive as directly behind) you. It'll sound just like mono. Any latency, given the same volume level, will be perceptible as a difference in "location" of the sound.
My unscientific experiments suggest that you can perceive down to about 1ms latency quite clearly this way across most of the audible range. The minimum is frequency dependent (as you'd expect) with lower frequencies being less sensitive.
Presumably the human brain has evolved to be extremely good at arrival time comparisons (maybe even doing some sort of phase-difference stuff) as a way of triangulating the origin point of sounds. There are doubtless other specialized ways in which the brain is equally sensitive, so the 100ms rule of thumb seems pretty naive to me. 100ms might hold true for the "main loop" of the human brain at the level of conscious thought, perhaps.
What reasonably-priced DAC would you recommend?
In the market for one currently.
If it was audio cue, I'd point you to "Love Live School Idol Festival", a rhythm game which "perfect" judgement window is some 32ms. Decent players will get perfect most of the time.
> Not to mention that 100 ms is musically a 16th note at 150 bpm. Being off by a 16th note even at that speed is – especially for percussive instruments – obvious.
The auditory system is especially good at processing serial data, and it has a better timing resolution than the visual one.
People with visual-auditory synesthesia are much better at tracking patterns in flashes of light for example (because the hear the flashes).
Presumably he measured it the way he did because it's easier to measure, rather than because he thinks it's the more meaningful way.
(Though maybe his way is more useful if he's interested in whether a keyboard gives an advantage in gaming, rather than whether it's pleasant to type with.)
> This is because, as a human, you don’t activate the switch, you press the key. A measurement that starts from switch activiation time misses this large component to latency.
But I see he does goes on to say that he cares about game performance, rather than typing experience: « If, for example, you’re playing a game and start dodging when you see something happen, you have pay the cost of the key movement, which is different for different keyboards. »
For me, I don't care about the time after switch activation, rather about time after the tactile feedback (the "click"). Ideally the character would appear on the screen at the same time as the click; not after, and not before. If a keyboard can 'cheat' and activate the switch before that and hide some latency, that's fine by me.
In tacticale switches the bump and the making of the contact are mechanically connected.
Using the moment of finger/key contact quite obviously selects for travel, among other things.
Nope! This is rarely (if ever?) the case. In alps switches, for example, there are two totally separate leafs, one of which handles the tactile feeling and the other of which is responsible for the actual actuation. If you browse through Haata's Plotly[1] you can see that many switches actuate well after the tactile bump. Though they are often pretty closely related in terms of their depth in the keypress, they are wholly unrelated from one another mechanically.
Cherry MX.
The tactile event on a Cherry MX Brown is ~1mm into the travel distance, and the actual actuation is ~2mm in. Kaihua Box Orange switches (still an MX-style switch) is an even better example of that. Kaihua Speed Bronze has the actuation point inside of the tactile bump instead of after the bump. I can't find any examples of switches that actuate _before_ the tactile bump (mostly because why would anyone design that?), but tactility and actuation are not inherently tied together in cherry MX switches, either.
They are both handled by a two-part leaf, which you can sort of see in some of the pictures on Deskthority[1]. There are two legs on the slider that have a surface to them that determines the tactility (or lack thereof in the case of linear switches) that slide linearly up and down the top leaf, which flexes it until it makes contact with the bottom leaf. That contact causes the actuation. All of the tactility is determined bu the shape of the slider legs.
How the making or breaking of the contact is related in terms of travel to the key press force doesn't have much to do with that.
The point I made was simply that on other kinds of keyboards the two are not related. On a rubber mat keyboard you can keep the dome depressed yet not actuate, for example. The collapse of the dome is also harder to control than the resistance against the spring. That makes preloading harder.
I would guess (and maybe I'm wrong about this) that you rest your fingers on the keycaps, and press them in as far as needed to actuate, but no further. The key still needs to travel.
Not sure how much I press them down (will try to analyse at next opportunity), but whenever I play a FPS (which is admittedly nowhere as often as I'd like these days) I certainly "preload" the fingers on the WASD keys in such a manner that the press is far quicker than when I touch type.
Precision and responsiveness is far better than using a chiclet type keyboard such as the MS Sculpt, which compares a bit to the Apple Macbook keyboards from memory (although the new Macbook Pro has even shorter travel again). The Sculpt (or MBP) has much shorter overall travel compared to the Romers, but the feel of when you are off/on really doesn't compare; the keys feel dead in comparison for gaming. YMMV.
Still, I guess in a way, timing it from the start of a key press is the most real measure of actual latency when you want to press a key. It's just got nothing to do with the processor etc.
Now, my wrists also hurt. Now, when I'm not travelling, I was using an external Apple keyboard, not the MBP's primarily, so I'm hesitant to blame the MBP's keyboard directly. The external Apple keyboard has a greater keystroke distance from start to bottoming out, but still has like zero distance between actuation and bottoming out. (For some keystrokes, particularly ^+Tab and ^+Shift+Tab, I find it hard to keep control actuated, despite it being fully depressed; it just seems to require a lot of pressure to keep things in electrical contact). The pain in my wrists didn't start until I started using Apple keyboards, and has mostly stopped since I've replaced them. (I now primarily use an ErgoDox EZ, primarily for the split/ability to independently position my hands. I had tried, and had similar success w/ a Kinesis Freestyle, but I didn't own it.)
(I used a MBP keyboard for ~4yrs, with an ergo keyboard of some kind for when I'm not travelling for ~half of that. I've used Thinkpad's of varying models for ~10 years. Now, I could just be getting old, but replacing the Apple keyboard is what made the difference thus far for me. It doesn't make a lot of sense to me, admittedly: my wrists are, I feel, in the same bad position on the Lenovo as they are on the MBP/Apple keyboard.)
Not sure I can agree with that. I was using one of the Apple keyboards for quite a long time while running liveops on an online game (which meant rapid response whenever incidents happened, jumping into shells and constantly typing like my life depended on it), and developed fairly severe wrist problems within a couple months. To the point where I almost had to leave the job on disability, per my doctor's orders.
On the recommendation of a friend, before taking that step I tried switching to a Kinesis Advantage for the better wrist alignment and less "hard" keystroke bottom as compared to the chiclets on the Apple keyboard. It was a bit of a learning curve (~2 weeks to get up to full typing speed when using it every day, a couple more to push past it), but at the end of it my wrists got better almost instantly, and I never had problems again. My typing speed went up as well.
I'm not sure how much of that improvement is due to the better alignment of keys (there's almost no hand movement when typing, and your wrists are always neutral) and how much is due to the bigger key action and softer bottom, to be fair.
Edit: it's worth mentioning that I'm also a boxer and a piano player, so my wrists take a lot of abuse on a regular basis. YMMV and if you're not having problems, I definitely found the Apple keyboards to be very easy and fast to use.
The Natural keyboards are good, but IMO the Kinesis is a worthwhile upgrade for the mechanical switches, programmability and durability.
The Kinesis keyboards are actually heavily inspired by an even more expensive keyboard called the Maltron. http://www.maltron.com/store/p21/Maltron_L89_dual_hand_fully...
Truth be told, I also prefer scissor switch keyboards, but there aren't any on the market that support the features I'd like: - configurable keys & layers on a hardware level - 60% layout - NKRO
Apple's magic keyboard would be great if it supported configuration/NKRO and didn't cost so outrageously much.
> Contrast this to the Apple keyboard measured, where the key travel is so short that it can’t be captured with a 240 fps camera, indicating that the key travel time is < 4ms.
— - original comment — -
True gaming keyboards have mechanical switches which activate on first key press, not on full key down. Bit disappointed no mechanical keyboard was tested as they are perceived to be the ultimate keyboards when speed matters.
No, mechanical keys have some travel before actuation as well.
Buckling spring switches, membrane domes, topre (membrane dome + spring), etc. all have actuation points somewhere in the middle of the key travel, not at the start or end.
The OLKB and Ergodox don't state the switches used, but it's almost certainly a cherry MX style switch with non-modified actuation points compared to the original.
I disagree. One of the greatest benefits of mechanical keyboards is that they actuate before bottoming out. With some practice you can learn to type without bottoming out, which can greatly increase your typing speed, and decrease the amount of stress on your fingers and wrists.
I'm using Cherry MX Speed switches, which have a 1.2 mm actuation point and 45 g actuation force. There are no published numbers for the Apple keyboards and the closest I could find was ~0.75 mm distance and ~60 g force. Cherry MX Reds, the most common mechanical switches, have a 2 mm distance and 45 g force. (I mention the actuation force because there is probably a slightly longer delay for higher actuation forces due to deforming the fingertip and motor unit recruitment, both of which are probably minimal.)
On top of it, the author seems to be making a statement about speed being the deciding factor for gaming keyboards. If that was the case, they'd all be using ultra-low actuation switches, which they aren't. In most cases, a 'gaming keyboard' is just a mechanical keyboard with aggressive styling, higher quality components (less plastic, braided cable), macro keys, multi-key rollover, USB or audio passthrough, and backlighting.
Then he uses 1 membrane gaming keyboard and 1 no name import that I can't even find the manufacturer for as his only gaming keyboards. There are no sample sizes reported, he just does his best to hit two keys at once, and uses a camera for determining when the key press starts.
Every step of the process has huge flaws and he doesn't even use a reasonable set of devices. Sorry to sound harsh, but I trust zero of the conclusions/interpretations of the data.
I thought his explanation (that delay from the start of the motion) was a good one. Unless someone is starting with a key partially depressed/near the actuation point (which you certainly could do), the key travel time is going to be a part of the perceived delay. Seems fair to me, given that delay and perception are the point of the post.
Now, if you think that gamers are starting with partially-depressed keys and therefore will actually experience less of a keystroke delay, that would be a valid counterargument.
> Every step of the process has huge flaws and he doesn't even use a reasonable set of devices.
I don't think this is being portrayed as an especially accurate study; the author includes plenty of caveats.
The "gaming" keyboards he used were also pretty shoddy. Now, I'm not necessarily saying gaming keyboards offer better latency, because that's not why I got mine, but his methods seem weird.
Most people don't partially depress keys to my experience.
Furthermore, the OP is the first one doing real measurements on keyboard latency, so perhaps you should trust the article to hint towards a previous unnoticed problem.
Anyways, your comment is totally missing the point and makes generalizations based on one debatable measurement error.
Also his table lacks whether the keyboard is mechanical and the type of switch used.
This subject needs more research.
> Note that, unlike the other measurement I was able to find online, this measurement was from the start of the keypress instead of the switch activation. This is because, as a human, you don’t activate the switch, you press the key.
He mentions the fact that some keys activate mid-travel, and that the very short travel is part of what makes the Apple keyboard so fast.
So neither the keyboard matrix nor the debouncing justify a latency of 10 ms or above.
It is nice to see that latency is an issue in gaming now, similar to realtime audio, where most operating systems are still not very usable - with the exception of OS X.
TextEdit: ~81 ms from key depression to when LCD pixels begin to shift. For Sublime Text: ~86 ms. Both of these text editors are pretty well matched.
However, if you boot into Recovery Mode in macOS, you gain access to a GUI without a V-synced/tripled framebuffer. Terminal in Recovery Mode: ~57 ms
Finally, the kicker. macOS users have always had access to a terminal interface upon boot called single-user mode:
Single User Mode: 37.5ms (all three measurements were the same)
If you want to experience what the latency on old computers felt like while typing, simply reboot your mac, and while it's starting up, hold 'Command + S'!
1. between the keyboard and CPU 2. in the input subsystem 3. in the app / system libraries 4. in the display subsystem 5. between the CPU and the screen
In 2014 I built a new computer with a i5-4590 CPU, ASUS Z97-A motherboard and 8GB of Kingston DDR3-1866 memory.
One thing I instantly noticed was that my mouse (Logitech G400) would feel "delayed" compared to my older computer from 2010 (i3-550, Intel DH55HC motherboard). I could have the same OS (tested Win7 and Ubuntu), GPU and monitor between both computers and switch, and the difference was that obvious.
Another problem I had was DPC latency under Windows with driver: "usbport.sys". USB audio would drop out in correlation with DPC latency spikes and I believe it was related to the mouse latency. Under Ubuntu I had the same problem and logged a dmesg message that said "retire_capture_urb: x callbacks suppressed", with the same symptoms.
I got so frustrated I stopped using the new desktop and went back to my old desktop and a new laptop for about 2 years, after wasting my time running Prime95, MemTest86 for over 24 hours, and swapping the motherboard with another model that let me disable HPET (Supermicro C7Z87-O)
In the end, last year I decided to work on it again and swap the memory with some Corsair 2X4GB DDR3-1333 memory and just like that, the DPC lag spikes were gone, USB audio didn't drop out and my mouse stopped lagging.
I didn't believe it at first, but just being able to move the mouse around and play audio over USB and not having it lag was enough proof.
It's an iOS video app for measuring latency. The page has this about Apple keyboards: "This one’s bizarre: the onboard keyboards on both the 2015 Macbook Pro and Macbook Air have worse latency than an external keyboard. Plugging in an external wireless keyboard improves response latency by 40 ms."
1. Wait for USB to poll.
2. Handle interrupt urb generated by keyboard.
3. Propagate the urb to the correct driver for completion
4. Create input events for each key event in this urb. Don't forget to use this to add to your randomness pool!
5. Pass the key event to user space, and wake up readers.
6. Some library reads the input event, and calls some sort of handler.
7. Application logic updates the internal state as a result of a key press.
8. Tells some library to redraw.
9. Library redraws, and writes to the X server using x protocol.
10. Magic occurs. I assume this magic is mostly just compositing windows and copying to a frame buffer, but who knows?
11. The magic pixies run across the wire from your PC to your monitor, and at some future date, your monitor displays it.
Honestly, I am impressed that all of this gets done in less than 100ms.
See https://superuser.com/questions/16893/do-usb-or-ps-2-keyboar...
Notice that just getting a thread scheduled every 2 ms is already impossible for Windows, certainly one running a game. You'll get a bunch of outliers within the second. So even if you got your keyboard down to 5 ms, great, but you are not running an operating system that can reliably do something within that timespan!
Maybe I'm not understanding, but that doesn't seem correct.
Most people (gamers) are running mice at 500/1000Hz polling rates and you can easily verify the movement made in each 1-2ms update. (And it is most definitely a noticeable difference going from a standard 125Hz rate to even 500Hz.)
The mouse measuring data every 1-2ms will increase the quality of the motion tracking, but it won't necessarily help you with latency unless the data gets to the game fast and the game handles the data quickly.
This explanation by John Carmack comes to mind... it's a good reminder against a lot of the hardware fetishism that is mixed into otherwise good advice about gaming setups. https://superuser.com/questions/419070/transatlantic-ping-fa...
You pressing the key triggers a wave of electricity cross the keyboard which is converted into the PS2 waveform, and pumped out at the same rate of the incoming clock waveform.
OLD PS2 keyboards don't generally have internal digital micro-controllers, they're effectively analog, the logic they do contain is blindly simple. This is why some struggle with N-Key Rollover.
---
OFC this is if you are using an -old- PS2 keyboard. I'm still using an 80's IBM Model M and above it roughly how it works.
- I cannot find about "diode cascades" having anything to do keyboards. The closest is the usual diode matrix to deal with simultaneous key presses.
- The PS/2 interface involves sending scan codes, parity bits, and start and stop bits. How exactly does a "wave of electricity" get converted into a PS/2 waveform without some digital electronics?
- All the old schematics for mechanical keyboards I could find were the usual matrix scan. Even a textbook from the 1970s.
Anyway, reference please. I'd find it very interesting to see how such a thing would work.
Here is a set of pictures of an IBM Model M, for instance. The microcontroller is clearly visible in the ceramic DIP40 package.
http://www.clickeykeyboards.com/model-m-gallery/1985-ibm-mod...
And I'm not an expert in this either, but I'm pretty sure double buffering is the norm, whether you use V-Sync or not.
One buffer in which your graphics card works on frames (I'll call this "graphics card buffer") and then a buffer into which finished frames are moved, so that your screen can read them out in peace (I'll call this "pre-screen buffer").
There's also "triple buffering", which introduces another one of those graphics card buffers, so that when a finished frame is being transferred from that first graphics card buffer to the pre-screen buffer, then your graphics card doesn't have to wait for that transfer to finish and can instead start working in the second graphics card buffer right away. (And then it transfers frames from those graphics card buffers in alternating fashion.)
So, the delay that V-Sync introduces is not that. What V-Sync does, is that instead of transferring finished frames from the graphics card buffer(s) into the pre-screen buffer as soon as the frame is finished, it waits with the transfer until your screen has finished with reading out the previous frame.
If you don't wait (have V-Sync disabled), your screen will read out some part of the previous frame and then read out the rest from the new frame. On the screen, you'll see this break between previous and new frame as screen tearing.
So, assuming your screen can display 120 frames per second and your graphics card happens to finish 120 frames in a second, then V-Sync will not introduce a delay. It'll wait once with transferring the first frame, but then they'll be in sync and no further delay should occur.
However, if your graphics card is able to calculate 240 frames per second (and your screen still does 120 frames per second), then with V-Sync, the graphics card buffer will be transferred into the pre-screen buffer only 120 times per second, making the graphics card slow down to 120 frames per second as well.
Without V-Sync, the graphics card buffer will be transferred 240 times per second, regardless of how often your screen can read it out from the pre-screen buffer. This means a frame will get loaded into the pre-screen buffer as your screen is reading it out. As a result, you'll get screen tearing and one half of your screen will be from the new frame, with a 1/240 s = 4.167 ms delay, the other half is still from the previous frame with a 2/240 s = 1/120 s = 8.33 ms delay.
So, a few numbers:
120 FPS with 120 Hz screen = 8.33 ms delay.
240 FPS with 240 Hz screen = 4.167 ms delay.
240 FPS with 120 Hz screen = ½8.33 ms + ½4.167 ms = 6.25 ms delay on average.
480 FPS with 120 Hz screen = ¼(1/480) + ¼(1/360) + ¼(1/240) + ¼(1/120) = 4.34 ms delay on average.
960 FPS with 120 Hz screen = 2.83 ms delay on average.
960 FPS with 240 Hz screen = 2.17 ms delay on average.
Edit: then there is third approach: simple keyboard/input devices with serial interfaces, where host provided clock is used to both clock the interface and keyboard scan logic. In essence the whole keyboard then looks like one big shift register. Keyboards that works this way includes original Macintosh, most Wyse and DEC terminals and MIT/LMI/Symbolics Lisp machines (and probably pre-sun4 Suns, sun4 and later have rs232-derived ionterface), also this is the way how controllers for Nintendo consoles before Wii work (IIRC Nintendo calls that "EXI bus") and how PlayStation 1/2 controllers work. IMHO this is to some extent where the idea behind SPI comes from.
I think the only PS/2 holdouts you'll find are the old Korean Starcraft players that are still using a Qsenn DT-35.
It's entirely a preference based thing, the most relevant factor would be whether or not you need to hot swap it.
Something like click-to-beep.
An interesting way to test this would be to use a sensor to note how the point where a key was definitely "headed down" (say > 10% of its total travel) and then waiting for the message to show up.
In older keyboards the main CPU was doing some of the debouncing so it knew "right away" that a keyboard was pressed. That cuts down on latency as well.
Another test case might be to put a USB -> PS/2 adapter on the keyboard. This lets the onboard CPU know to send the keycode as soon as it has decoded and debounced it.
I clock about 15 keystrokes per second while typing full speed, and I find serious issues with accuracy using most contemporary keyboards, even on gaming and higher-end OEM equipment.
Edit: Some keyboards are also practically unusable due to dropped inputs above a certain rate.
When I bought my first chromebook, I opened google docs and found the typing latency terrible. It couldn't keep up with me.
Then I let the chrome OS update, and everything was as smooth as butter.
It is a result of the matrix wiring of the keys, though more expensive keyboards will have them wired individually, mitigating this issue.
So it's not like nobody experiences this problem.
That said.. how are you holding C to crouch? I assume for WASD movement. I just tried that and it's contorting my hand in weird and uncomfortable ways.
I shifted my hand to the right so that my middle finger is on D, my ring finger moved forward and back (WS), and pinky for A.
That evolved from gaming on a laptop where I'd just rock my index finger back to hit C or shift my thumb forward and rock back on the space bar to jump. I got disturbingly good at Q3Arena on a Powerbook G3, yes, using the track pad. It inspired some bad ergonomic habits. haha
Now I just use Ctrl.
If you _could_ (not saying it's easy or even necessarily practical at all) drop replace all of the slow stuff like high-latency keyboards, syscalls, CPU-GPU communication (i.e. effective HSA) and build some proof-of-concept operating environment (that was explicitly incompatible with existing stuff).. I think you could get a pretty fast computer. It would be fun to try.
Anyway is there a Cherry MX keyboard that has low travel and low latency overall?
If you are really tied to the cherry mx style you could check out the kailh and cherry "speed" switches, which have slightly shorter travel distance and a higher actuation point.
[1] https://www.amazon.com/Mechanical-Keyboard-Extra-Thin-Switch...
1. How well did the historical systems do, and why? Presumably non-negligible key travel is not a modern invention.
2. How much of the latency is key travel? (i.e. what korethr said)
3. How exactly were the keys pressed/how fast were they pressed? All the article says about the experimental setup is "The start-of-input was measured by pressing two keys at once – one key on the keyboard and a button that was also connected to the logic analyzer."
P.s.: I currently use external Apple keyboards to perform & make music (with things like http://qwerkey.xyz).
> It’s possible to get down to the 50ms range in well optimized games with a fancy gaming setup, and there’s one particularly impressive consumer device that can easily get below that.
Is the device in question mentioned anywhere?
I think we should have rule on OSX and iOS where this sub 10ms latency is standard.
Before seeing this article I've thought that iTerm seemed slow before to show text, it'd be nice to see a writeup on how long it took for text to render after keyboard input on a few different programs to get developers to use the same methods to keep this as quick as possible.
But Apple 2 keys are not short travel keys
body {
max-width: 40em;
line-height: 1.5;
font-size: 18px;
margin: 0 auto;
font-family: sans-serif;
}
Those cracker-thin chicklets that comprise the Apple Magic keyboard will only make you faster if you rest your fingertips on the caps.
That may not work so well in all games; it depends on the controls. If you rest a finger on a certain key, but a situation requires you to use that finger to react with a different (though near by) key, you're at a disadvantage compared to having the finger raised so that it can strike either key with equal speed.
HHKB JP with Hasu's controller
For more depth than anyone really needs, see the r/mechanicalkeyboards wiki
https://www.reddit.com/r/MechanicalKeyboards/wiki/switch_gui...
As for keyboards, there's no real excuse not to just have a Bigass™ shift register (or a couple) and address every keyswitch with a trace and an interrupt crossbar. There's a limit to how cheap a good-enough keyboard can ultimately be, so a difference of a few cents in BOM and assembly, and slightly more intricate membrane layouts is not worth crying over.
The methodology here is broken for non-linear long-travel keyswitches, for which the "point at which the key starts moving" is the wrong point to measure. For example, I'm typing this on buckling-spring keyswitches. The break for these switches is part way down the stroke, this is intentional and does not contribute to "latency", since the intent of depressing the key above the break is not to send the keypress at that moment, but to be ready to cross the break once the previous key has been pressed. This is very similar to how good handgun triggers typically function: a light, firm, and smooth uptake before a break, and hopefully with a reset very near the break. It communicates to the user how close they are to actuating the switch.
In the case of linear long-travel switches (i.e. Cherry MX Red style switches), it's harder to decide where to consider the key "pressed", but in the case of non-linear long-travel switches (buckling spring, Cherry MX Blue) it's clear that the break is when the keypress should be registered, not the beginning of the uptake. In the case of non-linear switches, they don't need to bottom out to register keypresses, so they can have exceptionally low latency. With sufficient spring stiffness, and a long enough heel, buckling spring keyswitches should take less time to actuate than scissor-dome switches.
Added:
Regarding the testing methodology, it seems like you could do better with a combination of a motor, an armature, and a small strain gauge (or a measurement of motor load). The motor will apply consistent force at consistent peak acceleration between tests if you input consistent voltage. For non-linear switches, you can measure the break time as a junction in the applied force across the strain gauge or in the motor load on one of the analog inputs on your logic analyzer; for linear switches, you can measure the start of actuation the same way. Motor load would work just fine, since you're not interested in the exact force exerted, and thus don't need to calibrate for the efficiency of the motor.
s/modern/recent/
"For example, an iMac G4 running macOS 9 or an Apple 2 both feel quicker than my 4.2 GHz Kaby Lake system."
Kaby Lake system running OSX? I have one of the last G4 that came with OS9. Based on intuition it would make audio applications "feel" slower, when OSX came out I did not "upgrade", despite the marketing at the time. I guess I am not the only one.
"It turns out the machines that feel quick are actually quick, much quicker than my modern computer - computers from the 70s and 80s commonly have keypress-to-screen-update latencies in the 30ms to 50ms range out of the box, whereas modern computers are usually in the 100ms to 200ms range."
"... where we are today, where can buy a system with the CPU that gives you the fastest single-threaded performance money can buy and get 6x the latency of a machine from the 70s."
Methinks when someone spends that kind of money on a system, they will never accept findings like these. They are not likely to respond "inquisitively" to someone who describes achieving better speeds with a "less powerful" system that costs a fraction of what they paid. More likely, they will try to discredit them.
Back in the day there were very little between the keyboard and the screen, and most of it were either in rom or in ram.
Never mind that unless one were dealing with a big iron or similar, multi-tasking was a big nope.
These days most OSs have 10s to 100s of processes going right after a first boot on a clean install. And all those can trip something at "random" intervals.
Basically, desktop Windows has crossed the threshold of "needs SSD" to perform adequately. And in theory that shouldn't impact the performance of an older game, but it does, because what happens next is that the scheduler misallocates process time and throws off everything.
Thus desktop developers keep adding questionable "quality of life" stuff like file system indexers to justify their continued version releases (never mind avoiding doing actual code maintenance).
Strike that. Obviously computers were far more expensive in decades past and the prices have come down dramatically. What I meant is a first user with an older computer who is achieving better performance, e.g. lower latency, than a second user having the costs of acquiring the latest hardware and software (who discarded her older computers).