I'm surprised the "humans don't notice 100 ms" argument is even made. That's trivially debunkable with a simple blind A/B test at the command line using `sleep 0.1` with and without `sleep` aliased to `true`. To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms.
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.
> strike a key less than 100 ms after some visual stimuli, I'm sure I couldn't do it
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?).
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.
This rule comes from UX design user studies. However, the actual rule is that people perceive an event happening within 100ms as "instantaneous". Or, in other words, two events happening within 100ms of each other won't feel like distinct events. This doesn't mean that users won't notice the delay and it doesn't even mean users won't be frustrated by it, it's just a matter of human perception of distinct events in time.
Unfortunately, programmers/UX designers have a tendency to generalize this rule and use it to excuse slow user interfaces.
Another point is that, even if a bit of latency isn't noticeable (say, 20 ms), when added to other sources of latency it can make things noticeably worse.
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.
While you're factually correct about the musical stuff, note that the auditory system is not at all the same as the visual system, the latter being slower in processing information (i.e. full time for light entering retina to information being ready to do something with in the brain). Also resulting in reaction times for auditory stimuli being faster than for visual stimuli. So you can't just use one system to debunk a fairly general statement made about something visual related. Even though it's still false, but for other reasons.
"To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms."
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.)
> 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).
The other thing to consider is how is latency perceived when actually TYPING in real life. My guess is that the difference between the shortest latency and the longest latency hardly matters for the purpose of a human putting words on a screen. There's so many other cognitive activities going on that I can't imagine someone would notice unless they're specifically looking for it and nothing else. Really, does anyone complain about this stuff? even world-class touch typists?
Of 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?
IMO, a better measure would be from activation of the switch, as opposed to the beginning of key travel. I don't start waiting for the character to appear on my screen from the moment I begin to press down. My anticipation begins when I feel the tactile feedback of the switch activating (or the switch bottoming out on switches that don't offer tactile feedback). On a keyboard with good tactile feedback, I might not move the switch through it's full travel -- just a little bit above and below the activation and reset points.
I immediately switched to skeptic mode when I saw no actuation points or normalization for travel distance. All this is showing is that to move further it takes longer. Duh. Why even bother pointing out the polling rate? That's like setting up runners at random places on the racetrack to measure who's faster. The guy/gal that starts closest to the finish line isn't necessarily faster.
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.
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.)
A weird result with the Das 3 keyboard (25ms) considering it uses a cherry MX switch, same as the Kinesis (55ms).
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.
> 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.
Actual activation might be hard to get, but when the key bottoms out is probably the best way to go. Or even better, why not post both when key travel starts and when it ends. If people are really curious, they can model a linear scale and use the key response plot to guess exactly where the activation happens.
Didn’t watch good enough. There are mechanical keyboards in the review as mentioned below. My bad. Original comment below for future reference.
— - 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.
Compare with musical keyboards where not only key number but also the velocity matters, so each key has two electrical contacts, and the whole thing is usually scanned around 10kHz for proper velocity measurement. Although key contacts are arranged in a diode matrix, the latency is usually below 2 ms, even with good old MIDI.
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.
I've done a simple test with my Macbook Air, using the app "Is It Snappy", as mentioned in the comments. I used the keyboard on my macbook, which is a chiclet style mechanism. The tests were all done in triplicate except for TextEdit, (only twice)
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'!
It actually does seem a little faster, which is sad. I would like to see how much normal userspace can be optimised, and where the delay occurs:
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
This is incredible. Single user mode feels like the screen updates BEFORE pressed the keys, like it is time travelling. I guess I've used to the high latency on newer computers.
Or if you're on Linux (Debian/Ubuntu), switch to one of the default virtual terminals with Ctrl-Alt-F1 (and Ctrl-Alt-F7 to switch back to your X server console on my machine) to experience the delight of low latency keyboard-to-screen typing.
I have something interesting about USB input latency to share.
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.
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."
The MacBook Pro 2015 doesn't use an USB connection to connect the internal keyboard when using macOS. Instead it uses SPI. Unlike the newer MacBook Pros it still has the keyboard wired to USB, but doesn't use that because of power saving reasons.
The issue not mentioned in the article is number of lines on the keyboard matrix used to detect keypresses. Cheaper non-gaming keyboards can only detect up to 4 simultaneous keystrokes. Gaming keyboards can detect up to 6. That may not sound like a significant difference, but if you're moving diagonally (eg. W and D), running (Shift), holding an item (or use) (E) and jumping (space), that is 5 keys which need to be processed. Moving from my older Gaming keyboard to a generic Logitec keyboard, and I was no longer able to run diagonally in FIFA games while doing trick moves. So the non gaming keyboard made me stop playing that game.
Computers are fast. 100ms is eons for things that just run on CPU. With a 2ghz computer, you can count from 1 to almost a billion. That's a billion little steps that can happen in the blank of an eye.
I find my typing accuracy is affected by keyboard latency.
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.
Isn't a big part of the reason "gaming" keyboards cost so much because they can register more than three keys (sometimes four) being hit at the same time - something many cheaper keyboards cannot do due to the way they are wired?
The experience of 100 ms latency is definitely noticeable. Ask anyone who's ever ssh'd to a server across a continent or ocean. Empirically, I notice I have a lot more typos in such a situation.
This great article and the other recent one from him started me down the path of thinking about an end-to-end optimized modern computer and operating environment.
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?
It would be cool to look at Linux vs the BSDs on this.
BSDs (dragonfly and openbsd) do feel like they react faster to keyboard input, but I've always wondered whether it's actually faster or just imagined.
This article prompted the following questions for me:
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."
So.. I noticed the huge latency difference between (Alt+Ctrl+F1) tty1 and Gnome with X11. After some tests using "Is it snappy?" app and my das keyboard I decided to check if Wayland had similar latency problems. After switching to Wayland I cut 40ms off my keyboard latency.. hmm. I don't know why that is but I assume there's some sort of frame buffer latency. The only thing I miss now is Plank :[
[+] [-] colanderman|8 years ago|reply
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.
[+] [-] pdkl95|8 years ago|reply
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
[+] [-] gregmac|8 years ago|reply
If you want to blind A/B test yourself, run this:
Adjust DELAY as you want, and then use test_a and test_b and see if you can guess which is which, then run alias to see for sure.[+] [-] AmVess|8 years ago|reply
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.
[+] [-] stebalien|8 years ago|reply
Unfortunately, programmers/UX designers have a tendency to generalize this rule and use it to excuse slow user interfaces.
[+] [-] azernik|8 years ago|reply
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.
[+] [-] stinos|8 years ago|reply
[+] [-] lightedman|8 years ago|reply
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.)
[+] [-] pygy_|8 years ago|reply
> 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).
[+] [-] crispyambulance|8 years ago|reply
Of 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?
[+] [-] tammer|8 years ago|reply
[+] [-] Risord|8 years ago|reply
[+] [-] korethr|8 years ago|reply
[+] [-] xbkingx|8 years ago|reply
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.
[+] [-] Nition|8 years ago|reply
[+] [-] mjw1007|8 years ago|reply
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.)
[+] [-] baxuz|8 years ago|reply
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.
[+] [-] GuB-42|8 years ago|reply
> 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.
[+] [-] ehsankia|8 years ago|reply
[+] [-] DeepYogurt|8 years ago|reply
[+] [-] nobrains|8 years ago|reply
[+] [-] bastijn|8 years ago|reply
— - 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.
[+] [-] Stenzel|8 years ago|reply
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.
[+] [-] xigency|8 years ago|reply
[+] [-] rubatuga|8 years ago|reply
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'!
[+] [-] akvadrako|8 years ago|reply
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
[+] [-] dannyw|8 years ago|reply
[+] [-] maxymoos|8 years ago|reply
[+] [-] rasz|8 years ago|reply
[+] [-] jtl999|8 years ago|reply
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.
[+] [-] js2|8 years ago|reply
http://isitsnappy.com/
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."
[+] [-] Dunedan|8 years ago|reply
[+] [-] smallstepforman|8 years ago|reply
[+] [-] Skunkleton|8 years ago|reply
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.
[+] [-] nojvek|8 years ago|reply
[+] [-] whipoodle|8 years ago|reply
[+] [-] matthavener|8 years ago|reply
See https://superuser.com/questions/16893/do-usb-or-ps-2-keyboar...
[+] [-] olegkikin|8 years ago|reply
Something like click-to-beep.
[+] [-] ChuckMcM|8 years ago|reply
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.
[+] [-] alasdair_|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] fred256|8 years ago|reply
[+] [-] ilaksh|8 years ago|reply
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?
[+] [-] snvzz|8 years ago|reply
[+] [-] nikodunk|8 years ago|reply
[+] [-] geokon|8 years ago|reply
[+] [-] grantwu|8 years ago|reply
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."
[+] [-] rbanffy|8 years ago|reply
[+] [-] enthdegree|8 years ago|reply
[+] [-] oskenso|8 years ago|reply