I recently purchased a Drobo, and in looking over some online documentation, I encountered this support article which states:

If a FireWire 400 device is also connected, it will pull down the overall performance to match FireWire 400 (FW400) instead of FireWire 800 speeds.

I realize that if I attached a FireWire 800 device to a 400 device, and then that 400 device to my computer that obviously I'd only see 400 speeds from the 800 device, but this KB article seems to imply that connecting a 400 device to the other FW port on my Drobo, and having my Drobo connected via 800 to my Mac, will cause the Drobo to communicate at 400 speeds.

Is this true? Is this a limitation of the FireWire protocol, a practical limitation common to many implementations of FireWire, or a limitation specific to the Drobo itself?

  • A canonical answer to this would be a good thing; I've found many posts on various tech discussion web sites asserting both sides of the argument, claimed to be backed up by personal testing. – Daniel Mar 27 '12 at 16:27
  • This should be easy to test with data transfer of a large file (say an entire VIDEO_TS folder) with A/B testing where A has a FW400 device attached but idle. I've never seen the connection of a FW400 device cause significant slowdowns, so it might be a drobo specific implementation or just a CYA in case the 400 cable is placed between the host and the drobo. – bmike Apr 6 '12 at 15:10

It depends primarily on how the devices are connected.

Say we have three devices connected:

A(400) <--> B(800) <--> C(800)

Firewire is processed in chips. 800 speed firewire chipsets will pass 400 speed along the 800 bus at 400 speeds as data is passed along the chain. So anything C sends will be seen by B and A as 400 speed, and it will exist as 400 speed on the 800 bus between A and B. It doesn't increase the 400's total bandwidth, but it does take twice as long to transmit along the 800 bus as it would if B had sent it natively.

When B sends to A it will be at 800 speeds.

The problem is that if A is particularly communicative then it will drag down the total bandwidth of the 800 bus between B and C. If A transmits at full speed, the 800 bus becomes a 400 bus. If A transmits 25% of the time, then its 100mbps data consumes 200mbps of time on the 800 bus.

When C sends data to A, it will be at 400 speeds, and use up twice the bandwidth on the 800 bus than it would if it were transmitting native 800.

This is called multi-speed concatenation.

When B notices C sending 400 speed data, it simply passes that data along the 800 bus at 400 speeds. When that packet is done it can immediately send the next packet at 800. The transition is instantaneous, so there's no additional bandwidth lost, but again, if A talks a lot, it can reduce the total bandwidth on the 800 bus significantly.

B(800) <--> A(400) <--> C(800)

This configuration will reduce the total bandwidth through the entire bus to 400, regardless of the chipset used in each device.

| improve this answer | |
  • This is sort of what I suspected - the protocol doesn't specify either way, so it becomes an implementation detail. Good to know, but still annoying that the speed of devices in the chain depends on the position of those devices in that chain. – Kyle Cronin Mar 27 '12 at 16:44
  • I'd love to point out the specification, but it's an IEEE specification that requires $$$ to access. – Adam Davis Mar 27 '12 at 16:44
  • @AdamDavis, do you have any sources on this? I ask because I've read your position on a number of web sites, but I've also read quite a few people claiming their personal testing shows that FW400 anywhere in the chain slows the whole chain to FW400 speed. – Daniel Mar 27 '12 at 16:45
  • 1
    Just put all the slow cables and devices at the end of the chain. Since most chipsets all seem to follow the 63 device limit the overhead loss is low and I've only seen it affect things with minor (5 to 10%) slowdowns worst case when your chain grows to include 17 devices or so. – bmike Mar 27 '12 at 16:50
  • 1
    This is a fantastic answer. Thanks so much for the work you put into it! – Kyle Cronin Mar 27 '12 at 17:14

FireWire is a point to point protocol and the controllers are generally fully functional and can use the full capacity between two adjoining controller chips over a FireWire cable. So in practice just don't put a FireWire 400 speed cable between devices that are capable of FireWire 800 and the computer. Place your first FireWire 400 cable and device at the end of the chain of FireWire 800 capable devices.

Basically a FireWire 400 cable has six conductors - two for power and four for data. FireWire 800 cable has eight (or double) the data conductors and the same two power lanes.

Think of an analogy with the interstate highway system. Here you have a computer connected via fire wire 800 to the Drobo and fire wire 400 to something else. This is the same as three highway exits with four lanes of traffic between the middle and the last exit and eight lanes of traffic between the first in the middle exit. Assuming there's no delay getting on and off the highway exits (which is true for FireWire but not in reality), it shouldn't matter that traffic between the first two exits will be slowed down just because later on the highway merges down to four lanes.

Of course when you have simultaneous traffic some going all the way to the end of the chain at the 400 speed that will impact the bandwidth available for traffic between the two 800 speed ports.

The FireWire protocol is fast for exactly this reason whereas the USB chain always slows down for the entire "bus". From an engineering standpoint it's simpler and cheaper to just slow down the entire transport to avoid having to deal with the network topology and differing link speeds due to cabling conditions down the chain.

| improve this answer | |
  • Actually, the USB bus is ALWAYS high speed between the high speed hub and the high speed host, and does the translation to change speeds. Firewire does not. – Adam Davis Mar 27 '12 at 16:58
  • Please edit my answer into technical correctness on the USB front as needed - I've always seen slower speeds when a slow mouse was connected to the keyboard (same hub as a drive) for instance on USB. I have lots of real world experience, but not a deep understanding of the protocols and implementation details. I know enough to be dangerous with assumptions based on measurements of bulk data transfer times. – bmike Mar 27 '12 at 17:01
  • Eh, since the question isn't about firewire vs usb, I'm not inclined to fix it beyond my comment. – Adam Davis Mar 27 '12 at 19:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .