6 ms·

I'm surprised by the section on including key travel time in the latency measures. Wasn't the Apple 2 keyboard about comparable in travel distance and resistanc

by iamevn 5y ago

I'm surprised by the section on including key travel time in the latency measures. Wasn't the Apple 2 keyboard about comparable in travel distance and resistance to today's typical mechanical keyboard switches? I still can't find it in me to like the Apple Magic keyboard because I feel like my fingers are smashing into a metal plate hundreds of times a minute. That's a me problem though and others just have better form. Now I'm curious about the latency of the stuff I've put on teensys in my own custom keyboards/controllers and will need to resist the urge to go shopping for a scope. Also wondering how much PS/2 vs USB matters.

kongin 5y ago
> I'm surprised by the section on including key travel time in the latency measures. Wasn't the Apple 2 keyboard about comparable in travel distance and resistance to today's typical mechanical keyboard switches? >>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, I don't get that either. It should be the time a key makes contact to the time the signal is sent. If I were to design that I would make an external trigger that connects to the solder pads of the key and start the timer on the logic analyser. I like my keys with a lot of travel and a good thunk when they send the signal. This would penalize them extensively for doing exactly what I want. I mean if you want fast keyboards capacitive key caps would be even faster, but I've yet to meet anyone who has replaced their keyboard with a tablet.
- regularfry 5y ago
  Because typing on a capacitive tablet would be tiring. You can't rest your fingers anywhere without registering a touch, so you lose all the benefits of a home row. You need to be able to distinguish between resting contact and a positive press, and capacitives would make that hard. Not impossible, but not easy either, and tablets today don't do it.
  - kongin 5y ago
    Not sure what you're explaining? I'm just pointing out that their metric is extremely flawed and can be easily gamed by an inferior solution. Like the Apple Magic.
    - riversflow 5y ago
      I'm not seeing how its "gaming the metric" to include travel time of the key on a keyboard. Typing is ultimately a physical interaction with an interface, not just data transmission over a wire. Therefore, if we are measuring the latency of the input we must include physical travel time. Consider an extreme example, if each "key" used a control lever, like the type on a tractor or used to control thrust in an airplane, we'll just say 90 degrees with a radius of 8", with a significant amount of linear activation force(relative to a keyboard). It wouldn't matter if the device had response time that was virtually instant when you reached the activation point, the input latency of this system would be so significant as to be impractical for most typing tasks. If anything excluding travel time would be gaming the metric.
      - kongin 5y ago
        >I'm not seeing how its "gaming the metric" to include travel time of the key on a keyboard. Because if we remove travel time by using a capacitive keyboard you end up with something that is objectively a worse keyboard. Replacing the capacitors with strain gauges so you can rest your fingers on the home row without activating them results in an worse keyboard yet again. Any metric that when optimized produces an objectively worse product is a bad metric and optimizing a bad metric is gaming it.
- bee_rider 5y ago
  I think you are right that there are good keyboards that would get penalized in this metric. But I'm not sure that it makes sense to try to improve the measurement system -- is is possible that this just isn't a very important measurement.
Agingcoder 5y ago
I agree with you about the apple magic keyboard. It hurts quite badly!
bschwindHN 5y ago
> Also wondering how much PS/2 vs USB matters. Ben Eater has a great video on this: https://www.youtube.com/watch?v=wdgULBpRoXk https://www.youtube.com/watch?v=wdgULBpRoXk
AussieWog93 5y ago
>Also wondering how much PS/2 vs USB matters. I had to get to grips with the USB spec when designing my USB scope [1]. Adherence to the USB spec itself doesn't necessarily create human-perceptible latency; HID frames can be transmitted every 1 ms and could be parsed in a negligible number of CPU cycles on an embedded machine with USB-OTG and no operating system. Like everything, the noticeable lag appears because the application-layer software is going through 15 layers of abstraction rather than talking directly to the input device, and this can become as complex and bloated as it wants. [1] https://espotek.com/labrador/ https://espotek.com/labrador/ (In case you become unable to resist your scope urge :P)
- puzzlingcaptcha 5y ago
  Thanks for sharing, that looks like a great hobbyist tool.
  - AussieWog93 5y ago
    You're welcome. Not going to pass up an opportunity to shill my business on HN. :P
- unwind 5y ago
  Thanks for sharing. Micro typo alert on the Labrador landing page: "Everything was been" -> "Everything has been" or "Everything was", I guess. :)
