Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
2  
Wonder if the same thing is true for USB mice. Mine certainly seems so after switching the interface (but not the mouse itself) a few months ago. –  martineau Aug 1 '12 at 20:58
    
If it,s true for the keyboard, it's most probably the same for mice; but probably less important since there is no emergency keystrokes for the mouse –  PPC Aug 1 '12 at 21:01
    
I don't think this is something sensible to be concerned about. If you did this, and the keyboard stuck, then the network interfaces would be starved and you couldn't control the system remotely. It seems like you're just trading one problem for another. –  David Schwartz Aug 1 '12 at 22:06
1  
@DavidSchwartz : It's mostly a theoretical question, and taken from a computer architect point of view. Still, there is one application from a user's PoV: "my computer is stuck, doesn't respond to Ctrl-Alt-Backspace: should I look for a PS2 keyboard or forget it and hard-reboot" –  PPC Aug 1 '12 at 22:12
2  
@PPC: Ctl-alt-del likely wouldn't work anyway. The reboot process is controlled by high-level software which shuts down programs, flushes caches, and so on. With an interrupt storm, high-level software won't work. –  David Schwartz Aug 1 '12 at 23:30

2 Answers 2

up vote 13 down vote accepted

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:

enter image description here

share|improve this answer
    
I'm not that much into speed than priority: I understand that a longer data path can cause my keystroke to wait; but I'm thinking about "chances that the keystroke would be lost on a faulty system", which I think does not depend on the path length. –  PPC Aug 1 '12 at 21:56
    
How can the IRQ be processed in software BEFORE hitting the CPU? Do APICs have their own processors? With their routines in central memory? Do they 'borrow' CPU time? –  PPC Aug 1 '12 at 21:58
    
> "chances that the keystroke would be lost on a faulty system" It depends on the fault, but yes, obviously a USB keyboard has a much higher chance of losing keystrokes due to the extra complexity. > Re: APICs Yes, they have a a processor that does some level of processing, just like the keyboard controller has a processor, video-cards have GPUs, etc. Most hardware has some sort of chip that handles some processing. –  Synetech Aug 1 '12 at 22:28
    
> How can the IRQ be processed in software BEFORE hitting the CPU? Not only does a USB keyboard have its drivers, but the USB controller has drivers too. The keyboard data doesn’t go straight to the CPU, instead it makes its way through the keyboard to the USB controller, to its driver, to the keyboard drive, then to the CPU or other software as needed, so some things like Ctrl+Alt+Del don’t work via a hardware line but are rather processed through software. –  Synetech Aug 1 '12 at 22:29
    
So, if I get you well the basic dataflow of my keystroke would be: USB controller, APIC, CPU In through Low-pri IRQ, USB ISR/IST, CPU self-generated IRQ (like a TRAP), keyboard ISR/IST? This way, the relevant priority is that of the USB controller..? In my question I thought that the USB controller could translate the USB packet(s) to real keyboard IRQ. –  PPC Aug 1 '12 at 22:35

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.

share|improve this answer
    
The application I'm targetting is the window manager (easy case) or the OS itself. I expect my CPU to drop its USB-like-IRQL processing to cleanly receive my sync-disks-before-I-reboot-you –  PPC Aug 1 '12 at 22:46
    
>> Does this .. mean that USB kbds are less responsive: could you detail your 'no' answer? –  PPC Aug 1 '12 at 22:48
    
@PPC if you design a device driver, then USB kbds could possibly be slower for nano- to micro- seconds. If you are interested in any user-level code, then the code remains blocked when any IRQL of level > 1 is being handled. So it doesn't matter if kbd IRQL equals to highest IRQL or medium IRQL. User code is blocked. –  oleksii Aug 1 '12 at 22:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.