On Sun, 4 Jan 2004, Axel Waggershauser wrote: > I increased FSBR_DELAY in uhci-hcd.c and ran my program again (and > expected to get a lower throughput than before, as I thought increasing > the "DELAY" value would mean to delay some action thereby reducing the > throughput,
You're almost right... Increasing the "DELAY" value means to delay a slowing-down action! So increasing it improved your throughput. > but:) I got the following results: > > with FSBR_DELAY set to (HZ / 5) I get: > > blocksize: 131072, count: 8 speed: 904.837 [kB/s] > blocksize: 262144, count: 4 speed: 927.345 [kB/s] > blocksize: 524288, count: 2 speed: 145.586 [kB/s] > > with FSBR_DELAY set to (HZ / 2) I get: > > blocksize: 131072, count: 8 speed: 899.026 [kB/s] > blocksize: 262144, count: 4 speed: 919.129 [kB/s] > blocksize: 524288, count: 2 speed: 914.129 [kB/s] > > > So it looks like the FSBR_DELAY has to be longer or about the same > duration than the URB completion takes. That's right. This is an area of the uhci-hcd driver that could stand a little improvement. In case you're interested, here's a brief, incomplete (and possibly not entirely correct) description of what FSBR_DELAY does. If an URB takes too long to complete -- longer than FSBR_DELAY -- uhci-hcd assumes it's because the device is just sending NAKs and isn't processing any data, or is only processing data very slowly. It jsut doesn't take into consideration that the URB might be a very long transfer. Anyway, when this happens the driver slows down. Instead of trying to send data as fast as possible, it only sends one packet per millisecond. It does this in an attempt to reduce the load on the system's PCI bus, rather than sending lots of packets that it thinks the device is just going to ignore. > Do I have to expect any disadvantages of this solution? Probably not. If you have no other USB devices attached, certainly not. > Why was the > FSBR_DELAY set to 50ms in the first place, is this some USB standard > definition? It isn't a standard. So far as I know, 50 ms was just a heuristic value. > Would it be wise to incorporate this patch into the official > kernel or would you still advise me to use the "double buffer URB" > technique? With better programming in the driver, the exact value of FSBR_DELAY won't matter so much. For now, I still think you should try the "double buffer URB" approach. If nothing else, you can compare the relative speeds using different buffer sizes and let us know if it works as well in practice as we expect it to :-) 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
