USB and Firewire bus control

[Lord Evermore]

This may be an old issue but I don't recall ever seeing anything specifically about it.

USB is a "master/slave" bus if I understand correctly. The controller is the master and the devices are slaves. Firewire is a peer to peer master bus, each device is in control of its own usage of the bus.

Does USB allow only one device to be transferring data at a time (with very fast switching between devices, such that you wouldn't know your mouse wasn't constantly communicating)? Sort of like an IDE bus, where some commands may be transferred to multiple devices, but only one can actually be active.

Does Firewire act more like SCSI where multiple devices communicate directly between each other or the host adapter at the same time, up to the limits of the bandwidth of Firewire? I know Firewire is based on SCSI protocols.

I'm just wondering how well the two busses allow for saturation with multiple devices. If USB can only allow one device to be sending actual data at a time, then the bus usage can never peak beyond the maximum usage of one device, and the time taken for two devices to simultaneously transfer a given amount of data would be equal to the time taken for each device to do it one at a time. If Firewire works the way I think, then the data could be transferred all at the same time, with the time taken would depend on the total amount of data divided by the maximum real performance of the Firewire bus and controller chips; given than no single device is able to fill the bus continuously, other devices would be sending data to fill up the remaining bandwidth so that the total time taken is less than the time for each device to transfer one at a time.

 

[LED]

I have 7 devices hooked up with USB...all of them work simutaneously together and none pause if that helps...dunno about Firewire cause I only have 1 device and won't be expanding till Firewire800 comes available

 

[Lord Evermore]

Well, an operating and applications SEEM to work all at the same time on your PC, but in fact the CPU is rapidly switching between everything that is done. I'm wondering if that's how USB2.0 works, so that it seems all the devices are working concurrently when they're not. The "pause" between device access wouldn't be long enough that you'd see it, it'd only result in a lower overall data rate for each device, and the total bus usage not going higher than the fastest device rates, and probably only be noticeable with multiple high bandwidth devices, so that there'd be a noticeable drop in transfer rates. With even two external drives, the switching may not be significant enough to notice, but with 6 or 7 it might.

 

[Eug]

I used to get a BSOD when running 2 of my USB 1.1 devices simultaneously under Windows 98. Both could be hooked up to the same hub no problem and each one worked fine if it was the only one running.

YMMV.

 

[anthrax]

linky....Firewire USB
hopes it helps.....probabaly doesn't..

Also..think with firewire, you can daisy chain devices up....you don't need a host slave relationship between the devices.. (computer/USB Keyboard)....therefore, you can connect firewire devices to one another with out a PC being involed....

 

[LED]

LE...I have a USB Mouse and keyboard plus a Sanner and Printer which I can not believe that it's switching because the mous and keboard doesn't stuuter while the printer and scaners going not to mention I have a Speaker going with music ...no stutters either but I'll check with a techfreak that's into it tomorrow and get back maybe with some data.

 

[Eug]

Originally posted by: LED
LE...I have a USB Mouse and keyboard plus a Sanner and Printer which I can not believe that it's switching because the mous and keboard doesn't stuuter while the printer and scaners going not to mention I have a Speaker going with music ...no stutters either but I'll check with a techfreak that's into it tomorrow and get back maybe with some data.

Well, a USB mouse and keyboard are very low bandwidth. A printer is relatively low as well, and even a scanner isn't that high.

We're talking stuff like hard drives, etc. Now that's high bandwidth.

Here are some comments from Adaptec. It's a little old, but does have some good info.

USB
Furthermore, the same inherent simple design that allows for it to be low-cost also makes it "host centric" -- meaning that the host CPU must initiate every transaction occurring between every device. The practical ramifications of this are that once you've added more than a handful of devices on the USB bus, bus latencies increase, efficiency goes down and real sustained throughput is only a fraction of the 1.5 Mbytes/second upper bound...

USB is also a hub architecture, meaning that each device must be connected into a hubbed port rather than daisy chained from device to device. This adds additional cost when the number of devices you want to connect exceed the number of ports on your host system -- and each hub also counts as a device.

