Hi Alan. The machine has only two cameras inserted (no hids, nothing else). While the cameras have an interrupt endpoint, I disabled it in uvc_video. Still I don't get more than two cameras into the schedule. So there are no interrupt endpoints besides the one used for the internal hubs. They are 2 and their schedule is 4bytes per 256ms. Hardly a large load.
With the interrupt endpoints on the camera, usage was 98%, now it's 93% with them disabled. T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc=744/800 us (93%), #Int= 2, #Iso= 10 The only reason I can come up with to make this happen is that the driver does not send 3 packets per microframe worth of isoc-data or that the scheduler does not account for that capacity, ie only 8 microframes * 1024 bytes. Something along that path. Or the scheduler is really, really broken. :) That would probably give me 80%+ usage when it should not be more than 30-35%. Searching the net for it yields approx. the same information. People are lucky to be able to run two cameras with Linux. Regards, Christian ________________________________________ From: Alan Stern [st...@rowland.harvard.edu] Sent: Wednesday, 03 September 2014 6:16 PM To: Christian Melki Cc: linux-usb@vger.kernel.org Subject: Re: EHCI Isochronous schedule full? On Wed, 3 Sep 2014, Christian Melki wrote: > I've probably got this wrong... > > I try to run several cameras with compressed streams (MJPEG) using maxpacket > 3*1024 isoc-endpoints. > EHCI should be able to transmit 8 microframes * 1024 bytes * 3 packets of > data per frame (approx 24MB/sec). > Two cameras work fine, but when I connect a third camera I get -ENOSPC from > the scheduler. > I don't get how the schedule can be full. One camera should be able to fit > within one microframe. (3 * 1024b). > That leaves atleast 7 microframes available if 100% of bandwith is used for > isochronous transfers (not likely, but anyway). > > Debugfs lists the periodic schedule as (two cameras connected): > > /sys/kernel/debug/usb/ehci/fsl-ehci.0 cat periodic > size = 512 > 1: qh256-0001/c3b0bd40 (h2 ep1in [1/0] q1 p1) > 6: qh16-0001/c301d080 (h7 ep3in [1/0] q1 p8) > 7: qh256-0001/c3b72180 (h8 ep1in [1/0] q1 p1) > 9: qh16-0001/c30dd100 (h10 ep7in [1/0] q1 p16) > 22: qh16-0001/c301d080 > 25: qh16-0001/c30dd100 > 38: qh16-0001/c301d080 > 41: qh16-0001/c30dd100 > 54: qh16-0001/c301d080 > 57: qh16-0001/c30dd100 > 70: qh16-0001/c301d080 > 73: qh16-0001/c30dd100 > 86: qh16-0001/c301d080 > 89: qh16-0001/c30dd100 > 102: qh16-0001/c301d080 > 105: qh16-0001/c30dd100 > 118: qh16-0001/c301d080 > 121: qh16-0001/c30dd100 > 134: qh16-0001/c301d080 > 137: qh16-0001/c30dd100 > 150: qh16-0001/c301d080 > 153: qh16-0001/c30dd100 > 166: qh16-0001/c301d080 > 169: qh16-0001/c30dd100 > 182: qh16-0001/c301d080 > 185: qh16-0001/c30dd100 > 198: qh16-0001/c301d080 > 201: qh16-0001/c30dd100 > 214: qh16-0001/c301d080 > 217: qh16-0001/c30dd100 > 230: qh16-0001/c301d080 > 233: qh16-0001/c30dd100 > 246: qh16-0001/c301d080 > 249: qh16-0001/c30dd100 > 257: qh256-0001/c3b0bd40 > 262: qh16-0001/c301d080 > 263: qh256-0001/c3b72180 > 265: qh16-0001/c30dd100 > 278: qh16-0001/c301d080 > 281: qh16-0001/c30dd100 > 294: qh16-0001/c301d080 > 297: qh16-0001/c30dd100 > 310: qh16-0001/c301d080 > 313: qh16-0001/c30dd100 > 326: qh16-0001/c301d080 > 329: qh16-0001/c30dd100 > 342: qh16-0001/c301d080 > 345: qh16-0001/c30dd100 > 358: qh16-0001/c301d080 > 361: qh16-0001/c30dd100 > 374: qh16-0001/c301d080 > 377: qh16-0001/c30dd100 > 390: qh16-0001/c301d080 > 393: qh16-0001/c30dd100 > 406: qh16-0001/c301d080 > 409: qh16-0001/c30dd100 > 422: qh16-0001/c301d080 > 425: qh16-0001/c30dd100 > 438: qh16-0001/c301d080 > 441: qh16-0001/c30dd100 > 453: itd/c32901e0 itd/c3290500 > 454: itd/c33c1d20 itd/c20ec000 qh16-0001/c301d080 > 455: itd/c20eca00 itd/c20d5320 > 456: itd/c32d08c0 itd/c32d05a0 > 457: itd/c20e83c0 itd/c20e86e0 qh16-0001/c30dd100 > 458: itd/c20e8460 itd/c20e8780 > 459: itd/c20ecaa0 itd/c20ec6e0 > 460: itd/c33c16e0 itd/c20ece60 > 461: itd/c33c1aa0 itd/c20ec140 > 462: itd/c21eaaa0 itd/c21eadc0 > 463: itd/c32900a0 itd/c32903c0 > 464: itd/c33c1960 itd/c20ecf00 > 465: itd/c3155dc0 itd/c3155aa0 > 466: itd/c20ec320 itd/c33cc0a0 > 467: itd/c3155c80 itd/c3155960 > 468: itd/c3155e60 itd/c3155b40 > 469: itd/c21ea1e0 itd/c21ea500 > 470: itd/c20ec780 itd/c33c1780 qh16-0001/c301d080 > 471: itd/c21eabe0 itd/c21ea8c0 > 472: itd/c21ea140 itd/c21ea460 > 473: qh16-0001/c30dd100 > 486: qh16-0001/c301d080 > 489: qh16-0001/c30dd100 > 502: qh16-0001/c301d080 > 505: qh16-0001/c30dd100 > > which is ~90 entries out of the 512 uframe schedule size. So why do I get > -ENOSPC? This is probably a result of the interrupt transfers using up space in the schedule. If you can get rid of them (by unplugging the devices that require them, or plugging the devices into a different USB bus), leaving only the isochronous transfers, it's likely to work better. The scheduling algorithm in ehci-hcd is not sophisticated and it does not make optimal use of the available bandwidth. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
