On Sat, Jul 11, 2009 at 12:06 PM, Markus Rechberger<mrechberger@xxxxxxxxx> wrote: snip >> 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. > Hi Markus, Yes, and YOU can improve it with the current devio.c. Especially on an Atom, which is a very high performance processor, (compared to other embedded processors). And now that it is getting difficult to buy memory sticks less than 1Gig, the buffer limit should not exist. Just double or quadruple the number of usbdevfs urbs you use. I have run at 24.5 Mbyte per second for days. The amount of data transfered at that rate is astonishing, try to give yourself a few tenths of a second of data on the fly. However, in modern systems, there are not huge kernel delays reading such things as legacy floppies or CD drives which could cause really long lags. If you are not able to buffer enough to keep up with the data, well, you cannot. Buffers, like caches, only even out demand, they cannot defeat a long term inability to keep up with data. The reason that I think the max size usbdevfs urbs should be increased is to decrease the number of usbdevfs ioctls required. That is a minor processing load (except on slow processors), which decreases the start up race with iso xfers, but the limit is arbitrary and unexpected. I would bet most developers would be surprised at the "small" limit for high bandwidth, high speed devices. Why would the limit be one ms of transfer per usbfs urb? I am sure the original developers were trying to limit the number of "large" kmalloc requests which can also be a problem in small embedded systems. The thing is, devio knows everything about maxpacketsizes and the interval, so it can know how to split a "huge" transfer (into a real usb urb), and so could do multiple iso urb mallocs in the preferred <4k size, or more practical for highbandwidth <32k size, bigger kmalloc sizes would be less wasteful. I don't know the real issues for kernal malloc sizes, whether multiple small kmallocs are better (with more waste), or better fit, bigger mallocs. The ultimate solution (especially with usb 3.0 on the horizon) is to implement zero copy transfers from user space. I am sure this will be coming up soon. 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
