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

251–260 of 274 posts

Re: Keyboard latency

#251

Post by whipoodle »

Skunkleton wrote: post #182

On linux, after keyboard has decided that a key has been pressed, and is ready to tell USB about it. 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 rea…

Ok, but the point is that it used to take even less time than it does now, and ideally things would get faster as technology advances.

Re: Keyboard latency

#252

Post by sp332 »

ComputerGuru wrote: post #245
sp332 wrote: post #28

Earlier quoted context omitted.

The PS/2 protocol is incredibly slow. Just sending two bytes over the wire via PS/2 takes 1.3 ms.

True. But that is throughout, not latency. Key presses are latency limited, not bandwidth limited.

But the latency of your keyboard will be increased by 1.3 ms just by putting it on a PS/2 port. That's more than USB polling at 1000Hz.

Re: Keyboard latency

#254

Post by gh02t »

Moru wrote: post #217
ewjordan wrote: post #72

Earlier quoted context omitted.

"the most ergonomic keyboards are those that require the least amount of repetitive motion" 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.…

About 18 years ago I started typing on a Microsoft Natural Keyboard Elite. That helped a lot with my wrists. Since then I have upgraded a few times but always the Natural range of keyboards from Microsoft. They are a lot cheaper than the Kinesis Advantage and easier to learn I guess. I would love to try a Kinesis though but don't dare for that price :-)

The Advantage is certainly an investment, but I found it worthwhile. They last for eons, they're built like a tank. If you have significant wrist problems you might be able to talk your employer into paying for one, I know a couple people who have done that.

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

Re: Keyboard latency

#255

Post by mistercow »

throwawayReply wrote: post #235
mistercow wrote: post #167

Earlier quoted context omitted.

I was suspicious that there might be some artifacts of terminal updating that are amplifying the effect in that test, so I whipped up a little graphical test: 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 ke…

Adding step="0.01" to the input allows stepping down in 10ms increments. 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 notice…

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

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.

Re: Keyboard latency

#256

Post by jetpacktuxedo »

dom0 wrote: post #226
jetpacktuxedo wrote: post #77

Earlier quoted context omitted.

>In tacticale switches the bump and the making of the contact are mechanically connected. 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…

> Nope! This is rarely (if ever?) the case. Cherry MX.

False. You can bend the leaf of a cherry MX switch into all sorts of wild shapes to move the tactile event up and down the press, but the actuation will stay in largely the same place. If you browse the force curves from the link I posted above, you can see that some switches (cherry MX Brown, for example) actuate well after the tactile event.

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.

[1] https://deskthority.net/wiki/Cherry_MX#Construction

Re: Keyboard latency

#257

Post by jetpacktuxedo »

ilaksh wrote: post #136

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

Not sure about low latency (especially since this article seems to have failed to test that at all...), but for low-profile cherry-style switches you could look into the new low-profile Kailh switches, which are sort of based on the old Cherry ML switches. The only manufactured board you can buy with these right now is the Havit HV-KB390L[1], as far as I know.

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

Re: Keyboard latency

#258

Post by dom0 »

jetpacktuxedo wrote: post #256
dom0 wrote: post #226

Earlier quoted context omitted.

> Nope! This is rarely (if ever?) the case. Cherry MX.

False. You can bend the leaf of a cherry MX switch into all sorts of wild shapes to move the tactile event up and down the press, but the actuation will stay in largely the same place. If you browse the force curves from the link I posted above, you can see that some switches (cherry MX Brown, for example) actuate well after the tactile event. The tactile event on a Cherry MX Brown is ~1mm into the travel distance, a…

So you are saying that what makes the tactility (the slider moving on the spring) and that what makes the contact (the slider moving the spring until it touches some other metal) are the same, which is exactly what I said ("mechanically connected").

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.

Re: Keyboard latency

#259

Post by Skunkleton »

whipoodle wrote: post #251
Skunkleton wrote: post #182

On linux, after keyboard has decided that a key has been pressed, and is ready to tell USB about it. 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 rea…

Ok, but the point is that it used to take even less time than it does now, and ideally things would get faster as technology advances.

Yeah, but there used to be only a few steps to draw a new character, and none of those steps were polled, or dependent on a scheduler.

Re: Keyboard latency

#260

Post by Skunkleton »

nojvek wrote: post #195
Skunkleton wrote: post #182

On linux, after keyboard has decided that a key has been pressed, and is ready to tell USB about it. 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 rea…

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.

The issue is that there are a bunch of steps that are polled (usb), or that require many context switches/interactions with the scheduler. All of this adds significant latency, regardless of the throughput of the CPU.
Post reply on HN