the USB-IDE bridge was at least part of the bottleneck here. Writes are less problematic -- you just dump the data in bulk OUT packets and the bridge writes to IDE whatever it can whenever it can.
At high speed there's a PING protocol too ... basically the device can let the host know when a buffer is available for the OUT data (512 bytes), so bus bandwidth isn't wasted sending data that would get NAKed and later resent.
I agree it's quite likely that the USB-IDE bridge is part of the
bottleneck. But USB itself shouldn't be that much of a limiting factor. The raw speed of the bus is around 60 MB/sec, and even with all the
overhead you should still be able to get half that (I think) on an
unloaded system.
For BULK traffic the ceiling is 52 MB/sec. I've certainly seen individual production devices top 27 MByte/sec "hdparm -tT" on 2.5 kernels. I don't know how much overhead the USB-IDE bridges stick between IDE ("40 MB/s") and USB ("52 MB/s").
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel