When I originally decided to repair the power supply for the Cooler Master Xcraft external enclosure, my first thought was just to do it because of the sheer utility value of having such an enclosure around. But then I realized, this was going to be a good opportunity to revisit one of the small battles from the past – namely USB 2.0 versus Firewire.
A Brief Technical Background of the Interfaces
Universal Serial Bus, or USB for short, was first standardized in 1996 by a consortium of seven companies which involved mostly computer-related companies. The original standard permitted for Full-Speed 12Mbit/s and Low-Speed 1.5Mbit/s transfer rates.
It wasn’t until 2000 that USB 2.0 became available. It was an upgrade to the original USB 1.x series of standards, offering higher data rates of 480Mbit/s (high-speed). This was capable of operating over the original four-conductor cable as used by USB 1.x, and peripherals were backwards and forwards compatible – operating at the maximum speed mutually supported by both host and device. Cables and plugs were mostly standardized, with some manufacturer-specific deviations. However, it gained significant support on both PC and Apple platforms and replaced a number of legacy ports.
USB operates as a strictly master-and-device hierarchy, with all transactions initiated by the bus master, usually the computer. This served to simplify and reduce the cost of peripherals, which may have been part of the reason for its success and ubiquity. USB offers both power and data connections, and is hot pluggable. Several device classes were defined, for easier device configuration. Since then, faster variants of USB 3.0 and 3.1 “Superspeed” have become popular, while maintaining backwards compatibility for the most part.
IEEE 1394, also known as Firewire or i.LINK or Lynx was an alternative interface which offered similar features. However, Firewire development pre-dates USB beginning in the late 1980s, and completed in 1996 primarily by Apple with contributions from semiconductor manufacturers and computer-related companies. Notably, Intel was not one of the parties, and this was frequently attributed as being the reason for its lack of penetration into the market.
Firewire contrasted with USB somewhat, by operating at rates of 100, 200 and 400Mbit/s (marketing rate, with actual physical rates marginally lower) from the outset. Later improvements boosted the rate to 800Mbit/s and higher although using different connectors and signalling and being relatively unpopular and shortlived by comparison.
Unlike USB, Firewire peripherals were more complex owing to the need for any of the devices on the bus to perform as a bus master. This increased the cost of Firewire peripherals (in general). The bus also allowed for various abilities not catered for in USB which has strict master and device relationships (although this changed later with the introduction of USB on-the-go (OTG)). It was common in Firewire buses to utilize daisy chaining of devices in a way not common with USB, and even possible to use Firewire to perform host-to-host connections for use as a “network” connection or to access another computer’s hard disk (e.g. MacOS Target Disk mode).
Firewire proved to be more efficient by supporting direct-memory access (DMA), which unfortunately, also allowed it to be a (potential) channel by which attacks can be launched on target computers simply by plugging in malicious peripherals.
Similar to USB, the original Firewire 400 standard had a number of standardized connectors – a six pin which carries power, and a four pin which carries data only. While it does carry power in a similar way to USB, the voltage was not standardized, and was “nominally” around 25V, although could be much lower depending on the design of the port itself. It is also capable of hot-plug operation, with standardized device classes for ease of device configuration. However, USB touted 127 possible devices per bus, with Firewire topping out at 63. This was rarely an issue in ordinary usage, however.
Despite the superiority of Firewire at its introduction when compared with USB 1.1, it remained relegated to niche roles such as in transporting video and audio (e.g. for MiniDV camcorders). Lack of support by Intel meant that Firewire interfaces were often an “add-on” extra for PC users, and the introduction of USB 2.0 bought contemporary performance, thus reducing the incentive for some users to install such an interface.
One major use of high speed external interfaces is to enable the connection of external storage to a computer. Firewire was initially envisaged as a way to replace the parallel SCSI bus for connection of hard drives, for example. High speed interfaces were at a premium, prior to the advent of USB 2.0 and Firewire 400, thus their existence allowed for much improved external drive performance enabling multimedia and more demanding applications on external devices. As a result, manufacturers of more premium high-end external enclosures and devices began to offer devices with both interfaces to cater for users which may have access to only one or the other (e.g. early iMacs with USB 1.1 and Firewire 400).
Despite the similarities in the advertised physical-layer data rates of 480Mbit/s and 400Mbit/s, users noticed differences in the performance. Where both interfaces were available, it wasn’t as simple as choosing USB 2.0.
To see just how different these interfaces performed, I decided to test it myself with some semi-modern hardware so that we have a good indication of just how different the performance was. As it turns out, my everyday AMD Phenom II x6 1090T BE machine with a Gigabyte 890FXA-UD7 motherboard features both USB 2.0 ports hosted by the chipset and Firewire 400 ports hosted by a Texas Instruments IEEE 1394 controller.
The Enclosure and Drive
The test was conducted with the Cooler Master Xcraft enclosure. It has a flossy metal finish on the external cover.
Vented grilles are provided to allow for the drive to cool, and rubber feet stop the drive from sliding around. A vertical stand is also provided, but not pictured.
The front has a logo badge which serves as a one-touch back-up button (for the software which it was initially bundled with) as well as being an indicator light of power and activity (blue and red respectively).
As this is a more premium unit, we can see a USB B-F socket to interface to the host PC, but also two USB A-F to allow for additional drives to be connected. This indicates the controller board has a USB hub IC on board, however, it is to be noted that USB devices can only be nested down seven hubs but reliability can suffer. In general, many enclosures of the day, even dual-standard ones, did not offer this facility.
There are also two Firewire 6-pin sockets, and both are “equal”. Either one can be used to connect the drive, and the other to daisy chain. Some earlier models may have had three of these ports rather than two, however, rarely drives with just one port were also made. The advantage of this set-up is that no Firewire hubs would be necessary if connecting a number of these units together, as Firewire hubs were rarely encountered and much more expensive than USB hubs. On the downside, there are potential reliability issues especially with long cables and potential for bad-connections mid-bus.
But of importance is the internal chipset that powers it, as different chipsets and firmwares can affect the performance and compatibility somewhat. The PCB of the board shows that the solution is made by SKYCable Co. Ltd. On the top side, there is an SMSC USB2504A-JT USB 2.0 four-port hub IC. There is the firmware flash chip, soldered to the board, a PMC Pm39LV512-70JCE.
The chipset is buried underneath, and is an Initio INIC-1530s. This chipset claims to be IEEE 1394a-2000 compliant with asynchronous transfers up to 400Mbit/s. It supports SBP-2 interface over Firewire for maximum performance, and USB bulk-only transfer. The IDE side supports up to UDMA 100, making it a fairly high performance solution. Next to it is an Agere L-FW802C, which I couldn’t find a datasheet for, but presume is a Firewire PHY interface.
To test the unit, I decided to grab a random IDE drive I had lying around in my room that needed some exploring. The drive in question is a Western Digital Caviar SE (WD2000JB-00GVC0) 200Gb 7200rpm 8MB-cache hard drive. While it wasn’t the fastest, largest, densest drive that I had in my possession (that would be the 320Gb IDE drives, which are still employed in legacy-computer service), it should be still enough for demonstration purposes. As a note, this drive was manufactured 2005, and would have been taken out of service around 2011. It has rested for six years … and it still works with all its data intact.
Testing was performed with HDTune Pro and ATTO.
HDTune Pro Sequential Read
On the USB 2.0 interface, with no other devices connected to the controller, the chipset managed a steady 31.1MB/s transfer rate. This is considered fairly good for USB 2.0, as the highest results normally sit about 30-32MB/s, with common user rates varying from about 17MB/s to 28MB/s depending on the host controller and devices connected to the bus (as bandwidth is shared).
However, when connected to Firewire, the drive was able to achieve a very solid 40MB/s almost throughout the transfer. Towards the end, the limitations of the drives’ own ability to transfer data was shown in the inner zones of the hard drive. A faster drive would have been able to “fill it in” and achieve an average of about 40MB/s.
As a result, Firewire wins when it comes to sequential read with 40MB/s compared with 31.1MB/s on USB 2.0. So despite the physical layer rate of Firewire being less than USB 2.0, its reduced overheads result in a substantial (28.6%) advantage over USB 2.0.
Of note is that because bus bandwidth is shared, external drive to drive copies are fastest when copying from one bus to another – one drive on Firewire and another on USB 2.0 for example. If you have multiple independent USB controllers (as I had previously chose to configure my machines with), then having one drive on a PCI card and the other on the onboard chipset should see full performance. Hooking them up to the same bus often results in half the performance due to the scarcity of bus bandwidth – note how the hard drive is faster than the interface and is essentially bottlenecked by it.
HDTune Pro Sequential Write
When writing, a virtually identical result is seen for USB 2.0 with an average of 31MB/s transfer rate.
However, Firewire encounters some limitations here with a reported rate of 25MB/s. This is an unexpected finding and may be chipset/firmware related or OS-related due to Windows 7’s handling of caching for “SCSI” devices versus USB devices.
So unexpectedly, when it comes to writes, USB 2.0 wins. But likely, not because it is technically superior, but maybe because of the way Windows 7 handles write caching, command queueing (not applicable to USB BOT) and buffer flushing (even when best performance is selected).
ATTO seems to show USB having parity of performance when it comes to reading and writing as implied by HDTune Pro. Best performance is at 64kB accesses and above.
Firewire’s performance discrepancy is reflected in ATTO as well. The performance does not increase as sharply with block size as with USB 2.0, but overall absolute transfer rates for small block accesses are much improved over USB 2.0 showing another advantage. This may be related to command queueing and DMA access.
While Firewire was not as popular as USB 2.0 in its heyday, and Firewire is all but dead now, anyone who has used the two interfaces would probably already have known that Firewire is mostly superior for external hard drives despite its lower “advertised” physical layer rate (of 400Mbit/s vs 480Mbit/s of USB 2.0) due to its more efficient use of bus bandwidth.
The differences were quantified on a modern machine with sequential read transfer rates in favour of Firewire by 28.6%. Sequential writes showed an unexpected disadvantage for Firewire, possibly due to OS or chipset limitations, with USB 2.0 besting Firewire by 23.5%. However, when small block accesses are involved, absolute figures from ATTO show 4kB read accesses on Firewire are 2.6x faster, and writes are 2.4x faster.
Generally speaking, Firewire appeared to be the superior bus for external hard disk enclosure interfacing. Aside from the write anomaly, it “tunnels” SCSI disk commands over the SBP2 interface and certain chipsets could even support multiple LUNs (e.g. a Master and Slave device) on the IDE bridge board, as I had done such a thing with a Prolific PL3507 in the past. Some difficult ATAPI devices seemed to work better as well. Such features are not often supported on USB.