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

Reply via email to