On Sat, 3 Jan 2004, Axel Waggershauser wrote: > > In addition to what Johannes has mentioned, an important factor > > is the overhead during submission of new requests. Axel didn't say > > explicitly how his test program works, but if it waits for each > > URB to complete before submitting the next URB then this could > > be an important factor. I can easily imagine it explaining the > > difference between the desktop and laptop timings. > > What I do is submit one urb, then wait for it > (wait_event_interruptible_timeout() with a complete() in the complete > handler of the urb), then queue the next urb. I can imagine that this > causes the 'low' throughput when requesting many small transfers, but I > can not see how this can explain the drop of throughput with large > transfers, since the wait-for-requeue overhead decreases continuously.
Aha. Well, a few other people have suggested mechanisms that might account for the drop in throughput with larger buffers. The point is that you shouldn't be relying on the large-buffer technique to maximize throughput. The correct approach is to set up a pipeline: submit enough URBs to account for at least 16 KB of data (whatever buffer size you use), and submit a new URB as each old one completes. This should yield the maximal throughput pretty much independent of what the buffer size is, so long as it's not too large or too small. > My old driver (2.4) did never queue an urb with a larger transfer_buffer > that 64k. If the total buffer was larger than 64k, I simply resubmitted > the urb in the complete handler with updated buffer pointer and buffer > size. I can't remember why I did that and I thought with rewriting it > for 2.6 I could make it 'proper'. Anyway, my old driver did not have > this problem and I could do the same thing with 2.6. But I would rather > help fixing it, but working around it. Just change your driver to use two URBs, each managing a 16 or 32 KB buffer. Submit both of them at first, then go round-robin. This will work even under 2.4, provided you set the appropriate flag to allow queueing of URBs. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
