Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keyboard latency

danluu.com

Post reply on HN
Print view View original

81–90 of 274 posts

Re: Keyboard latency

#81

Post by ehsankia »

korethr wrote: post #2

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 m…

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.

Re: Keyboard latency

#82

Post by tomxor »

gregmac wrote: post #34
colanderman wrote: post #9

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 e…

Hm, neat. I notice about the same result -- 0.1 is quite obvious. 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]}" 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.

neat, 100ms is blatantly obvious, I can't imagine anyone not discerning that one.

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.

Re: Keyboard latency

#83

Post by duskwuff »

valarauca1 wrote: post #57
rubatuga wrote: post #18

Earlier quoted context omitted.

Doesn’t the micro controller in the keyboard still scan, and then send a ps/2 signal?

Most mechanical PS2 keyboards are a diode cascade. 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 Rollove…

This is absolutely untrue for any PS/2 keyboard, as well as for most pre-PS/2 PC keyboards (incuding AT and XT keyboards). All keyboards have always had a microcontroller in them which is responsible for scanning the key matrix and sending output over the serial link. (In PS/2, it's also responsible for reading input to change the state of keyboard LEDs.) There is nothing analog about them whatsoever.

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...

Re: Keyboard latency

#84

Post by xbkingx »

colanderman wrote: post #9

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 e…

The more obvious example is to watch a video encoded at 10 frames per second followed by a 30 fps video. Does it look different? If yes, something's wrong with the statement

There are plenty of examples on YouTube if anyone's interested.

Re: Keyboard latency

#85

Post by bitwize »

bhj wrote: post #37
andyfleming wrote: post #24

Earlier quoted context omitted.

That's fine though. It's about the experience end-to-end. I love the apple keyboards. I still type faster on them than other keyboards, including high-end mechanical keyboards. The short keys and actuation feel responsive, yet I've never felt like I've accidentally triggered a key.

Agreed, and I don't understand the hate many people (seem to) have for them - the most ergonomic keyboards are those that require the least amount of repetitive motion. Not that there isn't an adjustment period, but some seem to pull out their Jump To Conclusion mats a little early.

If you can't adjust to an Apple keyboard (and don't have RSI), the problem is you -- not the keyboard. Retrain yourself to type softly.

Re: Keyboard latency

#86

Post by microcolonel »

I've been experimenting with alternative protocols to HID. I'm not satisfied with fixed-interval input polling out of sync with vsync; it takes way too many samples to reach the desired latency (and especially jitter!) numbers.

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.

Re: Keyboard latency

#87

Post by spott »

tomxor wrote: post #82
gregmac wrote: post #34

Earlier quoted context omitted.

Hm, neat. I notice about the same result -- 0.1 is quite obvious. 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]}" 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.

neat, 100ms is blatantly obvious, I can't imagine anyone not discerning that one. 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 be…

25ms is 1.5 * (1/60)... Is your monitor running at 60Hz?

Re: Keyboard latency

#88

Post by tomxor »

stebalien wrote: post #69
colanderman wrote: post #9

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 e…

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 ti…

I rarely use transitions larger than 100ms in UX, I doubt i'm abnormal in not seeing the result as instantaneous (compared to no transition). On the other hand this certainly is not normal UX design, I am very irritated at how common excessively long transitions are used on the web... to the point that I actually have to wait for things to finish animating before I can interact with them, it feels so 90's like i'm supposed to be impressed with the transition rather than the transition to simply convey the introduction of something and then to get the hell out of the way (like it should).

Re: Keyboard latency

#89

Post by tomxor »

spott wrote: post #87
tomxor wrote: post #82

Earlier quoted context omitted.

neat, 100ms is blatantly obvious, I can't imagine anyone not discerning that one. 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 be…

25ms is 1.5 * (1/60)... Is your monitor running at 60Hz?

Your probably right, it's an old TN panel in a 10yr old laptop... I'm gona have to steal someones shiny modern IPS in a minute :P (I know they are generally slower response but it's 10 years newer so you never know) [edit] No IPS still super slow. How common are >60Hz computer displays these days?

Re: Keyboard latency

#90

Post by jdietrich »

munchbunny wrote: post #71
alasdair_ wrote: post #36

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?

Yes, n-key rollover sometimes comes up. In practice, I've only had it become an issue in the wild either when more than one player is sharing the keyboard or, in some rare games, primarily simulators, where you might need to hold multiple keys.

It's a frequent issue in FPS games. Simultaneously pressing four keys isn't particularly unusual in an FPS, but it confounds an awful lot of non-gaming keyboards.
Post reply on HN