RE: EHCI Isochronous schedule full?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [stern@xxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, 03 September 2014 6:16 PM
To: Christian Melki
Cc: linux-usb@xxxxxxxxxxxxxxx
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux