Can Someone Please Explain USB vs. FireWire??

  • Thread starter Thread starter Alexrkstr
  • Start date Start date
A

Alexrkstr

Member
I can't seem to find anyone that can technically explain how a firewire interafce will be better for optimizing your recordinds.... the only thing I hear is that USB consumes CPU power, and I even challenge that.

Can someone explain if it is true that FW is better than USB and why with some technical data?
I'm sure everyone will find it useful.

My question is based on the potential of upgrading from Mbox 2 Mini to a FW PT interface.
 
I can't post link to the site yet but here is some info that may help..if I understand your question..

1 - FireWire, uses a "Peer-to-Peer" architecture in which the peripherals are intelligent and can negotiate bus conflicts to determine which device can best control a data transfer

2 - Hi-Speed USB 2.0 uses a "Master-Slave" architecture in which the computer handles all arbitration functions and dictates data flow to, from and between the attached peripherals (adding additional system overhead and resulting in slower data flow control)

FireWire vs. USB 2.0 Hard Drive Performance Comparison
Read and write tests to the same IDE hard drive connected using FireWire and then Hi-Speed USB 2.0 show:

Read Test:
* 5000 files (300 MB total) FireWire was 33% faster than USB 2.0
* 160 files (650MB total) FireWire was 70% faster than USB 2.0
Write Test:
* 5000 files (300 MB total) FireWire was 16% faster than USB 2.0
* 160 files (650MB total) FireWire was 48% faster than USB 2.0
 
I can't post link to the site yet but here is some info that may help..if I understand your question..

1 - FireWire, uses a "Peer-to-Peer" architecture in which the peripherals are intelligent and can negotiate bus conflicts to determine which device can best control a data transfer

2 - Hi-Speed USB 2.0 uses a "Master-Slave" architecture in which the computer handles all arbitration functions and dictates data flow to, from and between the attached peripherals (adding additional system overhead and resulting in slower data flow control)

FireWire vs. USB 2.0 Hard Drive Performance Comparison
Read and write tests to the same IDE hard drive connected using FireWire and then Hi-Speed USB 2.0 show:

Read Test:
* 5000 files (300 MB total) FireWire was 33% faster than USB 2.0
* 160 files (650MB total) FireWire was 70% faster than USB 2.0
Write Test:
* 5000 files (300 MB total) FireWire was 16% faster than USB 2.0
* 160 files (650MB total) FireWire was 48% faster than USB 2.0

Wow - this is EXACTLY what I was looking for... THANK YOU. One question though - are these are FW400 or FW800?
 
Yeah, and FireWire just sounds cooler than USB.

Do you want your wicked tunes conveyed by FireWire (sounds cool) or USB (sounds wimpy)?

FireWire for me baby...


:D
 
fw has it's own controller... usb uses the cpu so it does take extra cycles... usb allocates a portion of its bandwidth to other peices onthe bus even if they are not in use at the time... usb works in a burst mode kinda way... where fw will do sustained through put...
 
Yeah, and FireWire just sounds cooler than USB.

Do you want your wicked tunes conveyed by FireWire (sounds cool) or USB (sounds wimpy)?

FireWire for me baby...


:D

Lol Ya the name alone lets you know it would win. jk jk
 
One other thing... USB uses 4 wires. 2 wires are always used for power. That leaves 2 wires to carry all of the data. Fire wire uses 6 wires, of which 2 are for power. That leaves 4 wires to carry data. Yes, there are some Firewire jacks/plugs/cables that have only 4 wires total. The 2 power wires are left out. Still, there are 4 wires for data.
 
Some of the numbers are plausible for FW400, but I'd expect FW400 to range up to maybe 30-40% faster than USB in typical use. If you're seeing numbers that are 80% faster, you're either hitting some really bad degenerate case in the USB side of things (no guess what) or those are based on FW800. Either way, you hit a wall well before 800 Mbit/second in all but burst throughput, making faster speeds mostly irrelevant except when booting off the device or other similarly degenerate workloads.
 
Last edited:
One other thing... USB uses 4 wires. 2 wires are always used for power. That leaves 2 wires to carry all of the data. Fire wire uses 6 wires, of which 2 are for power. That leaves 4 wires to carry data. Yes, there are some Firewire jacks/plugs/cables that have only 4 wires total. The 2 power wires are left out. Still, there are 4 wires for data.

Which is fascinating because both USB and FW400 are half duplex (one side speaks at a time). I'm not sure why they have twice as many data lines under the circumstances. Of course FW800 is full duplex, which means that FW800's total round-trip bus throughput can be on the order of four times as fast as USB, not twice. :)