Ballas 5y ago
A lot of time can be wasted with poor debounce implementations. Cherry switches claims <8ms bounce IIRC, but you only need to debounce one of the edges. So as soon as you see the key start bouncing, you know it is activated, so you can immediately register the press, then do debounce. That way you only delay the registration of the release. By using a shift register you can also minimize it to the actual bounce time, not a predetermined delay. I (personally) don't know of any commercial keyboards that implements it this way, but given that their software is closed source, it is very possible that some do use this algorithm.
- awelkie 5y ago
  Not only that, but the matrix scanning could be done via interrupts instead of via polling as is typically[0] done. An interrupt could fire on a level shift of any of the column GPIOs, then the MCU needs to search the rows to find the selected key. After the interrupt the MCU will need to poll until all the keys are released. So there's another source of latency that could be improved. I think the only source of polling left is in USB, but I think that's inherent to the USB protocol (someone correct me if I'm wrong here). Without the USB polling I think it would be possible to have key-press-to-USB-packet completely interrupt driven which should make the latency in the keyboard itself negligible. [0]: I say typically but like you said a lot of implementations are closed source, so who knows. All of the discussions I've seen on matrix scanning use the polling method, and the open source implementations use polling as well (e.g. Keyberon[1]). [1]: https://github.com/TeXitoi/keyberon-grid/blob/master/src/bin/keyberon60.rs#L239 https://github.com/TeXitoi/keyberon-grid/blob/master/src/bin...
  - Ballas 5y ago
    The few open source implementations I have looked at scan the matrix as fast as the processor allows. So using interrupts can reduce power consumption a lot, but depending on the actual matrix layout, probably not any worthwhile speedup in the nominal case, as you still have to scan the rows after the interrupt. AFAIR, the USB poll rate is a function of USB rate, and what the endpoint reports/requests. Low-speed, full-speed and high-speed all have different poll rates.
  - 5y ago
wmwmwm 5y ago
There’s a great video here that goes through all this - the gist is that USB keyboards specify what polling rate to use, 1000hz for the best ones, maybe 125hz for the cheaper ones. An interesting thing about ps/2 is that even though it doesn’t have to wait for the keyboard to poll it transmits data at much slower speed than USB (khz vs mhz) which somewhat offsets the advantage it gets from being interrupt driven https://m.youtube.com/watch?v=wdgULBpRoXk https://m.youtube.com/watch?v=wdgULBpRoXk edit: ah, sorry, I see someone's posted a link to this video already!
bborud 5y ago
That bit made no sense. It might have made some sense if it was measured from the moment you get physical feedback from the keyboard that the key has been pressed. But I suspect that this isn't as straight forward as it is tempting to believe. (For instance if the mechanical feedback and the moment of contact do not occur at the exact same moment)

by iamevn 5y ago

kongin 5y ago

> I'm surprised by the section on including key travel time in the latency measures. Wasn't the Apple 2 keyboard about comparable in travel distance and resistance to today's typical mechanical keyboard switches? >>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, I don't get that either. It should be the time a key makes contact to the time the signal is sent. If I were to design that I would make an external trigger that connects to the solder pads of the key and start the timer on the logic analyser. I like my keys with a lot of travel and a good thunk when they send the signal. This would penalize them extensively for doing exactly what I want. I mean if you want fast keyboards capacitive key caps would be even faster, but I've yet to meet anyone who has replaced their keyboard with a tablet.

regularfry 5y ago
Because typing on a capacitive tablet would be tiring. You can't rest your fingers anywhere without registering a touch, so you lose all the benefits of a home row. You need to be able to distinguish between resting contact and a positive press, and capacitives would make that hard. Not impossible, but not easy either, and tablets today don't do it.
- kongin 5y ago
  Not sure what you're explaining? I'm just pointing out that their metric is extremely flawed and can be easily gamed by an inferior solution. Like the Apple Magic.
  - riversflow 5y ago
    I'm not seeing how its "gaming the metric" to include travel time of the key on a keyboard. Typing is ultimately a physical interaction with an interface, not just data transmission over a wire. Therefore, if we are measuring the latency of the input we must include physical travel time. Consider an extreme example, if each "key" used a control lever, like the type on a tractor or used to control thrust in an airplane, we'll just say 90 degrees with a radius of 8", with a significant amount of linear activation force(relative to a keyboard). It wouldn't matter if the device had response time that was virtually instant when you reached the activation point, the input latency of this system would be so significant as to be impractical for most typing tasks. If anything excluding travel time would be gaming the metric.
    - kongin 5y ago
      >I'm not seeing how its "gaming the metric" to include travel time of the key on a keyboard. Because if we remove travel time by using a capacitive keyboard you end up with something that is objectively a worse keyboard. Replacing the capacitors with strain gauges so you can rest your fingers on the home row without activating them results in an worse keyboard yet again. Any metric that when optimized produces an objectively worse product is a bad metric and optimizing a bad metric is gaming it.
bee_rider 5y ago
I think you are right that there are good keyboards that would get penalized in this metric. But I'm not sure that it makes sense to try to improve the measurement system -- is is possible that this just isn't a very important measurement.

Agingcoder 5y ago

I agree with you about the apple magic keyboard. It hurts quite badly!

bschwindHN 5y ago

> Also wondering how much PS/2 vs USB matters. Ben Eater has a great video on this: https://www.youtube.com/watch?v=wdgULBpRoXk https://www.youtube.com/watch?v=wdgULBpRoXk

AussieWog93 5y ago

>Also wondering how much PS/2 vs USB matters. I had to get to grips with the USB spec when designing my USB scope [1]. Adherence to the USB spec itself doesn't necessarily create human-perceptible latency; HID frames can be transmitted every 1 ms and could be parsed in a negligible number of CPU cycles on an embedded machine with USB-OTG and no operating system. Like everything, the noticeable lag appears because the application-layer software is going through 15 layers of abstraction rather than talking directly to the input device, and this can become as complex and bloated as it wants. [1] https://espotek.com/labrador/ https://espotek.com/labrador/ (In case you become unable to resist your scope urge :P)

puzzlingcaptcha 5y ago
Thanks for sharing, that looks like a great hobbyist tool.
- AussieWog93 5y ago
  You're welcome. Not going to pass up an opportunity to shill my business on HN. :P
unwind 5y ago
Thanks for sharing. Micro typo alert on the Labrador landing page: "Everything was been" -> "Everything has been" or "Everything was", I guess. :)

