On Tue, Oct 19, 2010 at 01:25:24PM +0200, Sander Eikelenboom wrote: > Tuesday, October 19, 2010, 1:13:03 PM, you wrote: > > > Am Dienstag, 19. Oktober 2010, 11:42:09 schrieb Sander Eikelenboom: > >> I was wondering why a USB2 device connected to a USB3 host controller causes much more interrupts then the same device on a USB2 controller. > >> Probably because there isn't a seperate roothub handling the USB2 devices ? > >> > >> usb2 controller > >> idle (no application grabbing video): 30 interrupts/second > >> active (application grabbing video): 155 interrupts/second > >> > >> usb3 controller > >> idle (no application grabbing video): 20 inter/second > >> active (application grabbing video): 7830 inter/second > > > The ehci driver goes to great lengths to minimize the number of interrupts. > > What you are seeing here is likely simply one interrupt per URB. > > > Regards > > Oliver > > But it's the same application, grabbing the same videostream with the same settings from the same device, so the bandwidth used by the device should be the same for both > Would it be expected that in such a case a usb3 controller would use more interrupts/URB's to transfer the same data ? Oliver is right. The xHCI driver currently causes the hardware to generate multiple interrupts per URB. That can't be fixed on 0.96 xHCI host controllers (with the way the driver is currently built), but it can be fixed on 1.0 xHCI host controllers. There's a "Block Event Interrupt" (BEI) bit for isochronous transfer TRBs that will place an event on the event ring when the TD completes, but not generate an interrupt for it. That should cut the interrupt generation down to once per URB. 0.96 host controllers don't recognize that bit, unfortunately. The other thing you could be seeing is that the xHCI host controller generates an interrupt (once) every time the periodic endpoint ring is empty. If the kernel driver isn't keeping ahead of the hardware by submitting multiple URBs, then you'd see those extra interrupts between URBs submitted by the driver. I haven't done any performance testing with isochronous transfers yet, so it could be something else entirely, like the hardware generating spurious interrupts when an isochronous endpoint is active. What host controller are you testing on? If it's an NEC, what firmware is it? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
