simultaneous copy to multiple media

Diez B. Roggisch deetsNOSPAM at web.de
Sun Mar 20 18:32:15 EST 2005


> Well, 430 MB/s is only for USB 2.0. AFAIK, most devices (esp. storage
> devices) are still only USB 1.1 compliant, which makes this rate go down
> to a mere 40 MB/s or something close.

I think it is 430 MBit(!), so about 50MB per second. The old usb 1.1 has
12MBits. So I don't think that Claudio could observe 15MByte/s with a 1.1
bus....

> 
>> 4) with 45 MByte/s I could theoretically simultaneously
>> supply three separate data streams to three USB
>> controller writing with 15 MByte/s each out to the
>> external storage media.
> 
> No, you can't. As I said in response to point 2, it doesn't matter what
> kind of bus you use, when the bus isn't meant to do real "broadcasts" or
> can actually talk to several devices simultaneously because all wires are
> duplicated a corresponding number of times, there's always overhead when
> switching between the devices.

Well, if the bus is faster, it can (and does) use multiplexing. All busses
do that, apart from crossbar switches which have n:n point2point
connectivity.
> The bus must be acquired for communication with one device (so that the
> others won't simply go blabbering over the communication), then the data
> must be streamed, then the bus released again. This process takes time,
> and AFAIK, USB is pretty expensive (compared to data transmission speed)
> here, as USB guarantees that a packet reaches the endpoint when its
> transmitted over the wire (in the sense that it won't get lost because
> someone else was also talking). Now, when more devices come into play,
> this overhead becomes significant, and takes away quite some bandwith.

USB uses a host-based bus arbitration scheme where only the controller
decides who can talk when. So there is very limited bus arbitration
overhead. But of course this also means that the host has grant each
attached device bus time every now and then, as the device itself has no
chance of signalling data availability itself. So - that adds again some
overhead :)

In the end, I'm not sure what throughoutput is actually possible. As I said
to Claudio in a private mail: Apart from multithreaded writing to the bus
and _hoping_ that things speed up one can't do much - at least not in
python, and not without deep driver fiddling or even writing drivers
oneself.
-- 
Regards,

Diez B. Roggisch



More information about the Python-list mailing list