> > Also, I'd like > > to see this reduce the IRQ rate more than it does. > > Why does this reduce the IRQ rate at all? Doesn't an IRQ fire at every URB > completion in the queued chain?
With EHCI (plus patch I've not yet posted, more testing yet :) this more than halves the IRQ rate on larger transfers. I suspect that with OHCI or UHCI (much slower) it won't have much of an effect as-is. As to why it does so, remember that a given IRQ may indicate completion of any number of transfers. IRQs don't fire at the very instant transfers complete, they wait till some upcoming microframe (or frame) boundary. And the hardware doesn't even know about URBs. (In the case of EHCI, there's even the option to say which transfers should generate an interrupt on completion.) Scenario (won't happen this fast with the NEC EHCI): uframe N - queue a bunch of 4KByte transfers, 8 packets each - some packets get out in that uframe uframe N + 1 - first transfer finishes, interrupt scheduled for N+3 - second transfer executes entirely - third transfer starts uframe N + 2 - third transfer finishes - fourth transfer executes - fifth transfer starts uframe N + 3 ... triggers IRQ> - ... etc And depending on when the driver tasklet scans the schedules, it may also detect completed transfers that haven't yet triggered an interrupt... :) With EHCI the latency is tunable so interrupts can happen after 2^N (0<=N<=6) uframe delays. The current driver defaults to lowest latency, but that's settable as a module parameter and the default can of course be changed. I seem to recall OHCI also has some tunability in that respect (maybe that's wrong), but don't know about UHCI. What I want to do is have a robust way to tell EHCI not to interrupt for most of the queued transfers. It's not as simple as I'd hoped, since there's a common case where the HC has cached some transfer data that the queue append must update. If it's done that, it needs to be corrected asynchronously. (Interrupt or timer.) - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel