simultaneous copy to multiple media

[Heiko Wundram]

Am Sonntag, 20. März 2005 23:16 schrieb Claudio Grondi:
> 2) if I understand it right, an USB controller is connected to
> to the PCI bus and there can be many separate USB
> controller on one PC

Yes, there may be more than one USB-controller in a PC, but this doesn't 
matter, they are all connected to the same bus (the PCI bus). This is a 
parallel bus, but also a bus which can only serve a single endpoint at a 
time. The frequency is normally 66 Mhz, so you get a theoretical 66*32 Mb/s 
over the PCI bus.

But, this is only theoretical usage. Consider the EIDE-controller trying to 
write data into DMA memory which it has read from disk. It has to do the 
following to communicate with memory:

1) signal the DMA chip (which is also a device on the PCI bus) that it has 
data. This implies grabbing the PCI bus, making sure noone else is talking at 
the moment.

2) pass the data, 32 bit at a time, to the DMA chip, which places this data 
into main memory.

3) you may not grab the bus too long, as other devices might also want to 
communicate with some other device (e.g. the PIC, to signal an interrupt to 
the CPU). Thus, you have to free the bus after some time, and you have to 
forcibly give free the bus when some other device signals an interrupt. This 
also means starting transmission again after the bus has been successfully 
reacquired.

4) finally, after communication with the DMA-chip is done, signal the PIC via 
an interrupt that you wish the CPU to be signaled that it should do a 
software interrupt, so that the OS interrupt handler can be scheduled and can 
take the data from the DMA region (and do something with it).

Now, even when the bus is fast, setting it up all still takes time, so you 
never get the theoretical throughput you might wish to see.

Accessing the USB controller does the game the other way around; the OS uses 
the DMA-chip to stream the data onto the PCI bus for the controller to 
transmit.

So, overall, adding more USB controllers to your PC only adds extra throughput 
until you reach the top limit of PCI (when the controllers start stealing 
bandwith from each other).

> 3) the theoreticall speed of USB (430 MByte/s?) is much
> higher as the experienced 15 MByte/s, probably due to slow
> controller on the side of the external storage media, so
> maybe even on one USB line I will have the chance to
> use it full capacity connecting many slow devices
> (I can't imagine, that USB goes down with the speed to
> the speed of the slowest component connected, does it?)

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.

> 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.

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.

For example, Ethernet takes another way. Ethernet simply says: when I have 
data which is transmitted while someone else was talking, throw away the 
resulting mess (a collision, remember those cool blinking lights on hubs?). 
Someone will retransmit it if it was important.

> 5) watching the low CPU usage while writing to USB
> shows me, that CPU-time is not a problem.

No, it most certainly isn't. That's why modern computers always use a DMA-chip 
to do the heavy work of dealing with the hardware on external busses... ;)

> P.S. Your message appears in my Outlook Express
> as one having no content, but an attachment, so I can't
> read it directly.

Err, that's pretty strange. I can read my KMail written emails in pretty much 
any client that I have access to... So I guess this is a problem with Outlook 
Express not understanding MIME correctly, and not a problem on my side... ;) 
And, don't worry, I won't switch to <windows sucks>-mode now. ;)

-- 
--- Heiko.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20050321/8e0134de/attachment.sig>