[Edit: Oh, yeah. I know why. FW800 was already in planning at the time and was full duplex, and they needed to maintain electrical compatibility. Of course. *smacks head* ]


fw has it's own controller... usb uses the cpu so it does take extra cycles... usb allocates a portion of its bandwidth to other peices onthe bus even if they are not in use at the time... usb works in a burst mode kinda way... where fw will do sustained through put...

They both have controllers. The USB controller is just a lot dumber. :) ...unless, of course you meant that FireWire devices have their own controllers (which is true).

I'm not quite sure what you mean about USB allocating a portion of the bandwidth to devices on the bus even if they are not in use. If you mean things like HID devices behaving isochronously, that's true, but if somebody designed a FireWire HID device, somebody could conceivably design it that way, too if they were nuts. The difference is that USB precludes the device telling the host that it needs to do something, which means that every button on every device has to be polled regularly for status changes.

Of course, all the FireWire devices I've ever seen that look somewhat like HID devices (things with buttons) are things like audio interfaces or camcorders that have isochronous communication going constantly for the audio streams anyway, so the data rate difference between sending button change messages versus sending button status continuously as part of every frame amounts to noise. :D

Both USB and FW do burst transfers and continuous transfers. USB can be slightly faster at bursts because its theoretical speed is faster. FW is significantly faster at anything approaching continuous throughput because it doesn't require continuous CPU to do it. :)
 
I'm not quite sure what you mean about USB allocating a portion of the bandwidth to devices on the bus even if they are not in use. If you mean things like HID devices behaving isochronously, that's true, but if somebody designed a FireWire HID device, somebody could conceivably design it that way, too if they were nuts. The difference is that USB precludes the device telling the host that it needs to do something, which means that every button on every device has to be polled regularly for status changes.:)


no... as it was explained to me (and perhaps i misunderstood) if say you have a usb printer that's sitting there unused at the time... some portion of the bandwidthis allocated to that device just incase you start to use it because of it's serial nature... where FW is paralell and the "smart"devices simply extract what info it needs...
 
no... as it was explained to me (and perhaps i misunderstood) if say you have a usb printer that's sitting there unused at the time... some portion of the bandwidthis allocated to that device just incase you start to use it because of it's serial nature... where FW is paralell and the "smart"devices simply extract what info it needs...

*shrugs*. I suppose that's remotely possible. That would depend on the printer. Generally speaking, though, I would not expect a USB printer to use any bus bandwidth except possibly the driver occasionally polling it for ink levels.

In general, USB (and FireWire) devices are bulk devices, which means they don't get any bandwidth reservations, merely getting whatever is available whenever the computer sends a message to the device and/or asks the device to send it something, and getting delayed as much as is needed until a free time slot on the bus becomes available. Unfortunately, some early USB audio devices were also bulk devices, which is one of the reasons USB audio got a really, really bad rep there for a while. :D

BTW, FireWire is definitely not a parallel bus... well, unless you count loops in a poorly wired setup. :D

The type of communication where a device requests a reservation is known as isochronous communication, which literally means "equal amounts of time". In USB and FireWire, every second on the bus is basically diced up into time slots of equal length. Each of those slots can be used for a message sent to a device or received from it (or in the case of FW800/FW1600/FW3200, one sent and one received packet per slot). With isochronous communication, a device declares that it needs a block of N slices, and that it will need one of those blocks again after every K slices until the device is deactivated or its settings change. In essence, this means that it reserves a certain amount of bandwidth, though we generally think of it more as time slices rather than bandwidth since it is a stream of bits, not a bunch of analog signals multiplexed on the same wire... but I'm being a little pedantic here.

Audio (and video) devices typically use isochronous communication. Normally, the only devices that take bandwidth whether they are in use or not are isoch devices, and even that isn't purely true. A USB device won't send data unless the driver is requesting it. Unload the driver, and even an isoch data stream goes away. Thus, for some types of devices (webcams, for example), the device typically only sends data when requested. For audio devices, however, usually the driver is always active. YMMV.

Human interface devices (a.k.a. HID; anything with buttons) are also isoch devices, at least in the USB world. So your mice and keyboards and stuff are constantly wasting bandwidth as the computer asks "Has this jerk pressed a key yet?" over and over and over. A FireWire HID device, if such a thing existed (and I guess they probably do to some degree), would not likely be isoch because the device would have the ability to send a message to the computer only when a button is actually pressed.
 
Last edited:
thnx for the info... and you're right it's not a paralell process really... i was not describeing it very well... i mean parapell in the sense that they all read at the same time and "choose" to act on data or not... instead of watching for an interupt/header(?) to act on...
 
Back
Top