Keyboard input lag

[barbar]

Is there such a thing as improving the "performance" of the keyboard as an input device?
With mice, you can make sure that the device is operating at the native resolution, provide the sensor with an optimal tracking surface, keep the lens clean, set a 1ms polling interval, disable interpolative altering of mouse data in the OS (e. g. Enhanced Pointer Precision and Mouse Speed in Windows) and choose for games to use raw mouse data with raw input. All of which serving to make sure you get the least amount of latency and most precise tracking your setup is capable of.

Is there anything comparable for keyboards? Steps to make sure latency is kept minimal? USB vs. PS/2 as an interface, increasing polling rates, changing input code used in games, OS settings like under Character Repeat setting Repeat Delay to Short (preferably using a registry entry to put it to 0 if available), modifying your switches so the actuation point is <1mm? Maybe even ridiculous stuff like CAPSLOCK or NUMLOCK causing added latency?

I apologize if this has been over a countless amount of times already, but using the search didn't yield results specifically dealing with the reduction of "input lag" or ways to achieve that.

[Hucifer]

1000Hz polling rates are common on keyboards these days but honestly the "performance" gain is so negligible it's more placebo than anything else. I mean, we're talking a real world difference of what, 8-10ms at best? Pure marketing BS.

In practical terms I could see how reducing the distance between the point of actuation and bottoming out could make the keys feel a little more responsive for people who really mash their keys, but for most people I doubt it make much of a difference at all.

[ViciousWhiskers]

1000Hz polling rates are common on keyboards these days but honestly the "performance" gain is so negligible it's more placebo than anything else. I mean, we're talking a real world difference of what, 8-10ms at best? Pure marketing BS.

In practical terms I could see how reducing the distance between the point of actuation and bottoming out could make the keys feel a little more responsive for people who really mash their keys, but for most people I doubt it make much of a difference at all.

I think 8-10 ms can make a difference in rhythm games, but yes, to the general users it makes no difference.

[barbar]

I have found a way in Windows 7 to test whether your keyboard truly supports 1kHz polling rate and where its true latency is at, excluding debounce (which I'm convinced doesn't matter as explained further down). usbview.exe does not seem to tell the whole story.

First, set the registry value "KeyboardDelay" as found in HKEY_CURRENT_USER\Control Panel\Keyboard to 0. You'll have to log out and in or restart your PC to apply these changes.

In the Ease of Access Center under "Make the mouse easier to use", activate the "Turn on Mouse Keys" feature.

Open up mouserate.exe and place the cursor in the middle of the designated field of the program's interface.

Using two fingers, slam any 2 keys of the numpad keys (except 5 obviously) simultaneously. Repeat that a couple of times and look for the highest Hz value.

Basically, 1 key actuation causes the creation of 1 WM_MOUSEMOVE message and so when you slam two keys at the same time, you make sure that they are actuated only negligibly apart from each other. From the resulting maximum polling rate, you conclude the interval the signals are being received at, i. e. how much latency there is.

For example, a Tt MEKAG1 of mine (USB) reaches up to 800-1000Hz, while a Microsoft Wired Keyboard 600 caps out at 125Hz (proving that the former is capable of polling rates beyond 125Hz). When key reports are send out in the same packet, the directions of the cursor are combined, so for seperated motion and the corresponding polling rates we can be certain that we are dealing with two seperate reports.
This means that the MEKAG1 can register key strokes and send out the corresponding signals only 1ms apart from each other.
Now for debouncing. I had always assumed that debouncing only affects the actuation of a single key. Only that would make sense because debounce serves solely to prevent the creation of multiple messages from a single switch being actuated multiple times during a very short time frame (caused by the mechanical nature of switches). There is no reason to debounce the whole matrix.
With showing that the signaling rate does not cap out at <200Hz, I feel validated that debouncing is not a global phenomenon. If keystrokes can be registered only 1 millisecond apart from each other, the minimum of 5ms debounce can not apply to two different keys.

