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.
pgp6Uj3A40bZ4.pgp
Description: PGP signature
-- http://mail.python.org/mailman/listinfo/python-list
