Please consider a donation to the Higher Intellect project. See or the Donate to Higher Intellect page for more info.

A Look at FireWire and USB (2000)

From Higher Intellect Vintage Wiki
Revision as of 16:26, 12 February 2024 by Netfreak (talk | contribs) (Created page with "<h3 align="CENTER"> Hey, Sun -- Get on the bus! </h3> <blockquote> <strong>Summary</strong><br> Are USB and FireWire viable technologies for Unix? Rich Morin thinks so. He ou...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Hey, Sun -- Get on the bus!

Are USB and FireWire viable technologies for Unix? Rich Morin thinks so. He outlines the latest developments in high-speed connectivity, and explains why you -- and Sun -- should take another look at these emerging technologies.




By Rich Morin

Apple Computer has almost single-handedly succeeded in turning USB into an accepted interface standard. Sony, Apple, and others are currently making FireWire into the industry standard for multimedia. Isn't it time that Sun got on board?

Over the years, Sun has made good on its promise to support key industry standards. Thus, it supports both EIDE and SCSI for disk access, and offers a choice between MBus and PCI bus. Other interfaces, such as FDDI, are typically available from third-party vendors.

Unfortunately, Sun seems to be a bit behind the curve on FireWire and USB, two interesting interface technologies. Given the large number of interesting devices -- video and still cameras, digitizing tablets, keyboards, mice, microscopes, printers, and scanners -- available that use these interfaces, this is really a shame.

Using third-party interfaces, it is possible to attach FireWire or USB to many Sun systems; this is not the same, however, as having built-in support and a wide range of drivers.

IEEE-1394, which Apple markets as FireWire and Sony markets as i.LINK, is a high-speed serial connection, based on a tiered hub-and-spoke topology. The technology was developed by Apple and later codified by the IEEE-1394 specification. It currently runs between 12.5 and 400 Mbps, and speeds of 800 Mbps are forthcoming.

Speeds of 800 Mbps
for FireWire will
soon be available.

Dedicated game computers, including those from Nintendo, have provided a testing ground for FireWire. More recently, it has been adopted for realtime video use by camera manufacturers. FireWire is also being adopted for external disk drives and arrays, where the cabling limitations of such competing interfaces as EIDE and SCSI have long been a sore point.

The FireWire cable consists of two twisted and shielded pairs of cables and two power wires. There are no terminators -- none with which users need to concern themselves, at least. Nonetheless, FireWire can run 13 feet per link, and intervening hubs can extend this distance substantially.

FireWire devices need to have two connectors, one for connecting the cable to a source and another connecting the next device to the chain. The connectors (and, in fact, the whole system) are designed to allow hot plugging. Of course, interrupting a chain to add another device will temporarily disconnect the remainder of the chain. Repeaters, splitters, and bridges allow for the free-form connection of devices in stars and chains.

Unlike SCSI, FireWire arrived with a standardized connector. Unfortunately, this standard has already been compromised: video cameras use a four-wire version of the cable. Oh, well.

The FireWire protocol is a peer-to-peer system which has the potential to connect computers to each other in a high-speed network. Although FireWire does not support long-distance interconnection, it might be appropriate for setting up an economical local cluster. Work is also being done on an IP definition for FireWire; stay tuned.

Because FireWire is a peer-to-peer system, the boundaries between computers and peripherals can become blurry. It is conceivable, for instance, that a video camera could take control of an application, telling it how to process and store incoming data. Provision is made for asynchronous and isochronous communication for bulk transfers and time-critical one-way transfers, respectively. This works in a manner quite like USB -- but it is much faster.

Intel's Universal Serial Bus (USB) was designed as a multipoint replacement for RS-232; it allows up to 127 devices to be connected to a single computer. It can even serve as a substitute for other interfaces, including parallel ports and keyboard/mouse interfaces.

Many Sun users would be delighted to have an industry-wide range of keyboards and devices to choose from. Such variety is already available in the Mac and PC arenas, but Sun users are still stuck with a proprietary interface and a correspondingly small range of input devices.

USB cabling consists of a two-conductor, twisted-shielded pair of wires for bidirectional data, plus two heavier wires for five-volt power and ground. USB supports two speeds, 1.5 Mbps and 12 Mbps, which can exist together on the same bus. Wiring for 1.5 Mbps need not be shielded; neither speed requires termination.

At this speed, USB is obviously no serious threat to SCSI, let alone to FireWire (which starts at 12 Mbps). Intel has announced an improved version, however, which will run at 400 Mbps. It will be interesting to see which standard will win out in the high-speed arena. FireWire should probably win on technical grounds, but logic (as always) may have little to do with it.

FireWire should probably win
in the high-speed arena on technical
grounds, but logic may have
little to do with it.

Two new connectors have been developed for use with USB. One has four pins in a row and is used for connecting devices to hubs; the other has a square shape and is used for connecting hubs to computers or to other hubs. Because many devices have permanently-attached cables, you will see fewer square-shaped plugs in use.

USB uses a tiered hub-and-spoke connection scheme. The tier starts with a hub, to which a few devices can be connected. When the top level runs out of connector space, another hub can be added. Most desktop devices, including keyboards and printers, can also act as hubs.

USB hubs need to have some intelligence, because they are required to sense the addition of a device to an operating bus and inform the host. The hub will not apply bus power to a device until the host has assigned it an address, and the bus must recognize high-speed communication by the host (and not send it out over unshielded wires or to devices it knows can handle only the lower speed.)

USB's signal amplitude is low: it uses a 0.4 volt differential centered at 1.75 volts DC. As buses mature and electronic devices improve, lower voltages and currents can be used, requiring less signal power and creating less interference. Thus, serial communications have moved from current-loop devices, such as old teletypes, through the 12-volt RS-232 standard, to USB's 1.75 volts.

Power management on the USB can be problematic. The hub is supposed to supply power for the bus, but individual devices (if sufficiently power hungry) or collections of devices (if sufficiently numerous) can overtax the hub's capabilities. As a result, the supply voltage can be depressed to the point that the entire bus fails to operate.

Current limiting by the hub helps, but this is not a perfect solution. Self-powered hubs, which do not draw excessive power from the host computer, can also help. Fundamentally, however, it is up to users to keep track of the load they are demanding of their hubs, just as they would for electrical devices on a common circuit breaker.

Devices which derive their own power from another source must still connect to bus power, because of the signaling features involved with connection to a hot bus (high- and low-speed devices are identified by details of the power connection). A device which is plugged in to the bus, but is otherwise in an off state, must still provide information to the host.

The USB protocol allows for priority handling of a channel. This is necessary for time-sensitive data, such as digitized audio. Priority channels are isochronous (allowing guaranteed realtime performance) and unidirectional. Blocked channels are bidirectional and may or may not include error checking.

Blocked data can be given a back seat by software, up to the limit at which the priority channel uses all available bandwidth. Apple's G4 provides two USB channels to reduce the chances of this sort of saturation.