Sign in to follow this  

USB vs PS/2 keyboard: latency, bandwidth, inputs per second?

This topic is 2629 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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"?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
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.


My USB keyboard is indeed an odd one, it's from old iMac. But still, am I in minority or majority? -- Would you mind doing USB trace test for simultaneous multiple input on your keyboard?


Quote:

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


I could only find USB HID specification defines some "boot" keyboard, which is PS/2 compatibility layer, usually embedded in motherboard/firmware and with basic drivers in BIOS, but Windows is supposed to use its own drivers and possibly bypass this old PS/2 "keyboard controller" completely.

So, you say the encoder can tell OS driver it is going to send 10 bytes per packet and it can still be classified as "keyboard device" by HID? But, what happens when this device sends one 10 bytes long packet saying 8 keys are down, will they all be stored in keyboard buffer at once, or will these bytes get queued and go one-by-one into buffer (port 0x60/0x81), according to some keyboard interrupt?

Share this post


Link to post
Share on other sites
I have strong belief that if you take bunch of "pro" CS:S and Quake players, put them on a server where the ping is seemingly 100, when in reality it is 40, they will feel that they perform sub-par. If you switch them to a server which shows ping of 20 ms, then move them to server which shows the real ping of 40 ms, they claim that there is a definite difference between all three servers. :)

There was something along these lines in Soldat community in the summer of 2009, where the (new) game developer hosted and rented servers for players, ran modified server software which reported 16-33 ms lower pings than they actually were. People said that there is no lag in that server. :)

I'm sure there are some studies on this. Most of this is psychological.

And, what actually partly proves it's psychological is that even if there's a 2-4 ms of latency in input, that is a fraction of overall latency from player responding to an event(reaction time, time to actually get the button down, time to process the data and send it over to the server etc). The human factor is way too big in the equation.

I am not saying that there is no problem, I am just hating "pro gamers" with a passion. :)

Share this post


Link to post
Share on other sites
indeed. and his own examples about both pressing the same time, one getting recorded one frame later just shows. i mean, they have to press within 0.016 seconds AND notice which one was first, and that the computer was wrong.

not really possible.

the actual keyboard issue stated above exists. other than that, simultaneity of actual key-PRESSES never was an issue. simultaneity of key-HOLDINGS is (that's the keyboard problem stated above, it's a physical problem).

but the simultaneous detection of the actual press-event, not the holding should never be done. it should be a simple check if all are down at the same time, not if all get pressed down.

Share this post


Link to post
Share on other sites
Quote:
Original post by Calmatory
I'm sure there are some studies on this. Most of this is psychological.


Can you run USB trace with your keyboard and test for multiple simultaneous keys?


Share this post


Link to post
Share on other sites
Quote:
Original post by dank
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.


Then the game input system of the game is designed poorly. If you're checking to see if 2 keys are pushed on the same frame, you're doing it wrong. You should be slightly buffering keypresses and checking "simultaneous" to be within a certain time range, not a specific frame.

It is nearly impossible to physically press 2 keys so that they regularly hit within the same actual frame. It is however, easy to hit them within the same tenth or twentieth of a second or so which is what your game should be detecting.

-me

Share this post


Link to post
Share on other sites
Quote:
Original post by davepermen
but the simultaneous detection of the actual press-event, not the holding should never be done. it should be a simple check if all are down at the same time, not if all get pressed down.


Detection of simultaneous activation of two or more buttons within the certain time window, sometimes a single frame, is crucial for some games. You can not be checking keyboard for "current state", you can only check some keyboard *buffer*, which is located on computer side, not keyboard, and what you will be checking is only what managed to arrive there by that time. I am not talking about the lag behind the real time, I am talking about the *time-window* necessary to signal multiple keys, this is different - see Donkey Kong and Street Fighter examples above.


Can you run USB trace with your keyboard and test for multiple simultaneous keys, so we can see what is the latency and bandwidth, and whether it communicates all the multiple keys in one packet, or one key at the time like mine?

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine

Then the game input system of the game is designed poorly. If you're checking to see if 2 keys are pushed on the same frame, you're doing it wrong. You should be slightly buffering keypresses and checking "simultaneous" to be within a certain time range, not a specific frame.


Ok, I'll go back in time and talk to programmers of Donkey Kong and Street Fighter, I'll tell them they suck. -- I am not doing anything except trying to find out the real-world data. Can you run USB trace with your keyboard and test for multiple simultaneous keys, so we can see what is the latency and bandwidth, and whether it communicates all the multiple keys in one packet, or one key at the time like mine?



