On Fri, Jul 10, 2009 at 7:33 PM, Steve Calfee<stevecalfee@xxxxxxxxx> wrote: > On Fri, Jul 10, 2009 at 9:28 AM, Oliver Neukum<oliver@xxxxxxxxxx> wrote: >> Am Freitag, 10. Juli 2009 13:08:01 schrieb Markus Rechberger: >> >>> Yes you're right the problem is solved with newer kernels. Oliver >>> would it be possible to increase the buffer size to 200k instead of >>> 32k? 32k works for me but 200k would lower the iterations between >>> k-space/userspace for what I'm doing since the data is around 190k >>> carried by a single URB. >> >> Which size? Are you refering to the limit for iso urbs? >> In principle yes, but we have to have a limit and somebody will always >> complain. >> It would make more sense to allow submission of a list of urbs >> rather than raise the limit. >> > Hi, > > I don't see how submitting a list of usbfs urbs is any better (kernel > memory wise), than one larger urb. And I don't see how the current > limit helps, either. The kernel must malloc a bunch of memory and copy > the data to/from userspace. The problem is that high bandwidth > endpoints can use up to 1024*3*8==24,576 bytes for one millisecond of > transfer. So to do userspace high bandwidth iso requires LOTS of > usbdevfs urbs to stay ahead of system latencies. > > The actual limits in devio.c could more reasonably fit the usb spec. > ie. the max submission possible per endpoint per isopacket is 3*1024, > not 8K, and the max urb size submission should be a multiple of 24,576 > bytes, I would suggest 8 ms of data transfer allowed per usbdevfs urb, > which would put the max at 196,608 bytes per usbfs urb. > this would the the perfect size for me. > These changes don't have to be made, it is not impossible to do high > bandwidth iso from user space as things stand. I do get 21 mbyte/seconds on an Intel Atom with the 32k buffers, although it's easily to interfere the transfer and drop packets by doing something else in the system. It just seems like this can be improved. BR, Markus > It just seems the > current limits are arbitrary and don't really solve a potential kernel > memory problem caused by userspace. Iso is an inherent race between > sink and source of data, a user app needs lots of buffering to keep up > with a fast device, like a webcam. > > Regards, Steve > -- 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