Interestingly, using PS/2 with the MEKAG1, it caps out at 360Hz, meaning the key strokes are registered ~2.7ms apart from each other. Even more interestingly, when connected via USB and restarting the PC, the MEKAG1's polling interval is capped at 8ms/125Hz. I have to disconnect and reconnect it for it to go beyond 125Hz. Maybe because upon connecting it, it tells the USB controller what kind of HID protocol it wants to communicate with. I don't know if this is the same for other "1000Hz" keyboards.
If I made any mistake in my assumptions or method please correct me. At this point, I guess this shows USB to be the superior interface in terms of latency given a true 1kHz keyboard. Remember however that polling latency only plays a role when you actuate 2 or more keys during a short time span. If you press two keys more than 8ms apart from each other, that input is polled instantly and it doesn't matter whether the keyboard supports a 1ms or 8ms polling interval (at least that is how I think it is - if the polling interval actually determines the device's signaling rate, i. e. only sends out data to the PC every 8ms at 125Hz, then maximum polling rate would always determine latency of input - but that would be news to me, as far as I know polling interval only determines the rate the host controller polls the buffer at, not the rate the device fills that buffer at).

TL;DR: Debounce delay only affects 1 key at a time (for the keyboard tested at least) and therefore polling rates beyond 200Hz can be beneficial in terms of latency, although the benefit is questionable since you hardly ever press two seperate keys faster than 8ms apart from each other. Can be relevant for fighting game players though or bunnyjumpers that have to execute multiple commands during limited frametimes.

[dorkvader]

If I made any mistake in my assumptions or method please correct me.

I was going to leave this to someone else, but I might as well put my thoughts in before some mistaken conclusions are made.

Now for debouncing. I had always assumed that debouncing only affects the actuation of a single key. Only that would make sense because debounce serves solely to prevent the creation of multiple messages from a single switch being actuated multiple times during a very short time frame (caused by the mechanical nature of switches). There is no reason to debounce the whole matrix.
With showing that the signaling rate does not cap out at <200Hz, I feel validated that debouncing is not a global phenomenon. If keystrokes can be registered only 1 millisecond apart from each other, the minimum of 5ms debounce can not apply to two different keys.

Debouncing still occurs even if multiple keys are pressed. How do I know that? well, based on your test, if debouncing only occurred for one key, and you pressed two: the following would occur: For the first (debounced) key that you pressed, you'd get one output. For the second (non-debounced) key, you'd get a huge multitude of presses over the course of 5ms. On your program, you'd see a bunch of random presses form the second key you hit followed by a single press from the first key you actually hit. The time interval would be roughly 3-12ms until you stopped receiving output.

Since you get only one "press" for each key you hit, then you know that they are both debounced.

What does this have to do with latency? unfortunately, it's sorta-hard to measure latency. Here is what actually happens:

You press two keys more or less simultaneously. The microcontroller starts to see some action at those nodes on the matrix and runs some debounce. about 10ms later, the microcontroller sends both outputs at more or less the same time.

The poll rate does matter, because it helps get a really fine grain on when the keyboard can output useful info to the computer. I would say you don't gain too much from this, as anything the computer sees from the KB controller will be at least 10ms later than when you performed the action (It's something like upper bound of (debounce time) + (maximum polling latency), lower bound (debounce time) + (minimum polling latency (theoretically 0?)) for the time range, having better polling rate will improve your 'polling latency' measure (as I call it) and will up the upper bound a little.

I don't know too much about the USB spec, so I don't know how long it takes for the computer to "do something" about a USB input once it's polled the USB controller and registered an event, but that would add to the "polling latency" measure.

You also run into issues with how fast the KB scans the matrix. Due to debounce times being so long, little is gained from scanning the matrix faster than 200 Hz or so.

If you had a keyboard that didn't need debouncing, you could dramatically speed up the keyboard to near realtime. The proposed plan for hall effect will scan the matrix at (hopefully) about 100,000 Hz (three orders of magnitude faster than most cherry KBs) and since the switches are schmitt-triggered, they don't need debouncing (and instead have a little hysteresis). In such a case, the USB poll rate is the limiting point, as it's "only" 1000 Hz

In such a KB, you'd press a key (past the actuation point), the microcontroller would register it at most 100,000 ^ -1 seconds later and the computer would receive the event at most 1000 ^ -1 seconds after that. It would be quite hard to get better performance than this.

