Hacker News Reader

Comment by dan-robertson | Hacker News Reader

This does encourage optimising the OS or application part (eg double buffering and taking another frame is slow), but it doesn’t measure two significant sources of latency:

The latency in the hardware before the signal makes it to the usb (for most keyboards, even specialised gaming keyboards this is like 30ms, which is 2 frames).

There is also the latency from when the monitor gets a signal to when the pixels have perceptually finished transitioning. This can be 10s of ms too.

So even if the OS has 0 latency, and the monitor measures that, you could still easily observe a latency of say 60ms.

View on HN

True! I just watched this video [1] they put out with more details, and it sounds like they are working with monitor and mouse manufacturers to build true end-to-end latency measurement when using supported hardware. It would be easy for manufacturers to game these numbers, but hopefully Nvidia will provide some enforcement to prevent that. Maybe they could also add a microphone to measure audio latency because that is another huge problem with modern systems.

The video mentions that they get 15 ms end-to-end latency on a 360 Hz monitor in Fortnite. So that's what it takes for a modern system to finally beat the latency that you used to get on, say, an NES connected to a CRT. Still an order of magnitude above the limits of perception though [2].

[1] https://www.youtube.com/watch?v=-cXg7GQogAE

[2] https://www.youtube.com/watch?v=vOvQCPLkPt4

Yes! I watched that video many years ago. And then later I remember when media were hyping how "responsive" Apple Pencil was I was thinking what on earth are these people looking at. I thought to myself we would never get there because no one gives a damn about it. How the world has changed!

I often wonder at what cost, could we get it down to Sub Ms. Where everything from Input, Video and Audio are sync to the precision of 1ms. There used to be very little incentive to do so. Now that Gaming has taken over I hope it will develop some market perception and value so we could finally move into that direction.

The age of Instantaneous Computing.

> for most keyboards, even specialised gaming keyboards this is like 30ms, which is 2 frames

Worth noting that unlike some of the other sources being discussed, this source of latency is more due to physical constraints than bad engineering or bloated software. Keyboards are limited by the physical travel time & de-bounce of the mechanical switches themselves.

So this is more a tradeoff of using mechanical keyboards at all rather than "gah bloated electron" or whatever.

The other common peripheral, mice, don't have this mechanical constraint. They can even achieve sub-10ms for clicks due to the difference in switch expectations ( https://www.rtings.com/mouse/tests/control/latency )

EDIT: Also 30+ms seems to be quite far off. Cherry MX's specs are around 5ms, and I'm getting 8ms playing around with this tool: http://blog.seethis.link/scan-rate-estimator/

I understand keys take time to travel, but you can press them faster if you want. On the other hand I've never understood debounce as a justification for button latency. Surely a properly designed debounce circuit would add zero latency.

> but you can press them faster if you want

I mean, yes but not really? There's very real speed limits to the human finger, after all.

But the times given above are also quite far off - the actual keyboard numbers seem to be more in the 5-15ms range, not 30+ms. At least, my mechanical gaming keyboard is hitting 8ms on this test: http://blog.seethis.link/scan-rate-estimator/

I'm thinking that a debouncer might give rise to some latency when you let go of a button, or at the very least limit the shortest possible keypress. As in the first rising edge is definitely a keypress, but the falling edge is not necessarily a release.

Surely a properly designed debounce circuit would add zero latency.

If you only have to worry about false deactivation and there's no line noise, and your keys always stay down long enough to be caught by your scan interval (or they trigger an interrupt), then probably yes. If you have to worry about false activation, then probably no.

What’s a properly designed denounce circuit look like that adds 0 latency? Also, for anything that’s a gesture (eg double-click on a mouse) you need time to disambiguate. I wouldn’t be surprised if there’s something similar for the laser in terms of translating the analog signal to digital and then processing it and converting it into HID events the OS can understand.

You send the key event and THEN start the debounce timer. I think most people tasked with writing a debounce function wait for the key state to change, then start a timer for how long they think the switch will bounce for, check the state after the timer expires, and then send the key event. Obviously, that adds latency. But what you can do instead is send the key event immediately and then completely ignore events during the debounce interval.

Simple, you just ignore further input for x milliseconds after the first state change, where x is slightly less than the fastest supported double-click interval.

You certainly don't want to low-pass filter the whole thing, or otherwise wait for the contact to settle before reporting the keystroke or mouse click.

By definition a bounce takes time to detect. And you will get multiple bounces over a time period, so there is a tradeoff between latency and false positives and false negatives. As such, there must be a measurable latency in all debouncing mitigations. But depending on the switch this latency might be measured in microseconds, so you’re sort of right that debouncing doesn’t have to add significant latency for good switches and a good contoller. For a bad switch, and a slow controller, you might start to get into the ms range to ensure a switch is pulled high/low reliably.

Denouncing is there to prevent multiple detection where there is only one.

In general, you can make a denouncer with zero latency: the receiver still triggers on the first logic change for idle to active, but then gates any further changes for a while.

(At least, that’s how I design all my debouncers.)

There may be aspects that are specific to a matrix keyboard configuration that prevent this...

I picked 30ms from here: https://danluu.com/keyboard-latency/

It seemed a reasonable number for a goodish keyboard on that list

The methodology of that test was a finger pressing the key and includes that travel time. So it's hard to say how much latency comes from the keyboard vs. the tester's finger speed & consistency.

An interesting set of numbers, but doesn't tell you all that much about the hardware quality itself. The actuation point and travel distance of mechanical switches is itself an endless source of user opinions & discussions.

Sounds like the post you're responding to is complaining that so many keyboards are at 30ms and not the 5ms/8ms you're seeing. :)

Reply on news.ycombinator.com