Why is not USB interrupt-driven?

Question

What's the rationale behind making USB a polling mechanism rather than interrupt-driven? The answers I can come up with some reasoning are:

• Leave control of processing efficiency and granularity to OS, rather than the device itself.
• Prevent "interrupt storms" by faulty devices.

Some explanations on the net that I found say that it's mostly because of the nature of USB devices. They are mostly microcontroller-based systems which cannot queue larger transfers therefore require short interrupt intervals and such short interrupt intervals may not be the most efficient. Is that true?

Could there be other reasons?

Solution 1

The overarching premise of the development of USB was, "cheap chips". This was done, through the use of polling, which reduces the need for a higher arbitration protocol.

Firewire, which did allow for interrupts from the devices and even DMA, was much more expensive. So USB won in the low-cost field, and firewire in low-latency/low-overhead/... field. Due to history USB more or less won.

Solution 2

What's the rationale behind making USB a polling mechanism rather than interrupt-driven?

This seems to be anti-USB FUD (as in Fear-Uncertainy-Doubt).

The reason is that this simplifies things on the harware level quite a bit - no more collisions for example. USB is half-duplex to reducex the amount of wires in the cable, so only one can talk anyway.

While USB uses polling on the wire, once you use it in software you will notice that you have interrupts in USB. The only issue is a slight increase in latency - neglible in most use cases. Since the polling is usually realized in hardware IIRC, software only gets notified if there is new data.

On the software level, there are so-called "interrupt endpoints" - and guess what, every HID device uses them: Mice, Keyboard and Josticks are HID.

Solution 3

There are three ways to avoid data transfer collisions on a bus:

1. Have a somewhat complex bus management protocol. Such a protocol has to be rather sophisticated, as when too simple, it will make the bus rather slow (see Token Ring, which is rather simple, yet inefficient). However, having a sophisticated protocol makes all components expensive as all of them require management logic and need to understand of how the bus actually works (see Firewire).

2. Don't avoid them at all, allow them but detect and handle them. This is also somewhat complex and the bus cannot guarantee any speed or latency as if there are constantly collisions, throughput will fall and latency will raise (see Ethernet without switches, see WiFi).

3. Have one bus master that controls who can use the bus at which time and for how long. This is inexpensive, as only the master must be sophisticated and the master can give any possible guarantee regarding speed or latency.

And (3) is how USB works and not even the master USB chips need to be sophisticated as the master is usually a computer with a fast CPU and can perform all bus management in software.

USB device chips are dump as toast. They don't need to understand the nifty details of the bus. They just have to look for packets addressed to them which are either control packets, e.g. requesting meta data or selecting a configuration, data packets sent by the master, or poll requests from the master saying "if you have something to send, the bus is now yours".

To make sure the master polls them on time, they hand out a simple description table on request, that explains which endpoints they offer, how often those need to be polled, and how much data they will at most transfer when being polled. The master can use that information to build up a poll schedule that ensures that all devices are polled on time and get the bus for long enough to allow their maximum transfer size. Of course, this is not possible under all circumstances. If you connect too many devices that require very frequent polling and always want to send a lot of data, your system may refuse to add a new device with the error, that its poll requirements cannot be satisfied anymore. Yet that situation is rare in practice and USB is limited to 127 devices (hubs count as devices, so does the master itself).

Power management works in a similar way. Every device tells the master how much power it needs and the master ensures that the bus can still deliver that much, taking active hubs into account. If you connect another device and the bus cannot power it anymore, adding the device will fail with an error.

This allows a fairly complex, powerful, and fast bus system, yet with components that don't even need a real CPU. The simplest USB chips out there are just bridges to a serial data line (like an internal RS-232 bus or an I2C bus) and there is nothing really configurable and they cannot run software or have a firmware one could update. They just place incoming data packets into a buffer and then sent the buffer content bit for bit over the serial bus and they receive serial data in another buffer and return the buffer content when being polled. As for telling the master the configuration (including device and vendor IDs, as well as human readable strings), they simply send the content of a small external EPROM. Things cannot get much simpler than that yet such a chip is enough to build plenty of USB hardware already.

Comments

[Sedat Kapanoglu]

Is USB being half-duplex relevant to polling mechanism decision or is it one of the other aspects of USB design?

[Sedat Kapanoglu]

About anti-usb part: I just have that programmer itch about various inefficiencies of a polling system compared to interrupt driven, and I'm trying to find out the reasons behind these decisions.

[Sedat Kapanoglu]

Cost! Yes, that makes perfect sense.

[amby]

The polling increases the latency. Especially when several devices coexist on the same bus, because the PC has to poll the devices, in case they have something to deliver. Due to this, many audio devices prefer to use firewire. Everything has its pros and cons.

[Daniel Santos]

@Turbo J "This seems to be anti-USB FUD" -- Wow. How amazingly ironic. MS getting a small dose of their own medicine.

[John Chadwick]

@Daniel Santos Not to go too far off-topic, but if you pay attention, you'll actually find there is a lot of FUD going in every direction. MS has dealt with a ton of unfair criticism, although I don't know how USB actually has anything to do with Microsoft.

[Daniel Santos]

@John Chadwick hehe, they were the primary architects :) Haven't you noticed all of the god-awful Hungarian notation in the field names of the spec? idVendor, bLength, etc. Also, I think most people would be surprised how little CPU is consumed after accounting for DMA & the USB host controller carrying most of the load. The act of distributing peripherals (like USB types of devices) beyond the main board always presents many challenges (cabling, EMI, latency, etc.) and USB has obviously proven its self to be a good fit for most circumstances.

[John Chadwick]

@Daniel Santos Oh, that would explain it - I did notice that, in fact. Though, my primary source of dealing with USB code actually comes from Linux kernel code, where the USB structure names were normalized into more traditional C-style names.

[Daniel Santos]

@John Chadwick not in include/uapi/linux/usb/ch9.h :( But it's good not to deviate from the USB spec here IMHO.