Quote:

It is nearly impossible to physically press 2 keys so that they regularly hit within the same actual frame. It is however, easy to hit them within the same tenth or twentieth of a second or so which is what your game should be detecting.
-me


It's very possible, can you try it now, please?

"USB sniffer" to perform the test:
http://www.topshareware.com/USBTrace-transfer-42419.htm

Share this post


Link to post
Share on other sites
Quote:
Original post by dank
Quote:
Original post by davepermen
but the simultaneous detection of the actual press-event, not the holding should never be done. it should be a simple check if all are down at the same time, not if all get pressed down.


Detection of simultaneous activation of two or more buttons within the certain time window, sometimes a single frame, is crucial for some games. You can not be checking keyboard for "current state", you can only check some keyboard *buffer*, which is located on computer side, not keyboard, and what you will be checking is only what managed to arrive there by that time. I am not talking about the lag behind the real time, I am talking about the *time-window* necessary to signal multiple keys, this is different - see Donkey Kong and Street Fighter examples above.


Can you run USB trace with your keyboard and test for multiple simultaneous keys, so we can see what is the latency and bandwidth, and whether it communicates all the multiple keys in one packet, or one key at the time like mine?


no, it's not essential at ALL anywhere. and games don't rely on it, because it's impossible. the timeframes might be very low, but they are time frames, and in those timeframes all you do is check for keys, if they're down.

and no, i won't run an usb trace. because you look for the wrong thing. get your code work correctly in YOUR setup. get rid of your believe that latency will be such a big issue, and focus on getting your code to react correctly on stuff.

Share this post


Link to post
Share on other sites
Quote:
Original post by dank
Quote:
Original post by Kylotan
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.


My USB keyboard is indeed an odd one, it's from old iMac. But still, am I in minority or majority? -- Would you mind doing USB trace test for simultaneous multiple input on your keyboard?

What do you hope to learn from this?

If you're worried about it working for as big an audience as possible, you have to conform to the pessimistic situation, which you already know about. One more data point from me is not going to change an objective fact.

Given that your system already performs worse than what the standard protocol allows, and that the USB protocol allows device developers to specify their own improved protocols, it would seem fair to say that the bottleneck exists wherever each manufacturer decided it would.

Share this post


Link to post
Share on other sites
Quote:

...and no, i won't run an usb trace. because you look for the wrong thing. get your code work correctly in YOUR setup. get rid of your believe that latency will be such a big issue, and focus on getting your code to react correctly on stuff.


I tested it, I measured it. I told you numerical facts about my particular keyboard, it is not my "belief" but matter of mathematics that points there indeed is the problem. I'm sorry you do not understand, but I think I explained it enough and you did not address any of that. -- It is you who believes your USB keyboard is "fast enough" while having no idea how fast it actually is, and you're blatantly ignorant to test it?! That's not even 'belief', that's "blind fate".

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
What do you hope to learn from this?


Actual real-world numbers, as opposed to opinions.

Quote:

If you're worried about it working for as big an audience as possible, you have to conform to the pessimistic situation, which you already know about. One more data point from me is not going to change an objective fact.


What is "objective" fact? Where did you get those numbers? The most objective fact is if you would tell me what the USB trace says about your keyboard.

Quote:

Given that your system already performs worse than what the standard protocol allows, and that the USB protocol allows device developers to specify their own improved protocols, it would seem fair to say that the bottleneck exists wherever each manufacturer decided it would.


And what if your keyboard performs just the same as mine?

What if everyone's USB keyboard performs just the same as mine?


What are you basing your opinions on if you do not know any numbers nor you have ever tested any of these keyboards?

Share this post


Link to post
Share on other sites
dank, you really should spend a bit more time reading what people actually said, understanding it and then thinking more about the implications of what was said.

Share this post


Link to post
Share on other sites
Quote:
Original post by dank
I tested it, I measured it. I told you numerical facts about my particular keyboard, it is not my "belief" but matter of mathematics that points there indeed is the problem.


I tried the sniffer, then realized my keyboard isn't USB. I still use an ancient cherry keyboard some 15 years old, with adapter from AT to PS2. It's true what they say, they don't make them like they used to. It has outlived all of those Microsoft and Logitech high tech keyboards.