So I think you are still seeing debounce and therefore latency. I think debounce times for cherry MX switches are somewhere between 5 ms and 12 ms, but I would have to look up that value to be sure.

another thing:

Only that would make sense because debounce serves solely to prevent the creation of multiple messages from a single switch being actuated multiple times during a very short time frame (caused by the mechanical nature of switches). There is no reason to debounce the whole matrix.

This is not the case, which explains your mistaken conclusion. When you actuate a contact-based switch (and almost any type of switch there is) the switch will "bounce" between the open and closed states before settling in the closed position.  Here is a picture form wikipedia:

So it serves to distinguish a single actuation from a single keypress, not to distinguish multiple keypresses in rapid succession. You need this for multiple switches to avoid the behaviour I explain in the beginning of my reply. The most common indicator of an improperly-debounced switch is that you'll get multiple actuations on a single keypress. To prevent this, you must debounce every switch. This is indeed the mechanical nature of switches and occurs for almost every switch.
I recommend Haata's presentation from keycon

t=5126
(his presentation ends at roughly 1:53:54

You can also red his slides here

[Puddsy]

as an aside polling rate and other input lag related factors have little to no impact on any gaming

also just know that i have never once said "I wish I had a higher polling rate"

[barbar]

Thanks for the quick answer.

I'm afraid I haven't made myself very clear. Of course there is debounce delay for the second key stroke as well. But only for that specific key - i. e. no global, matrix-spanning delay for registering of switch actuations. When you press "A", only "A" will not be able to be actuated for another 5-Xms depending on debounce delay of the specific keyboard. But any other key, e. g. "B" will not be affected by the debouncing of "A", meaning the keyboard can register the actuation of "B" even if it is actuated for example 2ms after "A". If debouncing would be a global thing, like it is commonly stated, any polling rate above 200Hz for keyboards with 5ms debounce would be useless either way. In fact, getting results beyond 200Hz with my testing method would be impossible in that case, hence why I see the results as proof that debounce is not global.

As for the latency measured on the PC not telling the whole story because first the keyboard takes time to send the packet out: While I see how that could be true, I thought the fact that we are dealing with two seperate packets, each containing 1 key event, is proof that packets are send out much faster than for example 10ms. Again, if the two key events are combined in 1 packet, down+left movement of the cursor happens simultaneously in 1 WM_MOUSEMOVE message, i. e. the cursor travels diagonally in 1 motion and mouserate.exe reports 1Hz, i. e. 1 report/s. But they are not necessarily combined. If one just happens to be actuated somewhat later than the other, what happens is that both events are registered in seperate packets, the cursor first going down and then left in two motions, and mouserate.exe reporting whatever corresponding polling interval. Since the packets are received up to only 1ms apart from each other, there can be no 10ms signaling delay.

The only way that could happen is if there was a buffer in the keyboard, where the key events are stored for the time being and signed with timestamps and finally send out together in one report as two packets. But then the OS would also need a corresponding feature where it reads those timestamps and applies the events seperately and apart from each other exactly at the time differential given by the keyboard. I doubt that the OS does that. If both "packets" would be received in one report, the OS would most likely combine them, so that only one WM_MOUSEMOVE message is created instead of two.

What it also shows is that matrix scanning happens at at least 1000Hz, otherwise the second actuation could not be registered 1ms after the frist.

[FoxWolf1]

Wasn't there a thread several years ago, before the long downtime, where someone actually did a bunch of measurements to study keyboard polling rates and their effect on response time? IIRC it turned out to make more of a difference than expected.

One thing I wonder about is why debounce causes a lag in the response to the initial pressing of a key. I'm looking at that graph of the switch bouncing as I think about this, and I don't get why you couldn't send the signal ASAP after the first vertical dotted line...I mean, couldn't you have it notice that it had gone from a period of steady low-flat-line to not low-flat-line (assuming your controller can maintain a memory of the state of every switch in every matrix-polling-period for the last, say, 20ms, and check that memory without any delay), which must mean something has happened? Then to avoid chatter, you ignore for a certain period afterwards. Why would you have to wait for the bouncing to finish before you let the key register?

[barbar]

@ FoxWolf1

As far as I know and my tests suggest, that is actually what happens. The keystroke is registered at the first time of actuation, and only then the debouncing prevents any further registering of that switch for a certain time. Again, otherwise a second key could not be registered faster than debounce time (>5ms) after a first. Since my tests show that that is possible (only ~1ms between registering of key X vs. key Y), debouncing must kick in after initial actuation has been registered, and only affect one key at a time.

[Grendel]

Don't even know where to start here...

 - there are a bunch of numbers that affect latency from when the key is 1st actuated and the OS registers it: matrix scan rate, debounce time/algorithm, USB poll rate, USB transport rate, OS interrupt latency.
 - matrix scan rate: a decent rate is 1kHz, giving you a max. latency of 1ms
 - debounce: there are many ways how to implement this, common seems to be to check individual keys and to declare a key stable after 8ms of no more changes. Max. latency here is 5ms (max. bounce time for Cherry MX) + 8ms -> 13ms.
 - USB poll rate. A lot of boards spec 10ms here, ie. the board is queried every 10ms for a new report. Max. latency is 10ms is this case. Note that Windows seems to limit low speed USB links to a min. poll rate of 8ms regardless of what the device is requesting (USB specs. say 1ms is the minimum.) A lot of boards are low speed USB devices...
 - USB transport latency will probably be < 1ms, OS interrupt latency will be 1ms for Windows.

So the worst case overall latency in above's scenario (which I would rate as a typical gamer's board) would be 1+13+10+1 = 25ms, the average latency is something about 0.5+11+5+0.5 = 17ms. Not noticeable for a typist IMO.

