I found this article on Hacker News: https://danluu.com/keyboard-latency/. Do we have any idea what the latency on a Model 01 is?
1 Like
@algernon wrote a bit about it on his blog. there are several relevant entries; I think this is the latest:
2 Likes
Now that I’ve seen Dan’s latency methodology and some of his assertions about key debouncing, I’m…not super confident in his numbers.
I did some latency measurements last week. What I did was to instrument our firmware to toggle a pin on the Arduino each time it sent a USB packet. Then I measured the time from key actuation to USB packet. My numbers ran at around 9-14ms depending on whether a compute and data heavy LED effect was running.
Even accepting Dan’s assertion that we’d be looking at 4+ms from ‘finger starts to move’ to first actuation, I think we’re doing pretty good 
I think we should be able to get things pared down from there, but it hasn’t been a priority.
I can send the logic analyzer data from Saleae Logic to anyobody who’d like to look at my results.
3 Likes
For anyone reading my posts and measurements: that’s the main loop time. It does not include debounce, nor transmitting the report to the host. It just measures the time spent in the loop() function, so the numbers I have will be lower than actual, full latency.
1 Like
I just saw this tweet by Michael Stapelberg about how the new Kinesis Advantage 360 Pro (with ZMK firmware) has a 10 ms polling interval. Out of curiosity, do we know how that compares to the Keyboardio Model 01 and the newer Model 100, @jesse? What about the debouncing algorithm?
Michael made the open source Kinesis controller kinx and did some work on figuring out keyboard latency for his replacement board.
The exact latency of the Model 100 depends on a whole lot of factors. As far as I remember, the default poll rate for the Model 100 is 1ms, which is - again, as far as I remember - the same as for the Model 01. The debouncing is around 5ms.
However, the real latency depends on what plugins are enabled and active, and which key you pressed, among other things. It’s very difficult to measure and come up with a single number. With a very stripped down firmware, with debouncing turned off, or the internal keyscan toned down to ~0.25ms, you can get to an ~1ms latency. But that will be a very bare-bones firmware.
As for why it is so difficult to measure: LED mode updates factor into the latency: if you have an animated LED effect, your latency will be worse than if you don’t. If you press a key that will go through all the plugins that handle key events, so the more plugins you have, the longer it takes to process each key. If any of those plugins need to do some processing for the key, that also results in increased latency. Plugins can even decide to delay sending the key event.
Thus, latency depends a lot on what plugins are in play, and those play a bigger factor than the polling rate and the debouncing, and the base latency the firmware operates with.
Before Kaleidoscope became event-driven, the number of plugins in the firmware mattered a lot more than it does now. Originally, each plugin handler would be called once for each key in the keyboard, every cycle. We made it a lot more efficient when we stopped calling handlers for idle keys, and even more efficient when we called the handlers only in response to key toggle-on and toggle-off events.
I can’t recall the numbers, but I’m pretty sure than on a Model01 with lots of key-handling plugins enabled, I was still measuring average cycle times of less than 1ms, even when mashing the keys. The only thing that really pushed that number up a lot was LED effects that are constantly changing the colour of the keys, because the I2C communication for LED updates is (by comparison) very slow.
I doubt that there’s any human-detectable delay added by enabling a bunch of plugins, except for the ones that deliberately delay events (e.g. Qukeys).
1 Like
We have about 4ms of debouncing. When I’ve measured initial-press to USB latency, it’s typically sub-10-ms. We’ve got the standard USB2 1000Hz usb polling interval set up.
Keyscanner firmware is open over at https://github.com/keyboardio/avr_keyscanner