One detail on keypresses though. Data is sent serially. But detection is done instantly on the keyboard itself. It is perfectly possible to press multiple keys at same time. But as mentioned before, depending on keyboard, which keys can be pressed at same time depends on how signals are read. Whether a keyboard buffers or sends each keypress instantly and individually depends on hardware.

As for actual wire protocol (pdf), around page 60.

Ctrl,shift and alt are sent encoded as bitmasks (4+4, left and right keys). The rest is 6 bytes for other keys. It's up to keyboard to determine how many to send per packet.

The details say the following:
- keyboard *may* buffer, meaning it is not required to send multiple keys inside same packet
- order of keycodes inside same packet doesn't matter
- Pages 68/69 then have keyboard configuration, which is where packet sizes, polling rates and similar are negotiated. Examining that might prove useful

One thing I'm not inclined to examine right now is how individual characters are encoded, but given that configuration allows code page to be set, it is likely that one byte is enough (104 keys typically). That would mean that host needs to translate raw keyboard input into something OS accepts.


As for communication, USB 1.1 had a max of 12Mbits/sec, which would in theory mean 187,000 keyboard packets per second. Not sure what actual bandwidth used by keyboards is. Seems there is also low-speed mode at 1.5Mb/sec, which is still plenty fast.

Also relevent, USB bus multiplexes different devices, where each device is given a 1ms or 0.125ms frame. So the polling resolution is limited by that and latency will get progressively worse as multiple devices share same bus.

Share this post


Link to post
Share on other sites
Quote:

As for actual wire protocol (pdf), around page 60.

Ctrl,shift and alt are sent encoded as bitmasks (4+4, left and right keys). The rest is 6 bytes for other keys. It's up to keyboard to determine how many to send per packet.

The details say the following:
- keyboard *may* buffer, meaning it is not required to send multiple keys inside same packet
- order of keycodes inside same packet doesn't matter
- Pages 68/69 then have keyboard configuration, which is where packet sizes, polling rates and similar are negotiated. Examining that might prove useful


Yes, thank you. I did examine all that, it does not contain the answer.


Quote:

As for communication, USB 1.1 had a max of 12Mbits/sec, which would in theory mean 187,000 keyboard packets per second. Not sure what actual bandwidth used by keyboards is. Seems there is also low-speed mode at 1.5Mb/sec, which is still plenty fast.

Also relevent, USB bus multiplexes different devices, where each device is given a 1ms or 0.125ms frame. So the polling resolution is limited by that and latency will get progressively worse as multiple devices share same bus.


Yes, USB does have sufficient capabilities, for other USB devices, but the bottleneck here depends only on two numbers that are Keyboard/OS specific:

1.) number of packets per second (polling rate)
2.) number of maximum keys reported per packet

My computer has polling rate of 125Hz and my keyboard signals maximum of one state change (one key) per packet, for some reason, that's 125 inputs per second, that's all there is to it. -- Therefore, the only way "your" USB keyboard can perform better than mine is if you hacked default polling rate of Windows, or if it can send multiple keys in one packet.


If only two-three people came out saying their USB keyboard can report multiple keys per one packet, then this discussion would be "solved", as far as I'm concerned, that's all I want to know. Though, I'm afraid the chances are everyone's USB keyboard sucks at least as much as mine, who knows?

Share this post


Link to post
Share on other sites
Quote:
Original post by dank
Quote:
Original post by Kylotan
What do you hope to learn from this?


Actual real-world numbers, as opposed to opinions.

You've not been given opinions. You've been given specifications.

Quote:
Quote:

Given that your system already performs worse than what the standard protocol allows, and that the USB protocol allows device developers to specify their own improved protocols, it would seem fair to say that the bottleneck exists wherever each manufacturer decided it would.


And what if your keyboard performs just the same as mine?

What if everyone's USB keyboard performs just the same as mine?

You are not going to get everybody's test results. Even if 20 people posted here and gave you exactly the same results, it wouldn't prove anything.

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

There is no "exact" place. Us posting our data wouldn't prove or disprove that. The protocol states that 6 keys can be sent at once - that's from a specification, which you asked for. Maybe on your hardware, some hardware, or all hardware, that isn't the case. But you're not going to prove that one way or the other by having us to post our results. Nor is there any evidence that what you're asking for is at all useful.

Share this post


Link to post
Share on other sites

This topic is 2629 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.
Sign in to follow this