> 1. The problem, according to my crude user-space measurements using > gettimeofday(), is that a bulk transfer of 4096 bytes takes > approximately 70 milliseconds to complete. Does this seem > reasonable? It seems like a very long time for such a small amount > of data.
Yes it does seem rather long. 4KBytes is 64 max size packets (of 64 bytes each) which would (optimistically) fit neatly into four frames (19 packets each) with space left over ... one frame per millisecond, by definition. So you're seeing about 64 milliseconds too long, if you assume best case ... and typical case, on an unloaded USB, should be only a few frames short of best case even with a slow HC. I'll not speculate where that extra delay comes from, but I'd suspect it's outside of the USB layer (so bigger I/O sizes could give you better throughput). > 2. The windows software, according to sniffusb, is using much bigger > bulk transfer packets -- at least 64 kB. But the usbdevfs > interface specifically limits the packet size to 4096 bytes. Why > is this limit in place? Shouldn't I be able to generate bulk > transfers in larger sizes? I've also wondered where that 4KB limit comes from, it's too small to get adequate bulk throughput. And it's not even applied uniformly throughout "usbfs" (the new name for "usbdevfs" -- unrelated to "devfs"). If you wanted to experiment with bigger I/O sizes, tweak proc_bulk() in drivers/usb/devio.c to use kmalloc of the bulk transfer length to get the buffer (and kfree), with a ceiling on the order of 64K or 128K. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
