Hello,

Keyboard latency, bandwidth, inputs per second... does anyone know where exactly is the bottleneck and what software/hardware specification defines it?


1.) Wikipedia says PS/2 port works at 10-16 kHz and I think protocol defines 11 bits per packet. That comes down do 16,000 / 11 = 1454.55 inputs (keys) per second, right?


2.) USB keyboards?

I have to ask - Why? Are you worried the keyboard might not be able to keep up with you? [smile]

Yes.

Default Windows USB polling rate = 125Hz, i.e. it has 8ms latency. If it can communicate only one key per packet, then that comes down to 125 keys per second. While that may sound enough, it is only about 2 keys per frame @60fps animation, so if you play some fighter where you need to perform "DOWN+RIGHT+PUNCH" in a single frame this can be a problem, especially if there are two players both trying to report their simultaneous combos.

There is also additional limitation where some keys, such as arrow keys, need two scans codes, plus the "break codes" sent for keys that went up, which practically halves the bandwidth if the input buttons are being tapped quickly rather than held down.


What I am saying is that latency and bandwith problems with keyboards can be as real and as serious just like these same problems as manifested in networking. They can impact a game-play, just as much as running a game at 15fps instead of 60fps, for example.

Quote:Original post by dank
Default Windows USB polling rate = 125Hz, i.e. it has 8ms latency. If it can communicate only one key per packet, then that comes down to 125 keys per second.

The documents I've seen state that the default USB keyboard driver can handle at least 6 keys per packet. Even assuming there's only one packet per poll, that would seem fine.

I'm confused about your concerns. Even in the worst case (two scan codes per key, once for key down once for key up) you're still getting 30 key presses per second. For one, it's probably humanly impossible to do this. Then there's the fact that counting animations, game balancing, fun, and such, it's highly unlikely 30 key presses per second could be useful in some way (if it is, consider a key_down autofire mode instead of having players destroy their keyboard).

As for needing down+right+punch in a single frame, I don't see how that's necessary. That would be a sequence anyway, where you'd probably need a game mechanic to see if the next key in the sequence was pressed soon enough after the last (in which case you wouldn't want them all at once anyway - because then, which came first?). If they simply need to be pressed all at once, just do a check for is_key_down.

Wire protocol is the least of problems.

With most keyboards, n-key rollover (NKRO) will be a problem. Majority of keyboards, due to the way signals are read, will only be able to detect up to x simultaneous keypresses.

An easy way to test this is the press certain patterns of keys at the same time (in notepad or similar). Combos such as WASD, QWAS, ERDFCV, QAZEDC.

Most "good" keyboards are 3 way with separate ctrl-shift-alt lines. Some expensive ones are 6-key, but price alone doesn't determine the capabilities. Notebook keyboards are frequently not even 2-key.

Not that it matters, but controller decoding the signals also has latency that determines if a key has been pressed or is being held down. A window of 5-8ms is used for this, while the logic waits for key to pop back up.

When it comes to bandwidth, PS2 and USB are adequate - keyboard's own circuit will typically buffer enough for any realistic use. There can however be issues with PS2-USB adapters.

Long story short - the problems is not the wire, but detecting the keys in the first place. Also, USB keyboards are maximum of 6-key.

Here is one which guarantees NKRO. Depending on marketing, n-key almost always means either 6-key or even worse, 3-key with separate ctrl/alt/shift line.

But it doesn't matter, since most users have crappy keyboards so relying on many keys pressed is guaranteed to not work for 99% of users.

Quote:Original post by Kylotan
The documents I've seen state that the default USB keyboard driver can handle at least 6 keys per packet.

Yes, and there also seem to be some limits due to the keyboard encoders, so for example some keyboards will not be able to *register* more than 3-4 keys are down at the same time. -- EDIT: I see Antheus is talking about encoder side too, and I agree with all that, it makes it even worse in relation to lag behind the "real-time", but I am afraid it gets even more complicated on the computer side, with all the queuing, waiting, buffering, interrupts, and stuff.

Quote:
Even assuming there's only one packet per poll, that would seem fine.

Yes, there is only one packet per poll. What is worse, even though packets are 8 bytes long, they only carry information for one key at the time. Which means that if you press four keys simultaneously, in the same time, it will take 4x8 = 32ms before some application (OS) can do anything about it. They do have the potential to do much better, but as much as I can gather practical data the situation seem to be far worse than anyone would expect.

Here is "USB sniffer" program I used:
http://www.topshareware.com/USBTrace-transfer-42419.htm


My main problem is, I have no idea where is this bottleneck actually located, where are these limits defined. Is it Windows, is it application, is it HID specification, maybe USB protocol, or PS/2 emulation/compatibility, how about keyboard encoder, or perhaps keyboard controller, could it be keyboard buffer entrance point, maybe the driver... or some combination, or something? -- For example, 8 bytes long packets, what defines it, keyboard encoder, OS drivers, some "keyboard specification"?

Quote:Original post by dank
Yes, there is only one packet per poll. What is worse, even though packets are 8 bytes long, they only carry information for one key at the time.

The protocol explicitly allows for 6 keys at a time (plus modifier keys). If you're not seeing that in practice, I expect it's a limitation of your keyboard (or your testing method), and not specific to whether it is USB or PS/2.

Quote:For example, 8 bytes long packets, what defines it, keyboard encoder, OS drivers, some "keyboard specification"?

USB HID specification. But not all keyboards have to use that system.

Starcraft is played by people who train for 20 hours a day for months until their fingers bleed, competing for 6-digit+ prizes.

Peak APM on any competition is around 400. Extremes in short bursts have been said to reach 800. Average in diamond league is 250 that only few reach.

800 APM = 14 per second
400 APM = 7 per second
250 APM = 4.2 per second

Or - the best in the world can only sustain around 5-7 keypresses *per second*.

Quote:1454.55 inputs (keys) per second

Or, 200 times more than any human is capable of producing.

Wire is not the bottleneck. NKRO will be the biggest pain, and more frequently an unsolvable problem.


Also, due to the way modern hardware works, actual latency will be anywhere between 4 and 12 frames (at 60 FPS that is 66-200ms). Lowest possible latency is 3 frames. see here.

Quote:does anyone know where exactly is the bottleneck and what software/hardware specification defines it?

The bottleneck is human.

- Human reaction time is somewhere around 100ms if trained, 500ms+ on average.
- LCD and GPU rendering delays mean that it takes 50-200ms from the time logic started rendering
- A key press takes several milliseconds to go from depressed to the point where it's detected (fingers don't operate at speed of light).

In short - the only bottleneck for two-player button masher will be either NKRO or the human.

Antheus,

I'm talking about different type of games. Look, my keyboard has this limit of two scan codes per 0.016 seconds (one frame @60fps), apparently. So for example, in Donkey Kong, when I first stand complete still, and then *TAP* "arrow_key+jump", it simply will not 'side jump' every time, but either just move or only jump up, rarely both.

What happens is that "arrow_key" will use two packets, or the first two packets that will be registered will hold information about "arrow_key" going on and off, but in either case "jump" packets would come one frame too late. -- This is not about fast firing or rapid tapping of buttons, but simultaneous press of multiple buttons in the same time.


Imagine Street Fighter, you vs. me, and 2 inputs per frame limit. Now, we both push "forward+kick" in the same time, but what happens is that only you kick me and win... just becasue the two packets saying that I also did hit you never had a chance to get there in the same time/frame. Winning is good, but that's not the way you would wanna win, eh? -- Could you test your USB keyboard for multiple simultaneous input with that USB sniffer, so we can see if your keyboard does better than mine?