Ballas 5y ago

A lot of time can be wasted with poor debounce implementations. Cherry switches claims <8ms bounce IIRC, but you only need to debounce one of the edges. So as soon as you see the key start bouncing, you know it is activated, so you can immediately register the press, then do debounce. That way you only delay the registration of the release. By using a shift register you can also minimize it to the actual bounce time, not a predetermined delay. I (personally) don't know of any commercial keyboards that implements it this way, but given that their software is closed source, it is very possible that some do use this algorithm.

awelkie 5y ago
Not only that, but the matrix scanning could be done via interrupts instead of via polling as is typically[0] done. An interrupt could fire on a level shift of any of the column GPIOs, then the MCU needs to search the rows to find the selected key. After the interrupt the MCU will need to poll until all the keys are released. So there's another source of latency that could be improved. I think the only source of polling left is in USB, but I think that's inherent to the USB protocol (someone correct me if I'm wrong here). Without the USB polling I think it would be possible to have key-press-to-USB-packet completely interrupt driven which should make the latency in the keyboard itself negligible. [0]: I say typically but like you said a lot of implementations are closed source, so who knows. All of the discussions I've seen on matrix scanning use the polling method, and the open source implementations use polling as well (e.g. Keyberon[1]). [1]: https://github.com/TeXitoi/keyberon-grid/blob/master/src/bin/keyberon60.rs#L239 https://github.com/TeXitoi/keyberon-grid/blob/master/src/bin...
- Ballas 5y ago
  The few open source implementations I have looked at scan the matrix as fast as the processor allows. So using interrupts can reduce power consumption a lot, but depending on the actual matrix layout, probably not any worthwhile speedup in the nominal case, as you still have to scan the rows after the interrupt. AFAIR, the USB poll rate is a function of USB rate, and what the endpoint reports/requests. Low-speed, full-speed and high-speed all have different poll rates.
- 5y ago

wmwmwm 5y ago

There’s a great video here that goes through all this - the gist is that USB keyboards specify what polling rate to use, 1000hz for the best ones, maybe 125hz for the cheaper ones. An interesting thing about ps/2 is that even though it doesn’t have to wait for the keyboard to poll it transmits data at much slower speed than USB (khz vs mhz) which somewhat offsets the advantage it gets from being interrupt driven https://m.youtube.com/watch?v=wdgULBpRoXk https://m.youtube.com/watch?v=wdgULBpRoXk edit: ah, sorry, I see someone's posted a link to this video already!

bborud 5y ago

That bit made no sense. It might have made some sense if it was measured from the moment you get physical feedback from the keyboard that the key has been pressed. But I suspect that this isn't as straight forward as it is tempting to believe. (For instance if the mechanical feedback and the moment of contact do not occur at the exact same moment)