Things to improve this:

 - matrix scan rate of 2kHz, 0.5ms latency
 - 1.5ms stable debounce, 5ms+1.5ms latency
 - USB full speed w/ 1ms poll rate, 1ms latency
 - OS latency 1ms

--> overall worst case latency 9ms, average 5.75ms. IMHO it's possible that a a professional gamer could make out a difference. Not sure I do...

[barbar]

@ Grendel:

I'm not trying to deny everything that has been established about keyboard input, and the latency chain definitely does seem sensible. But take a look at my tests. I'm suprised myself, I expected the interval to cap out sooner as well, but how do you explain that two seperate key events are registered on the PC as fast as only 1 millisecond apart from each other?

Just to clarify, as I noticed I hadn't explained that part yet: mouserate.exe looks at two or more WM_MOUSEMOVE messages and depending on the difference in time of creation between both determines the polling rate. Reaching 1000Hz means that two WM_MOUSEMOVE messages were created 1 millisecond apart from each other. Since 1 key actuation causes the OS to create 1 WM_MOUSEMOVE message, this serves as an indication that scanning rate of the matrix is at least 1kHz, that debouncing delay only kicks in after initial actuation of a switch and that debounce also only affects 1 key at a time and does not delay the entire matrix scan. Additionally, since it can be established that the key events are received as seperate packets (multiple reports), we can conclude that the whole process for the second key press to be send to the PC also only takes 1ms at max.

At least these are the conclusions I have to arrive at given the test results. The only possible way that these conclusions are wrong is that the key events are buffered in the keyboard and timestamped and later applied by the OS in the correct order, seperate from each other and according to the timestamps. But that is not only questionable on its own, but all the more questionable considering that normally when key events are received simultaneously by the PC, they are combined, resulting in the OS only creating 1 WM_MOUSEMOVE message as acombination of the two and mouserate.exe only reporting 1 report. So if two WM_MOUSEMOVE messages are created, chances are, there have been two reports received at different times.

Sorry for the repetitiveness of my ramblings, hard to nail the formulation.

[Grendel]

@ Grendel:

I'm not trying to deny everything that has been established about keyboard input, and the latency chain definitely does seem sensible. But take a look at my tests. I'm suprised myself, I expected the interval to cap out sooner as well, but how do you explain that two seperate key events are registered on the PC as fast as only 1 millisecond apart from each other?

Ideally they started of 1ms apart from each other and made it through the chain keeping their distance. More likely they started further apart and 1st key got delayed along the way allowing the 2nd key to catch up to w/in 1ms. The thing w/ multiple discrete latencies that add up is that you almost never get the same number twice in a row.

