My gut is that there's a lot more to this, and that it's not broadly true.
I live in the UK and have worked from Australia a few times, and the latency is around 220ms. When typing over SSH, the latency is very noticeable. Not in terms of pressing a key and feeling lag in it showing up, but in a feeling of sluggishness when typing more than a few words at a time. I also notice this feeling in web apps that use React managed inputs for example.
My guess is that while 100-200ms isn't noticeable in one instance, adding that to every interaction in a system that has multiple interactions per second is noticeable.
A similar comparison is that I can't detect audio and visuals being incorrectly synced with much less than 200ms precision for individual beeps, however if I watch someone talking on a TV that's 30ms out I can tell something is wrong (even if I can't tell which direction).
If you read a little closer this is in his "counter-arguments" section stated as a claim made by other people - a claim he doesn't buy. If you look at some of his other articles about latency he points to user studies and research that shows the 100-200ms claim is not true.
So he's making the opposite argument you think he's making - he agrees with you.
The rule of thumb floating around when I was working on physical input devices last was to keep latency under 50ms so people wouldn't get frustrated. I don't have any sources but it becomes a bit more obvious when you look at it as fractions of seconds and then compare that to how slowly seconds actually tick by on a clock.
I remember Dan posting that he typed at ~120wpm somewhere. 120wpm is 0.002 words per ms or 0.4 words per 200ms. Wouldn't one notice if they're almost halfway through a word and nothing has shown up on the screen?
I work on VR systems, where latency is of paramount concern.
There is definitely a big difference between consciously noticeable latency and latency that has an effect on people.
Yes, to get to the point where a person can notice that latency is occurring and can call it out, you need to be in the 100ms range.
But if you want to make a VR system that doesn't make most people physically ill, you have to get "motion-to-photon" latency down to around 13ms (75hz). Even at that range, you still get a relatively large portion of people experiencing issues; I'd estimate 20%. At 90hz, you can get that down to about 10%. At 120hz (less than 9ms!), I haven't seen specific numbers, but my gut feeling from my own work with users is that it's lower enough to care about the extra work to hit that target. I suspect that we can't be fast enough on this issue, that 240hz, maybe even 1000hz, will be necessary to get down to 1%.
Luckily, most VR systems today have asynchronous reprojection systems to decouple view movements from application updates (to a degree). It is an extrapolation system, so there are some artifacts, especially around the edges of objects, especially if there is a huge difference between application update rate and view update rate. But I've seen applications running updates at 30fps, which should be headache inducing for sure for the vast majority of people, but they're running on headsets with a 120hz refresh rate and all you really notice are that animated objects look a little choppy.
Oof. I play piano (as a hobby, but seriously). When practicing on an electric piano, anything more than 20ms of latency is VERY noticeable for me, possibly even 10ms. There's a reason people still use wired headphones for practicing on electric pianos. Bluetooth just does not work. The latency interrupts the emotional state of flow and it's extremely jarring.
Typing on a computer is a different story. The latency perception via the eyes is very different than through the ears.
One place where latency has been felt very obviously for me is the MMO World of Warcraft. I’ve played it for many years from several different geographical locations, with reported latency between my computer and their servers ranging from as low as 20ms to as high as 240.
I can pretty reliably tell if I’m playing on a PST or EST (North America) server, with the latter having 50-60ms latency compared to a PST server with 20-30ms due to differences in distance. It’s not massive, but on EST servers everything is ever so slightly less responsive, and it’s particularly visible in combat where many abilities are being used rapidly and outcome is dependent on order of operations.
The differences starts becoming obvious when crossing the 80-90ms latency and unmistakable at 120ms+.
I would agree that it would be difficult to tell the difference in a one-off test but when it’s something you’re actively doing for long stretches of time it’s easy to pick up on.
I also notice this feeling in web apps that use React managed inputs for example.
I can tell when there's an extra render in a React app, on an input or just when something renders slightly later than expected like an update is being done in a useEffect after the first render, and I agree that it's really annoying. However, the input latency of a React app should be less than 16ms. There's nothing intrinsic to React (or any JS framework) that means there has to be any appreciable lag. Obviously there are badly written ones that do things very poorly, but if you find one like that you should vote with your feet and move to a competitor.
The author is rebutting this. "This line of argument is like saying that you wouldn’t notice a flight being delayed by an hour because the duration of the flight is six hours."
I was messing around with CSS animations the other day and even at 100ms you can definitely see the animation happening. One of these days I'll get around to making a site to A/B test how fast they are noticeable.
Maybe there are circumstances where 100ms+ latency is not noticeable, but I suspect they are few and far between if you're actually paying attention.
> "It’s not a coincidence that the quickest keyboard measured also has the shortest key travel distance by a large margin."
High-end keyboards often have user changeable key switches and there are a hundreds of different switches available, each tuned for a different mix of specified parameters including actuation depth, pressure (force) and many more. Switches made for competitive gamers are generally linear (no click), with light force and very shallow actuation depth. For example, some users love the feel and sound of clicky Cherry Blue switches but they're obviously a poor choice from a latency perspective. On my personal keyboards, I even have different switches installed on certain individual keys (Enter, Spacebar, etc) which have different actuation depth and force. Keyboard geeks and pro gamers can be very picky and precise about their preferred switches and the first step in getting serious about keyboards is swappable switches and key caps.
I appreciate the rigorous approach to testing the entire latency pathway but I think the key switch aspect of the chain is already very well specified, characterized and studied and is in the control of users who would value objective latency tests. Personally, I'd be far more interested in tests that measure the latency of the rest of the path after electrical switch actuation. Otherwise, a keyboard manufacturer may have the shortest post-actuation latency but it's invisible to these tests due to being masked by the subjective choice of a non-linear, full travel switch the manufacturer may have chosen due to a "feel" preference.
The Corsair K65 achieved the fastest latency of 0.1ms. By comparison the Apple Magic Keyboard with TouchID had a latency of about 27ms, both wired and bluetooth. Pretty wild that the Apple keyboard is 270x slower!
Now I personally use the Logitech G915 TKL, low-profile. The 1.3ms latency is excellent and I love the key feel.
I understand that key travel time is included in the latency measurements to facilitate the camera-based measurement, but wouldn't it make more sense to measure latency purely in terms of electrical signals? For example, measuring the time between the first connection of the circuit in the keyswitch to the time at which the USB packet including the keypress is sent across the wire? This seems like it would be equally possible to test with a second logic analyzer, without relying on a high FPS camera. Many people who use "special" mechanical keyboards are well aware of the actuation points on their keyboards, and understand that there are tradeoffs between travel time, physical feedback, and so on.
Put another way, unless you think gently resting your fingerprints on the top of a key should count as a "press", then it doesn't make sense to include the key travel time in latency.
Yeah I think so. Relevant quote from the article below. How are the keys being pressed, manually? We could have skipped all this by just knowing key travel time will govern based on his experiment. If you really want to know the fastest keyboards look at what the winners of typing competitions use.
>A major source of latency is key travel time. It’s not a coincidence that the quickest keyboard measured also has the shortest key travel distance by a large margin. The video setup I’m using to measure end-to-end latency is a 240 fps camera, which means that frames are 4ms apart. When videoing “normal" keypresses and typing, it takes 4-8 frames for a key to become fully depressed. Most switches will start firing before the key is fully depressed, but the key travel time is still significant and can easily add 10ms of delay (or more, depending on the switch mechanism). Contrast this to the Apple "magic" 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.
Yeah, this is a pretty big issue that disproportionately effects mechanical keyboards, failing to account for the fact that the "ready" position in the context of gaming on a mechanical keyboard likely involves having the key being slightly depressed, just above the actuation point (think resting your fingers on WASD).
The author is concerned about perception of latency. You perceive the time from when you make the decision to press a button to when you see the result. From this perspective mechanical vs electrical is irrelevant.
I notice very significant latency with my Moonlander Mk1, but that is most likely caused by the software and fancy layered kemaps I have created.
When I use the Moonlander, mainly for development, I end up typing a lot slower but producing the same output. I also have a lot fewer keyboard shortcut contortions, so my hands are happier.
Still it feels like we are trying to maximize the wrong thing, especially when writing software. It still feels very low level and mechanical, when the concepts and patterns are pretty well established. We just don't have a great interface for calling those up and making minor adjustments to suit our specific need.
I haven't used copilot, but from seeing devs on Youtube who have it enabled, I'm not sure it is the answer. The visual distraction from seeing possible but often slightly wrong solutions appear and then change seems like trading one chore for another.
> I haven't used copilot, but from seeing devs on Youtube who have it enabled, I'm not sure it is the answer. The visual distraction from seeing possible but often slightly wrong solutions appear and then change seems like trading one chore for another.
This feels reminiscent of my experience with most search systems, whether its the start menu in windows or google search:
-Type the first two or three letters of what I want
What I want appears first in the list
-"Oh good", I think as my brain processes that but I still type the next letter as I was already in the process of doing so
-Search results change thanks to that letter at the same moment I hit enter
> I notice very significant latency with my Moonlander Mk1, but that is most likely caused by the software and fancy layered kemaps I have created.
I'm not noticing all that much latency with my Ergodox EZ, but I'm also running QMK master[1] (rather than ZSA's fork via Oryx). It would be useful to note the firmware + revision in these tests.
40ms sounds like a lot of latency for twitchy games like StarCraft II (for which I've extensively customized my layout[2]); while I'm definitely enjoying the improved ergonomics in the game, I'm starting to wonder how much it's actually impacting my performance.
This post inspired me a few years ago to start a very impractical learning side project. Most keyboards don't overly prioritize latency. Development of a keyboard is easy using a USB stack from the manufacturer, but it might not prioritize latency.
I'm working on making my own FPGA based USB 2.0 HID device that will let me minimize any latency in the stack. PCB layout is mostly done, I'm working on a DECA FPGA board to prove out the USB hid software now. I started this pre covid though when Mach XO2s were inexpensive and available, so I have no idea who I will need to fight these days to get parts when I get to that point.
There is lots of wiggle room too in how you implement your debounce algorithm to optimize latency too. I'm excited to control the whole stack to try to make this as fast as possible. The Logitech lightspeed products came out after I started this project though and are far more practical for most people. I have one of those at home and will try to benchmark and compare them when I get there.
I have written USB device firmware for AVR, and read docs for a bunch of microcontroller families' with different internal HID device units that I wanted to port to.
If you do take suggestions for your next version, there are some hardware features that I would like:
* Let the MCU replace the next unsent input report, and atomically. Many USB devices can only queue reports, not replace them.
* Allow the microcontroller to know when a input report has been received. (ACK)
The first would make it possible to get the lowest latency with reports such as keyboard reports that contains only the state of momentary switches.
The second would make it possible to ensure that an event has been received, even if the host would poll at a slower rate than what the firmware works at.
The situation is especially complex for mice, where the reports have inputs that are relative — to the previous report.
If the test is between the keyboard and screen "For desktop results, results are measured from when the key started moving until the screen finished updating", then the classic "Transatlantic ping faster than sending a pixel to the screen?" should also be considered:
It is not uncommon to see desktop LCD monitors take 10+ 240 Hz frames to show a change on the screen. The Sony HMZ averaged around 18 frames, or 70+ total milliseconds.
This whole thing seems so technical and hardware focused. Scan rates, debounce algorithms, USB packets, etc. and then it comes out halfway through the blog post that he's actually largely measuring how long it takes his finger to depress the key!
He says that 16-32 ms of the latency ("4-8 frames") is attributed to his finger speed. In other words, he starts measuring from physical contact with the key rather than switch contact.
You'll see that the histogram of the keyboards they've tested suggests a bi-model latency distribution. About half tested show essentially no latency (0-3ms) and the other half show 10-15ms latency. There are outliers too, of course, but note that the finger speed measurements dominate these numbers.
It seems this post is really about key travel, but in disguise.
Unless I'm misunderstanding something, I see a possible issue with the experiment setup.
> 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.
In order to get an accurate measurement, wouldn't you need to directly connect the analyzer to circuitry on the underside of a specific key, as well as the USB output, and measure the diff? The article addresses this by mentioning it's only possible to get average latencies with their setup, but I wonder if this is why the keyboard with the shortest measured latency is also one with an extremely low travel distance.
If the major source of latency is key travel distance, does this really impact the user experience? My feeling is that a keyboard with longer travel distance feels more "solid" than one where the key hardly goes down at all, even if this adds some extra latency. Otherwise we could just type on virtual keyboards with zero travel distance, but then there is no tactile feedback when the key is pressed.
This post is why I believe the Apple Magic Keyboard is actually the best gaming keyboard currently available. I noticed it when I tried gaming on traditional mechanical keyboard, and then on an AMK. The Apple keyboard feels distinctly snappier, lets me react faster and take actions in quicker succession.
Now when I watch a real-time strategy gaming streamer or something, and hear them clacking furiously at their fancy mechanical keyboard, I wince. They're losing 10-20ms to key travel on every action they take!
Another great deep dive into latency of typing is this one [1] which considers input latency from the keyboard, the keyboard interface, the editor/IDE, and even the window manager.
Pavel found that Windoes Aero added 16.6ms extra latency (but this has probably been fixed by now).
It’s not quite ‘latency’ but one keyboard attribute I’ve come to notice is the key “spring-back” time. I’m not sure what that’s called. I recently switched from an older Apple wireless keyboard to a Logitech MX Keys keyboard. The feel is nice but the depressed keys feel like they “bounce back” too slowly for me leading to frequent typos.
It would be interesting to see concrete tests. Gamers have long preferred wired keyboards and mice supposedly for latency reasons, with the only wireless models they’ll accept being proprietary 2.4Ghz RF protocols designed specifically for lowering latency (e.g. Logitech’s Lightspeed lineup).
I have a Lightspeed mouse as part of my gaming setup and it does feel very responsive, easily good enough for my needs, but I’m not a chart topping FPS player who’d be pushing these devices to their limits.
[+] [-] danpalmer|3 years ago|reply
My gut is that there's a lot more to this, and that it's not broadly true.
I live in the UK and have worked from Australia a few times, and the latency is around 220ms. When typing over SSH, the latency is very noticeable. Not in terms of pressing a key and feeling lag in it showing up, but in a feeling of sluggishness when typing more than a few words at a time. I also notice this feeling in web apps that use React managed inputs for example.
My guess is that while 100-200ms isn't noticeable in one instance, adding that to every interaction in a system that has multiple interactions per second is noticeable.
A similar comparison is that I can't detect audio and visuals being incorrectly synced with much less than 200ms precision for individual beeps, however if I watch someone talking on a TV that's 30ms out I can tell something is wrong (even if I can't tell which direction).
[+] [-] xenadu02|3 years ago|reply
So he's making the opposite argument you think he's making - he agrees with you.
[+] [-] davemp|3 years ago|reply
I remember Dan posting that he typed at ~120wpm somewhere. 120wpm is 0.002 words per ms or 0.4 words per 200ms. Wouldn't one notice if they're almost halfway through a word and nothing has shown up on the screen?
[+] [-] moron4hire|3 years ago|reply
There is definitely a big difference between consciously noticeable latency and latency that has an effect on people.
Yes, to get to the point where a person can notice that latency is occurring and can call it out, you need to be in the 100ms range.
But if you want to make a VR system that doesn't make most people physically ill, you have to get "motion-to-photon" latency down to around 13ms (75hz). Even at that range, you still get a relatively large portion of people experiencing issues; I'd estimate 20%. At 90hz, you can get that down to about 10%. At 120hz (less than 9ms!), I haven't seen specific numbers, but my gut feeling from my own work with users is that it's lower enough to care about the extra work to hit that target. I suspect that we can't be fast enough on this issue, that 240hz, maybe even 1000hz, will be necessary to get down to 1%.
Luckily, most VR systems today have asynchronous reprojection systems to decouple view movements from application updates (to a degree). It is an extrapolation system, so there are some artifacts, especially around the edges of objects, especially if there is a huge difference between application update rate and view update rate. But I've seen applications running updates at 30fps, which should be headache inducing for sure for the vast majority of people, but they're running on headsets with a 120hz refresh rate and all you really notice are that animated objects look a little choppy.
[+] [-] dheera|3 years ago|reply
Typing on a computer is a different story. The latency perception via the eyes is very different than through the ears.
[+] [-] kitsunesoba|3 years ago|reply
I can pretty reliably tell if I’m playing on a PST or EST (North America) server, with the latter having 50-60ms latency compared to a PST server with 20-30ms due to differences in distance. It’s not massive, but on EST servers everything is ever so slightly less responsive, and it’s particularly visible in combat where many abilities are being used rapidly and outcome is dependent on order of operations.
The differences starts becoming obvious when crossing the 80-90ms latency and unmistakable at 120ms+.
I would agree that it would be difficult to tell the difference in a one-off test but when it’s something you’re actively doing for long stretches of time it’s easy to pick up on.
[+] [-] onion2k|3 years ago|reply
I can tell when there's an extra render in a React app, on an input or just when something renders slightly later than expected like an update is being done in a useEffect after the first render, and I agree that it's really annoying. However, the input latency of a React app should be less than 16ms. There's nothing intrinsic to React (or any JS framework) that means there has to be any appreciable lag. Obviously there are badly written ones that do things very poorly, but if you find one like that you should vote with your feet and move to a competitor.
[+] [-] LAC-Tech|3 years ago|reply
Average ping is 63 ms. Even that latency is noticeable - more typing errors for sure. I never connect without mosh.
[+] [-] tiffanyh|3 years ago|reply
Case in point...
My previous iPhone had 60Hz refresh rate, that equates to ~16ms.
My new iPhone has 120Hz refresh rate, that equates to just ~8ms.
I can absolutely tell the difference in the display between these two devices when I scroll.
[+] [-] advisedwang|3 years ago|reply
[+] [-] gibspaulding|3 years ago|reply
Maybe there are circumstances where 100ms+ latency is not noticeable, but I suspect they are few and far between if you're actually paying attention.
[+] [-] ilyt|3 years ago|reply
>My gut is that there's a lot more to this, and that it's not broadly true.
Which is why that quote is from list of "counter-arguments people say" and debunked by author...
> I live in the UK and have worked from Australia a few times, and the latency is around 220ms. When typing over SSH, the latency is very noticeable.
You don't have 220ms latency. You have latency of your whole system plus that extra 220ms
[+] [-] wyuenho|3 years ago|reply
https://www.researchgate.net/publication/259490307_Detecting...
[+] [-] rejectfinite|3 years ago|reply
Yea, author never played MMOS or FPS games online?
Going from 20ms to 100 is going to be VERY noticable.
[+] [-] hayd|3 years ago|reply
[+] [-] mrandish|3 years ago|reply
High-end keyboards often have user changeable key switches and there are a hundreds of different switches available, each tuned for a different mix of specified parameters including actuation depth, pressure (force) and many more. Switches made for competitive gamers are generally linear (no click), with light force and very shallow actuation depth. For example, some users love the feel and sound of clicky Cherry Blue switches but they're obviously a poor choice from a latency perspective. On my personal keyboards, I even have different switches installed on certain individual keys (Enter, Spacebar, etc) which have different actuation depth and force. Keyboard geeks and pro gamers can be very picky and precise about their preferred switches and the first step in getting serious about keyboards is swappable switches and key caps.
I appreciate the rigorous approach to testing the entire latency pathway but I think the key switch aspect of the chain is already very well specified, characterized and studied and is in the control of users who would value objective latency tests. Personally, I'd be far more interested in tests that measure the latency of the rest of the path after electrical switch actuation. Otherwise, a keyboard manufacturer may have the shortest post-actuation latency but it's invisible to these tests due to being masked by the subjective choice of a non-linear, full travel switch the manufacturer may have chosen due to a "feel" preference.
https://dygma.com/blogs/stories/the-ultimate-guide-to-mechan...
[+] [-] taroth|3 years ago|reply
The Corsair K65 achieved the fastest latency of 0.1ms. By comparison the Apple Magic Keyboard with TouchID had a latency of about 27ms, both wired and bluetooth. Pretty wild that the Apple keyboard is 270x slower!
Now I personally use the Logitech G915 TKL, low-profile. The 1.3ms latency is excellent and I love the key feel.
[+] [-] 323|3 years ago|reply
Anyone can explain how is that possible, given that plenty of experiments showed that the human (conscious) reaction time is above 150 ms?
[+] [-] yalue|3 years ago|reply
Put another way, unless you think gently resting your fingerprints on the top of a key should count as a "press", then it doesn't make sense to include the key travel time in latency.
[+] [-] twobitshifter|3 years ago|reply
>A major source of latency is key travel time. It’s not a coincidence that the quickest keyboard measured also has the shortest key travel distance by a large margin. The video setup I’m using to measure end-to-end latency is a 240 fps camera, which means that frames are 4ms apart. When videoing “normal" keypresses and typing, it takes 4-8 frames for a key to become fully depressed. Most switches will start firing before the key is fully depressed, but the key travel time is still significant and can easily add 10ms of delay (or more, depending on the switch mechanism). Contrast this to the Apple "magic" 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.
[+] [-] OkayPhysicist|3 years ago|reply
[+] [-] advisedwang|3 years ago|reply
[+] [-] michaelteter|3 years ago|reply
When I use the Moonlander, mainly for development, I end up typing a lot slower but producing the same output. I also have a lot fewer keyboard shortcut contortions, so my hands are happier.
Still it feels like we are trying to maximize the wrong thing, especially when writing software. It still feels very low level and mechanical, when the concepts and patterns are pretty well established. We just don't have a great interface for calling those up and making minor adjustments to suit our specific need.
I haven't used copilot, but from seeing devs on Youtube who have it enabled, I'm not sure it is the answer. The visual distraction from seeing possible but often slightly wrong solutions appear and then change seems like trading one chore for another.
[+] [-] Arrath|3 years ago|reply
This feels reminiscent of my experience with most search systems, whether its the start menu in windows or google search:
-Type the first two or three letters of what I want What I want appears first in the list
-"Oh good", I think as my brain processes that but I still type the next letter as I was already in the process of doing so
-Search results change thanks to that letter at the same moment I hit enter
-Annoyance
-Fin
[+] [-] rollcat|3 years ago|reply
I'm not noticing all that much latency with my Ergodox EZ, but I'm also running QMK master[1] (rather than ZSA's fork via Oryx). It would be useful to note the firmware + revision in these tests.
40ms sounds like a lot of latency for twitchy games like StarCraft II (for which I've extensively customized my layout[2]); while I'm definitely enjoying the improved ergonomics in the game, I'm starting to wonder how much it's actually impacting my performance.
[1]: forked to https://github.com/rollcat/qmk_firmware [2]: https://gist.github.com/rollcat/8b8dcd36c0abccf430b4160ad899...
[+] [-] markfeathers|3 years ago|reply
I'm working on making my own FPGA based USB 2.0 HID device that will let me minimize any latency in the stack. PCB layout is mostly done, I'm working on a DECA FPGA board to prove out the USB hid software now. I started this pre covid though when Mach XO2s were inexpensive and available, so I have no idea who I will need to fight these days to get parts when I get to that point.
There is lots of wiggle room too in how you implement your debounce algorithm to optimize latency too. I'm excited to control the whole stack to try to make this as fast as possible. The Logitech lightspeed products came out after I started this project though and are far more practical for most people. I have one of those at home and will try to benchmark and compare them when I get there.
[+] [-] Findecanor|3 years ago|reply
* Let the MCU replace the next unsent input report, and atomically. Many USB devices can only queue reports, not replace them.
* Allow the microcontroller to know when a input report has been received. (ACK)
The first would make it possible to get the lowest latency with reports such as keyboard reports that contains only the state of momentary switches. The second would make it possible to ensure that an event has been received, even if the host would poll at a slower rate than what the firmware works at.
The situation is especially complex for mice, where the reports have inputs that are relative — to the previous report.
[+] [-] NovemberWhiskey|3 years ago|reply
That doesn't make any sense to me. Debouncing is about preventing inappropriate deactivation, and is unrelated to time to initial activation.
[+] [-] secure|3 years ago|reply
https://michael.stapelberg.ch/posts/2021-05-08-keyboard-inpu...
I got 13.6ms ±21%, Dan writes about 50ms.
Maybe we measured different models, the Kinesis Advantage has many revisions.
[+] [-] lajosbacs|3 years ago|reply
We need to be reminded of this as long as car and other companies sell stuff like this with a straight face https://youtu.be/bpclpbDmHsw?t=361 .
[+] [-] adolph|3 years ago|reply
It is not uncommon to see desktop LCD monitors take 10+ 240 Hz frames to show a change on the screen. The Sony HMZ averaged around 18 frames, or 70+ total milliseconds.
https://superuser.com/questions/419070/transatlantic-ping-fa...
[+] [-] ilyt|3 years ago|reply
[+] [-] Dave_Rosenthal|3 years ago|reply
He says that 16-32 ms of the latency ("4-8 frames") is attributed to his finger speed. In other words, he starts measuring from physical contact with the key rather than switch contact.
If you're interested in actual hardware latency measurements: https://www.rtings.com/keyboard/tests/latency
You'll see that the histogram of the keyboards they've tested suggests a bi-model latency distribution. About half tested show essentially no latency (0-3ms) and the other half show 10-15ms latency. There are outliers too, of course, but note that the finger speed measurements dominate these numbers.
It seems this post is really about key travel, but in disguise.
[+] [-] lapcat|3 years ago|reply
Posted 1 year ago, 114 comments: https://news.ycombinator.com/item?id=28399883
[+] [-] dang|3 years ago|reply
Keyboard Latency (2017) - https://news.ycombinator.com/item?id=28399883 - Sept 2021 (114 comments)
Keyboard latency - https://news.ycombinator.com/item?id=15485672 - Oct 2017 (265 comments)
[+] [-] cialowicz|3 years ago|reply
> 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.
In order to get an accurate measurement, wouldn't you need to directly connect the analyzer to circuitry on the underside of a specific key, as well as the USB output, and measure the diff? The article addresses this by mentioning it's only possible to get average latencies with their setup, but I wonder if this is why the keyboard with the shortest measured latency is also one with an extremely low travel distance.
[+] [-] fferen|3 years ago|reply
[+] [-] velox_neb|3 years ago|reply
Now when I watch a real-time strategy gaming streamer or something, and hear them clacking furiously at their fancy mechanical keyboard, I wince. They're losing 10-20ms to key travel on every action they take!
[+] [-] diroussel|3 years ago|reply
Pavel found that Windoes Aero added 16.6ms extra latency (but this has probably been fixed by now).
[1] https://pavelfatin.com/typing-with-pleasure/
[+] [-] markstos|3 years ago|reply
[+] [-] adolph|3 years ago|reply
This is a step up from the signal processing power of the HHKB's Renesas M38K07M4 [3] or an MS ergonomic keyboard's NRF24. [1,2]
0. https://www.ifixit.com/Teardown/Magic+Keyboard+Teardown/5099...
1. https://chrispaynter.medium.com/modding-the-microsoft-sculpt...
2. https://www.nordicsemi.com/Products/nRF24-series
3. https://raw.githubusercontent.com/tmk/tmk_keyboard/master/ke...
[+] [-] uptown|3 years ago|reply
[+] [-] 0xbadcafebee|3 years ago|reply
[+] [-] falcolas|3 years ago|reply
[+] [-] kitsunesoba|3 years ago|reply
I have a Lightspeed mouse as part of my gaming setup and it does feel very responsive, easily good enough for my needs, but I’m not a chart topping FPS player who’d be pushing these devices to their limits.
[+] [-] Sugimot0|3 years ago|reply
[+] [-] dottedmag|3 years ago|reply
[+] [-] tosh|3 years ago|reply