Hacker News Reader

Comment by joshspankit | Hacker News Reader

I might even argue that it’s a worse problem.

A kid who asks you 1000 times a second whether you are there yet is going to know within 1ms of when you get there, but I imagine we’d all like being the driver much more if there were no “are we there yet”s and all the kid needed was one “We’re here” exactly when you arrive.

View on HN

There is in fact an interrupt mechanism for input devices - the host sends a request with a long timeout and the device responds to the outstanding request when it has something exciting to report, or when the timeout is about to expire. This is used frequently in low input rate devices like keyboards. Gaming mice use a high polling rate because it saves you the effort of keeping track of outstanding requests - you just report your current state immediately on every request, and the driver end can decide how often to ask you.

I may need to update my knowledge (I hope I do if you’re right), but from my understanding USB is a CPU-emulated protocol, which is to say there are no pins for “mouse button”, and the CPU has to do some “figuring out what this data means” work for each input event. Then, all this is done on a multitasking CPU that may or may not prioritize the interpretation and processing of that input.

That all being true, having a publish/subscribe model is still not the same as having a true interrupt (and I’d have to do some digging to figure out whether there wasn’t still polling somewhere in the pub/sub pipeline)

While this is intuitively obvious, it doesn't really always play out that way in practice since interrupts can be expensive to handle. For example polled IO can be significantly lower latency than waiting for interrupts.

You’ve piqued my curiosity. Please explain.

Essentially you're spinning waiting for the event that you know must come. Your latency will be on the order of a few clock cycles. Whereas if you use interrupts you are always at least a state-save and state-restore underway before you can service the next event, and likely a lot more than that.

The difference is real time control of stepper motors with crazy speeds when microstepping at 300K steps / second or more interpolating across 5 axis vs moving them at a snails pace of maybe 10K steps / second (on really nice and otherwise idle hardware, miss a single step and your goose is cooked, now you have a cumulative error).

I thought I'd seen a rather dramatic benchmark of this but I can't find it now. (I think it was in the context of io_uring, whose documentation mentions that polled IO is much lower latency and I'd trust Jens Axeboe on that one.)

This intuitively makes sense especially with SSDs and especially with NVMe SSDs: you're not going to have to wait that long, especially compared to the overhead of an interrupt. Also, if you're reading sequentially, once you get one I/O completion you're going to get a lot more in a short timeframe—it makes sense to just poll for those instead of handling every one as an interrupt. Interrupts are pretty expensive (I honestly don't have a good grasp of how Linux interrupt handling works but it can easily be on the order of microseconds.)

It also has some side benefits like preventing the CPU from going into a lower power state for only a short period of time.

As I understand it, USB2 drivers don’t actually poll — the host controller chip polls the mouse. On USB3, there’s a real interrupt mechanism.

Reply on news.ycombinator.com