On Wednesday 01 August 2007, Steve Calfee wrote: > At 10:42 PM 7/16/2007, David Brownell wrote:
> >I don't recall testing high bandwidth ISO. In general, ISO support > >is pretty weak with EHCI ... Actually, now that I think of it I *did* test it, but only using the "usbtest" driver. In fact, I tested it between an EHCI host and a net2280 gadget with "gadgetfs". :) > Update, I was able to get the high bandwidth ISO to work. I thought I > would report how, for others in the future. > > When building the isoc array for submission, if it is a 2 or 3 packet > per microframe IN or OUT, I thought that I just built more standard > packets and ehci.c would know from the endpoint attributes the mult > field. Wrong. What Linux wants is to get a packet 2 or 3 times as > long as maxpacket in the length request. Yes. I suspect that should be documented somewhere. > I have not tested all 3072 > possible packet sizes, but certainly 1*3, 512*3 and 1024*3 and > several sizes in between work for 20 second burst tests of transfers. > All this from a userspace usbdevfs application! > > Linux (through usbdevfs at least) has a limitation, the max request > it will accept is less than 48K per urb - 24K works. ISTR it started out at 16KB then someone said "that's not enough". One basic problem is that you can't reliably allocate very many physically contiguous pages for your buffers. So even 24K will be dicey on some systems. > I have not tried > everything in between. This means that to get iso running without > dropouts (the whole point of iso) requires submitting lots of urbs in > parallel. I have very successfully used 8 urbs transferring 24K per > urb, but that means that the app has to reload at least every 8 ms. Nobody promised streaming to/from userspace would be a speed demon! And even in that model, 8 msec is risky ... if an IRQ or other task gets scheduled at the wrong time, you'd still get dropouts. > Probably a production app would need to use 32 or so urbs to be > guaranteed the uninterrupted isoc flow. The high bandwidth stuff > would really benefit from a zero copy usb kernel. It's basically only high bandwidth streaming that needs that; but you're right that 24 MByte/sec is a lot of memcpy(). The same effect is visible on the peripheral side. - Dave > Regards, Steve > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