[barbar]

Latencies are pretty consistent for me. 350-370Hz with PS/2 and 700-1000Hz with USB. The inconsistencies are more likely caused by the actual mechanical time of actuation rather than by the following processing steps.

I can't say I have the necessary knowledge to prove the statement wrong that an input event can get delayed in the chain so that a second one "cacthes up", but from my general grasp of how input reading works, that just sounds off.

As far as the inputs starting off 1ms apart and keeping that distance throughout the chain - with that we can at least agree that it would imply that debounce happens after registering key actuation and that debounce delay only affects 1 key at a time, is not "global" in that sense. Else two actuations couldn't be registered only 1ms apart from each other.
Why I also think that the chain latency must be way lower than what we normally assume is that the key events are provided in seperate packets (proof of that being that they are not combined into 1 WM_MOUSEMOVE message). As such, the second key event must have passed all processive steps in the keyboard, the transfer protocol etc. - all possible delays would show in the time between registering input event #1 and input event #2. And since the time differential is a mere 1ms, well, that would mean after registering a key stroke, the rest happens pretty much instantaneous.
But I understand that there very well could be more delay and that the seperate packets are somehow transferred simultaneously after for example 10ms, only timestamped or something to maintain the initial difference in time. At the very least, my conclusions about debouncing and matrix scan would still stand even in that scenario.

You are welcome to follow my steps and play around with the test method. Maybe you have some ideas for more ways to use the test, or notice something I possibly am missing.
It would be easier and probably more reliable if someone with coding experience would write a little program where we don't rely on the keyboard creating WM_MOUSEMOVE messages, but where simply keyboard input events are monitored as they come in and the time between those registrations being expressed in ms.

[Grendel]

I can't say I have the necessary knowledge to prove the statement wrong that an input event can get delayed in the chain so that a second one "cacthes up", but from my general grasp of how input reading works, that just sounds off.

It just means that key 1 gets delayed longer than key 2.

As far as the inputs starting off 1ms apart and keeping that distance throughout the chain - with that we can at least agree that it would imply that debounce happens after registering key actuation and that debounce delay only affects 1 key at a time, is not "global" in that sense. Else two actuations couldn't be registered only 1ms apart from each other.

Correct. Delaying the matrix scan for a single key to finish bouncing would be counter productive.

Why I also think that the chain latency must be way lower than what we normally assume is that the key events are provided in seperate packets (proof of that being that they are not combined into 1 WM_MOUSEMOVE message). As such, the second key event must have passed all processive steps in the keyboard, the transfer protocol etc. - all possible delays would show in the time between registering input event #1 and input event #2. And since the time differential is a mere 1ms, well, that would mean after registering a key stroke, the rest happens pretty much instantaneous.

Nope. There is no way of deducting the latency by only measuring the interval of two independent events after they traveled the chain. You need to know exactly when a key psychically actuates, pretty complicated rig to do that.

But I understand that there very well could be more delay and that the seperate packets are somehow transferred simultaneously after for example 10ms, only timestamped or something to maintain the initial difference in time. At the very least, my conclusions about debouncing and matrix scan would still stand even in that scenario.

You are welcome to follow my steps and play around with the test method. Maybe you have some ideas for more ways to use the test, or notice something I possibly am missing.
It would be easier and probably more reliable if someone with coding experience would write a little program where we don't rely on the keyboard creating WM_MOUSEMOVE messages, but where simply keyboard input events are monitored as they come in and the time between those registrations being expressed in ms.

Switch Hitter gives you some timing info. Still not enough to assess the latency tho.

[barbar]

Correct. Delaying the matrix scan for a single key to finish bouncing would be counter productive.

As would a debouncing feature where the keyboard waits for Xms depending on debounce to register a key actuation. Both are proven wrong by the test (for the tested keyboard) and both are not commonly established facts about the workings of keyboards, or not that I'd ever heard. You yourself said "common seems to be to check individual keys and to declare a key stable after 8ms of no more changes.". But yeah, you also said there are different ways to implement this, which might even be the main cause of most keyboards capping out at 125Hz. Not because polling intervals are limited, but because they wait 8ms before they even confirm the actuation of a key.

It just means that key 1 gets delayed longer than key 2.

Input latency normally is the same for all events, some off-timed poll could maybe lead to one event being delayed more than another, but not consistently.

Nope. There is no way of deducting the latency by only measuring the interval of two independent events after they traveled the chain. You need to know exactly when a key psychically actuates, pretty complicated rig to do that.

I get what you are saying, but there's some more to conclude from the time of key registration on the PC. What you are saying is this, which is entirely plausible:

time: x = Key stroke #1
time: x+y where y is total latency = Registration of key event on PC/creation of WM_MOUSEMOVE
time: x+1ms = Key stroke #2
time: x+y+1ms: Registration/creation of another WM_MOUSEMOVE

So, both key strokes are subject to "y" latency, but are still registered only 1ms apart from each other on the PC, even though the total latency "y" for the inputs could be anything.

But again, when input data is received simultaneously in 1 report, Windows combines all "counts" into 1 WM_MOUSEMOVE message specifying the direction and amount of pixels the cursor should travel (when you press for example 4 and 6 at the exact same time (<=1ms), i. e. give the PC 1 "left" and 1 "right" count, the cursor will not move at all). Since it moves 2 times instead of 1 time, I have to assume the input events are received seperately even at poll readings of up to 1000Hz or 1ms. When the physical actuation points are 1ms or more apart, they are processed and send out seperately. What we can conclude from that is that any latency beyond 1ms must come from outside of the keyboard. If the keyboard for example scans the matrix only every 2ms, actuations could not be registered 1 ms apart from each other. Sure, they could be retrieved at the same time when they both happen within 1 scan cycle, but then they would be send out within the same report, combined into 1 mousemove message yadayada. The second key stroke must be processed and sent out seperately from the first if the cursor moves 2 times. That means that the time difference between the registered input packets is 1ms and that there is no delay coming from the keyboard beyond those 1ms. Any added latency in the chain that eventually constitudes "y" must come from hardware components of the PC such as the USB controllers, processor, and whatever else participates in input processing, and the OS.

Another possibility is that they are sent out in the same report, but timestamped. Then this test could indeed not tell us anything about how much latency the keyboard causes.

That latency of course is not measureable with this test as you mentioned. Do you know if the CAPSLOCK or NUMPAD LEDs can be used as indication of time of mechanical actuation of a switch? I have a 1000fps camera and those would make it easy to check for total latency of the input.

[Grendel]

Maybe this becomes more clear w/ a description what exactly (more or less) happens in a keyboard. First, keyboards are not event driven, ie. a key contact closing is not registered until the MCU explicitly measures the current state of the switch. MX switches are specified to have a bounce time < 5ms, during which a point measurement may come back as open or closed.

Most keyboards will poll the entire matrix at a set time interval, let's assume every 1ms, meaning that every switch is measured once in said interval. The MCU keeps track of the supposed state of each switch, remembering if it's open, closed, or in transition for the last n scans, say 8 (--> 8ms back.) If a switch is marked open or closed but measures the opposite, the MCU marks it as in transition. At this point there is already some possible latency present, since the switch could have been physically activated up to 5ms in the past (remember, while bouncing a key may read as open or close.) Once a switch is marked as in transition, every time it is scanned its state of the last 8 scans is evaluated as well -- if they are equal and the opposite from its pre-transition state, the key is now "officially" registered as changed. Anything from 8 to 13ms passed from physical actuation to registering the change at this point.

