Computer architecture: Are USB keyboards less responsive due to narrow IRQ range?

Question

Here is a statement I just thought of. Can anyone tell me whether, and why, it is true?

Statement: Because USB keyboards rely on a USB generic driver and architecture that has only access to lower IRQ level(s), it cannot give the keyboard access to an IRQ as priority-high as another (say PS2) controller would.

Does this (if it is true) mean that USB keyboards would have lower priority (in terms of availability more than speed) than keyboards plugged onto another port type (like PS2)?

Take for instance a USB keyboard mapped to a medium priority IRQ, on a faulty system that is stuck on another medium priority interrupt routine. Due to its relatively equal priority, keyboard events would be ignored and you won't be able to send Ctrl-Alt-del or any other emergency keystroke. If the keyboard had a higher priority, the system could enter the keystroke Interrupt routine.

Or does the USB controller have enough IRQ range (be it continuous priority-wise or not) for it to give your keyboard the priority it needs (basically just below power failure)?

And what about virtual keyboards, mapped through network connection on a remote desktop session?

EDIT: My question is not much about speed (see comments): the main question is: does a PS2 keyboard have more chances to speak to a CPU that is stuck somewhere on an interrupt priority higher than USB and lower than keyboard?

Answer 1

It’s not about IRQ range, it’s about three main factors:

1. Amount of bus crowding
2. Amount of data
3. Length of data path

In the past, keyboards and mice would have a dedicated IRQ (IRQ1 for keyboards, IRQ12 for PS/2 mice).

This meant that when a key was pressed, it had an almost direct line to the CPU (via the PIC; but still, only one jump away). This allowed for keyboard events to be processed very fast in hardware, particularly since it had IRQ1. (Of course this is all about normal keyboard usage and ignores the reset line that goes from the keyboard controller directly to the CPU.)

USB devices on the other hand all share the same bus and the USB controller’s IRQ (which is usually one of the IRQ-steering ones that is shared with other devices like NICs, video-cards and such). As such, with a USB keyboard, events go from the keyboard controller, through the USB bus into the USB host controller, from there, to the secondary PIC, then to the master PIC, then to either the drivers in the OS or the BIOS, then onto the CPU. Moreover, there is error-checking data added to data transferred over USB.

In other words, there is simply more going on with a USB keyboard than with an AT or PS/2 keyboard. The data path is longer and there is more data, and it may even have to go through software. Even though the USB bandwidth is sufficiently large, having other devices on the same port causes collisions and delays (you can add a hub, but all ports on it are still the same port on the controller). So there is a lot more waiting going on.

In addition, having its own (IRQ meant that an older keyboard could interrupt the CPU’s processing whenever it needed to. With USB, the keyboard has no such mechanism and can only send some data and wait/hope for the USB controller to interrupt the CPU at some point.

Virtual keyboards are even worse because they definitely go through software which of course cannot compete with a hardware line.

Here is a simple visualization of the difference between an AT or PS/2 keyboard and a USB keyboard:

Answer 2

Short answer

Both keyboards would perform absolutely equally for the user-level code. There might be small differences (nano- to micro- seconds on a modern PC) if you write device drivers. If the system hangs, both keyboards wouldn't solve the problem. Go for hard reboot.

---

Long answer TL;DR;

What is an interrupt?

When hardware (or some critical piece of OS internal software, like kernel) requires a processor service it fires up a message or an interrupt, which requests the processor to postpone whatever it is doing, and handle this request.

How it works?

When hardware generates an interrupt (e.g. a key press), this request goes into an interrupt controller. Controller then immediately interrupts CPU on a single line of its machine code (CPU still executes this last line). Once processor is ready to service this request, it asks an interrupt controller for an Interrupt Request (IRQ) and a handling routine. Interrupt controller has an internal data structure - Interrupt Dispatch Table that contains a pointer to a routine that is supposed to be executed by the CPU for a particular IRQ.

All different interrupts correspond to well-defined limited Interrupt Request Level (IRQL). For example on x86 systems there are 32 IRQLs, and on x64 and IA64 there are actually fewer - 16 IRQLs. Clearly, that there are more hardware devices and software services than IRQLs which means all some system objects will share IRQLs.

IRQLs table for x64

    IRQL  |    Description
--------------------------------------------
    15    |    High/Profile
    14    |    Interprocessor interrupt/Power
    13    |    Clock
    12    |    Sync
    11    |    Device N
    ..    |    ...
     3    |    Device 1
     2    |    Dispatch/DPC
     1    |    APC
     0    |    Passive/Low

Higher IRQL (with larger number) have higher priority. All components of a system try to keep the current IRQL of a processor on the lowest possible level - 0. If a higher level interrupt occurs, then current IRQL level of a processor is raised and the interrupts with lower level will not be handled up until all interrupts with higher levels are resolved. IRQ can be batch-handled if IRQ scheduler is able to queue several IRQs of the same level for processor execution.

What is the point?

This all has been really well designed to separate end-user from the complexities of hardware and make a universal architecture that can work with many types of the hardware/software.

1. User-level code (i.e. not kernel-level) is only executed when processor is at the Passive/Low (0) IRQL. Point is, you can only handle a key-pressed event in your application after all IRQLs have been handled. Therefore, for a keyboard it doesn't matter what IRQL is assigned to the hardware interrupt.

2. IRQL are only OS abstractions and are not set in stone. Corresponding IRQ and IRQL are stored in Windows registry (for example), and any enthusiastic user can change them manually.

Conclusions

Quotes from the question

Because USB keyboards rely on a USB generic driver and architecture that has only access to a few IRQ channels, it cannot give the keyboard access to an IRQ as priority-high as another (say PS2) controller would.

Perhaps the author meant lower IRQL instead of the fewer IRQ channels. Anyways, it doesn't really matter as it is not visible to the user on any modern PC. The possible differences are of the nano- to micro- seconds level and they only happen at the kernel level. In both cases user-level code is blocked by the OS kernel.

Does this (if it is true) mean that USB keyboards would be less responsive than keyboards plugged onto another port type?

It is not true because of the way OS designed. If OS is busy with something and is "slow", both keyboards would behave identically.

Take for instance a USB keyboard mapped to a medium priority IRQ, on a faulty system that is stuck on another medium priority interrupt routine

In this case the system will BSOD, IRQ handling routines must be designed up to a certain standard (such as they must be fast, synchronous, non-blocking so on). Any deviation from this and the kernel will BSOD.

Due to its relatively equal priority, keyboard events would be ignored and you won't be able to send Ctrl-Alt-del or any other emergency keystroke.

If the system hangs there are lots of things that can go wrong, but most likely the keystroke IRQL will be handled at the driver level. The problem is, it will not be delivered to the application that subscribed for such notification, as OS is busy doing something else.