Even if USB 2.0 was implemented (an extension of today's USB implementation that Intel has begun to talk about which offer significantly more bandwidth than USB today), the same CPU utilization issues would exist.

Firewire
1. FireWire supports isochronous data transfers, like those used when transferring digital video and other time-based media. Isochronous data transfers differ from standard asynchronous data transfer types in the sense that they guarantee the timely delivery of data between nodes (i.e., 30 seconds of streaming video plays out in exactly 30 seconds). This means that when an isochronous device such as a DV camcorder is connected to the FireWire bus, that device grabs an allocated portion of the bus necessary to guarantee the timely delivery of its data -- say 10 mbytes per second. The bus also automatically allocates 20% of the total bus bandwidth (i.e., 10 mbytes / second) for serial command overhead -- leaving only 30 mbytes per second (in our example) of available bandwidth for other devices. Once the FireWire bus bandwidth has been fully allocated, the bus will not recognize additional devices -- regardless of whether-or-not the connected devices are actually transporting data.

2. A condition known as multiple device overhead is created when a lot of devices are introduced onto the bus. This condition begins to manifest itself with a relatively few number of devices and continues to degrade performance as more devices are added. The reality is, the very attributes that make FireWire self-configuring, hot-plugable and so convenient to use are the same inherent attributes that cause increased latencies and add to the device overhead.

In summary, FireWire is very well suited for time-based media applications such as digital video. It also has some nice usability features such as being hot-plugable and bus powered -- with enough bandwidth to support disk drives and other moderately fast devices. Unlike USB and IDE, it supports direct memory access (DMA) -- meaning that it does not require host intervention with every transaction, but it is not ideally suited in a RAID storage environment because of the increasing device overhead that accompanies multiple device connections.

What's their conclusion? SCSI is the best.

 

[LED]

Eug...I also have an USB2.0 HD and CDRW, still no effect but maybe I'll run some beches with the others pluged in as to opposed to them diconnected...that should tell the story eh?

 

[Eug]

Originally posted by: LED
Eug...I also have an USB2.0 HD and CDRW, still no effect but maybe I'll run some beches with the others pluged in as to opposed to them diconnected...that should tell the story eh?

It would be hard to do the test unless you had something like this. What would be interesting would be to do is compare Firewire to USB 2.0 in this situation:

IDE 0: Windows XP boot drive
IDE 1: 120 GB 7200 rpm hard drive, completely empty
USB 2.0 120 GB 7200 rpm hard drive
USB 2.0 DVD-ROM 16X
Firewire 120 GB 7200 rpm hard drive
Firewire DVD-ROM 16X

Test 1:
Put 4.3 GB DVD-ROM in USB 2.0 DVD-ROM and then start copying it to the boot drive on IDE 0.
Start doing benches on the USB 2.0 hard drive, including a sustained 4 GB transfer to the empty IDE hard drive on IDE 1.

Test 2:
Put 4.3 GB DVD-ROM in Firewire DVD-ROM and then start copying it to the boot drive on IDE 0.
Start doing benches on the Firewire hard drive, including a sustained 4 GB transfer to the empty IDE hard drive on IDE 1.

The other way to do it would simply be to buy 5 USB 2.0 hard drives and 5 Firewire drives and start benching the transfer speeds to them. In other words, for most people I suspect the CPU utilization and bandwidth issue isn't going to be a deal killer.

More important might just be the maximum transfer rate, though, which is about 50-100% higher with Firewire compared to USB 2.0, assuming the hard drive is a fast one.

I see a lot of tests where only older laptop drives are tested, which is pretty useless since a slow laptop drive will only just barely max out USB 2.0 bandwidth.

 

[LED]

Well I have all those goods and did test Firewire HD vs USB 2 and the outcome is why I now use the Firewire Port for it...just can't wait for the 800 to blossom. Meanwhile I'll hold off on the testing because I have a Barton and Abit Rev 1.2 sitting here for the last week and I gots to get that done...Hopefully my Tech Geek freind will have something cause these are very good points that LE brought up and I'm wanting to know as well but no more then getting my new rig together