The state change needs to be send to the USB host. To do this the keyboard will rebuild the USB report after a matrix scan that resulted in change of the key matrix statee (one or more keys changed), either adding the key(s) or taking it (them) out, then stuff the report into the USB packet buffer (part of the MCU's USB sub module) to be send. As far the MCU is concerned the packet is sent and it will continue scanning the matrix while the USB module does its thing.

The packet will sit in the buffer until the USB host is polling for new data. It does this at its own set time interval (this is the USB poll interval that a device requests), usually 10, 8, or 1ms. A QFR or RK-9k eg. request 1ms, a QFS or QFXT 10ms. Note that Windows will limit the interval to a minimum of 8ms if the device is low speed (which every keyboard based on a Holtech controller is.) Once the host allows the packet to be send it has been sitting in the buffer for up to the poll interval ms. If during this time another key change has been recorded, another packet may be waiting right behind the current one to be send and will be picked up the next time the host polls the device after the current packet left. Multiple things to notice here -- we have another latency of up to the poll interval for the current key and up to twice as much for a subsequent key that actuated close but not close enough to make it into the 1st data packet.

Once the data arrives at the host chip inside the PC, it will create an interrupt. In Windows this will invoke a DPC -- from here on it will get complicated rather quickly (ref..) The time from when the packet arrives at the host and you see it on your screen can be really anything depending on your hardware/software configuration, and what is going on at that given time. Not deterministic at all.

[barbar]

Thanks for the insight. I'm afraid I can't exactly conclude from that however direct answers to the questions my test results have me asking. I think one thing is certain and the test results support that: The tested keyboard has a matrix scan rate of 1000Hz. Debounce kicks in after actuation has been registered and only affects that specific key. As we agreed on, otherwise two readings could not be 1ms apart.

We also agree that these test results cannot tell us anything about latency caused by the PC/OS. As for the question of latency in the keyboard, while I assumed that key events being reported/applied seperately up to 1ms apart meant that there could be no latency in the keyboard beyond those 1ms, because else they would be received simultaneously and combined, I have now realized that there can very well be lateny in the keyboard without the test results being contradictive to that. Using a dumbed-down example again:

0ms: Key stroke #1
1ms: Matrix scan registers #1
1ms: Key stroke #2
1ms+10ms: Some stuff that I don't quite understand happens and takes, say, 10ms to process #1
2ms: The next matrix scan registers #2
2ms+10ms: The same stuff happens, taking 10ms to process #2
11ms: Key event #1 arrives in the keyboard buffer ready to be polled
11ms: Key event #1 is polled
12ms: Key event #2 arrives in the buffer
12ms: Key event #2 is polled with the next poll cycle (@ 125Hz it would be polled at 19ms)
Xms: PC/OS do their stuff and create WM_MOUSEMOVE message for #1
Xms+1ms (+8ms @ 125Hz): Same stuff happens with second input and another message is created for #2

I didn't think of that before. So yeah, just because the key events are seperately reported up to only 1ms apart from each other doesn't mean there can be no latency beyond those 1ms in the keyboard already.
This does leave me with new questions though: In the keyboard, what causes of delay are there between a key actuation being registered within a matrix scan and that key event being ready in the buffer for poll by the host?
Any idea why PS/2 caps out at around 360Hz, i. e. ~2.7ms? Always thought the sampling rate of PS/2 was 100-250Hz.

The conclusion about USB being the superior interface in terms of latency for multiple key strokes faster than 8ms actuated apart from each other still stands though, because at 1000Hz maximum polling rate at least the second input is polled only 1ms later than the first, instead of up to ~2.7ms later with PS/2. And the conclusion that "1000Hz" is not entirely a gimmick in keyboards still stands as well, because at 125Hz a second input if actuated less than 8ms after a first will be polled a whole 8ms later as opposed to being polled instantaneously if time between actuation of the keys is larger than 1ms, and otherwise being delayed by only 1ms with 1000Hz.

[Grendel]

One point I'm trying to show w/ my writeup is that receiving two events 1ms apart does not mean the scan rate has to be 1kHz.

This does leave me with new questions though: In the keyboard, what causes of delay are there between a key actuation being registered within a matrix scan and that key event being ready in the buffer for poll by the host?

Bounce time of the switch (0-5ms), debounce time (8ms in above's example), processing time (highly dependent on the firmware implementation, should be < 1ms in most case tho.) These all add up.

Any idea why PS/2 caps out at around 360Hz, i. e. ~2.7ms? Always thought the sampling rate of PS/2 was 100-250Hz.

PS/2 works very different and is a way more efficient than USB (which, while faster bit-by-bit, has a tremendous protocol overhead.) It's a serial port that allows the keyboard to send a key event as soon it's available (vs. creating a status report and waiting for it to be picked up w/ USB.) The theoretical max. event throughput is on the order of 500/s, 360/s looks pretty "real-life".

The conclusion about USB being the superior interface in terms of latency for multiple key strokes faster than 8ms actuated apart from each other still stands though, because at 1000Hz maximum polling rate at least the second input is polled only 1ms later than the first, instead of up to ~2.7ms later with PS/2. And the conclusion that "1000Hz" is not entirely a gimmick in keyboards still stands as well, because at 125Hz a second input if actuated less than 8ms after a first will be polled a whole 8ms later as opposed to being polled instantaneously if time between actuation of the keys is larger than 1ms, and otherwise being delayed by only 1ms with 1000Hz.

If your board supports PS/2 on its USB connector via adapter it will be operating w/ USB slow speed (1.5Mb/s) and thus be limited to a minimum poll rate of 8ms (at least in Windows.) You will experience less input lag by using PS/2 over USB in this case. If your board does not support PS/2 chances are it's operating on USB full speed (12Mb/s.) In that case, assuming a decent firmware implementation, the input lag should be less.

That said, let me repeat that I don't think this matters outside the professional gaming world. People use ErgoDoxes for gaming w/o problems and its left side is scanned at around 160Hz IIRC.

[barbar]

One point I'm trying to show w/ my writeup is that receiving two events 1ms apart does not mean the scan rate has to be 1kHz.

How so? While I realized this test cannot be used to measure total latency, be it in the keyboard itself or elsewhere, with the results at hand I still have to stick to the test being useful to test for three things: Polling rate, scan rate and debounce implementation.

I now have tested another keyboard, namely a Microsoft Wired Keyboard 200 (USB). It caps out consistently at 31(.25) or 62(.5)Hz, i. e. 16-32ms between two key events. While there are different possible scenarios that could cause that time difference between two packets being sent out, we can assume that matrix scan rate is 125Hz and adds the first 8ms, while debouncing being implemented in a way where it confirms a key actuation only after 8ms of having been pressed adds another 8ms.

I think it does hold some value for gaming, Being able to get multiple keys to register within a short time span and also to get those events polled as fast as possible can make a real difference. 32ms vs. 1ms definitely sounds significant. Even 16ms vs. 1ms is relevant in the sense that this could make the difference between input data from the keyboard being polled in time for a frame rendering within a refresh cyle of the monitor or missing that frame rendering/monitor refresh, which adds yet more (perceived) latency to the overall chain.

But I can see how 8ms, or PS/2's ~2.7ms could be mostly negligible because you are only rarely, if ever, pressing keys less than 8ms or let alone 2.7ms apart from each other.

[Grendel]

One point I'm trying to show w/ my writeup is that receiving two events 1ms apart does not mean the scan rate has to be 1kHz.

How so? While I realized this test cannot be used to measure total latency, be it in the keyboard itself or elsewhere, with the results at hand I still have to stick to the test being useful to test for three things: Polling rate, scan rate and debounce implementation.

The delay through the OS drivers. I may allow the 2nd key to "catch up" to the 1st one. While I was playing around w/ these things I looked at the times of a single key going down then up. Using custom firmware w/ 2kHz scan rate, 2ms stable debounce, and 1ms USB poll rate (full speed) the shortest I saw was 2ms betw. key down and key up (using Switch Hitter for getting the events time stamped.) It's very unlikely that actually happened on the keyboard, more likely is that the key down event got delayed slightly longer in the OS than the key up event due to jitter in Windows deferred interrupt processing.

I now have tested another keyboard, namely a Microsoft Wired Keyboard 200 (USB). It caps out consistently at 31(.25) or 62(.5)Hz, i. e. 16-32ms between two key events. While there are different possible scenarios that could cause that time difference between two packets being sent out, we can assume that matrix scan rate is 125Hz and adds the first 8ms, while debouncing being implemented in a way where it confirms a key actuation only after 8ms of having been pressed adds another 8ms.

No way to deduct the scan rate from this behavior. I do agree tho that it probably is less than 1kHz -- rubber dome boards need longer debounce  times and do the matrix scan differently (since there are no diodes to prevent ghosting there may be some underlying "trickery" to allow fast typing.)