Level: Introductory Peter Seebach (developerworks@seebs.plethora.net), Freelance author, Plethora.net
24 May 2005 SCSI has a reputation as one of the oldest and most widely respected standards in computing, but it also has a reputation for poor price and performance and amazing quirkiness. This month's Standards and specs looks at the history of the legendary SCSI specification.
The Small Computer System Interface (or SCSI) standard is about 20 years
old and is still in use, although it has evolved and changed a
great deal since its humble beginnings as a proposal by Shugart Associates to
standardize device interfaces.
The SCSI standard is a parallel interface standard that traditionally
handled up to 160 MBps in data transmission and allowed users to connect
several devices to a single port (making it not just an interface, but also an
I/O bus).
The SCSI standard is most often used for disk devices, but such devices as
CD-ROM drives, tape drives, and scanners are also used with it. In fact,
there is no particular reason to limit the scope: any device could use
SCSI. However, the disk interface part of the standard is the highest profile,
probably because it is the most mature part of the standard.
Alan Shugart: Moving and shaking
Alan Shugart, founder of Shugart Associates and Seagate, gets most of the
credit for being the visionary who realized the world needed a standard like
this one. The initial protocol was called the "Shugart Associates Systems
Interface," or SASI. It had a fairly limited set of protocol commands, and
performance peaked out at 1.5 MBps (which sounds pretty weak, but for 1979
this was incredible).
In 1981, Shugart Associates was in conversation with other vendors (like NCR)
about interface standardization. By 1982, ANSI had a technical committee
working on the new standard, although they had redesignated it to its current
name, SCSI.
The official standard was released in 1986, and the Mac Plus was one of the
first machines to actually ship with SCSI. Apple continued using SCSI as a
primary drive interface in its systems for a very long time -- the first
IDE-based desktop Macintosh systems would not be seen for a decade or so.
The evolving SCSI
 |
Some flavors of SCSI
The following are varieties of SCSI:
-
SCSI-1 uses an 8-bit bus and supports data rates of 5 MBps.
-
SCSI-2 adds optional 16-bit support, data rates of up to 20MBps, and new
connectors (including the widely known 50-pin D-sub connector).
-
Wide SCSI uses a wider cable (68 pins) to support 16-bit transfers.
-
Fast SCSI uses an 8-bit bus, but doubles the clock rate to support data rates of 10 MBps.
-
Fast Wide SCSI uses a 16-bit bus and supports data rates of 20 MBps.
-
Ultra SCSI uses an 8-bit bus and supports data rates of 20 MBps.
-
Ultra Wide SCSI uses a 16-bit bus and supports data rates of 40 MBps.
-
SCSI-3 is a collection of related standards, including the Ultra, Ultra2, and
faster standards.
-
Ultra2 SCSI uses an 8-bit bus and supports data rates of 40 MBps.
-
Wide Ultra2 SCSI uses a 16-bit bus and supports data rates of 80 MBps.
-
Ultra3 SCSI uses a 16-bit bus and supports data rates of 160 MBps.
-
Ultra320 uses a 16-bit bus and supports data rates of 320 MBps. It requires a new data-transfer mode with an 80 MHz free-running clock to eliminate ISI problems with the clock signal.
-
Ultra640 is the same as the 320 except it supports data rates of 640 MBps and its clock is 160 MHz.
|
|
The following section looks at a bit of the interface standard's history.
SCSI-1: A good beginning
The SCSI-1 specification nominally supported 5 MBps transfer rates; in
reality, the Mac Plus couldn't come close to this, but it was still faster
than the pre-SCSI Mac ever managed to be.
Early SCSI systems did all sorts of things no one would expect to see
today. For instance, the AT&T 3b2 had an SCSI controller which was
connected to a disk controller -- and that disk controller could control more
than one disk. Modern SCSI drives generally have an on-board controller for
each drive; it has been this way for a long time. The support for logical unit
numbers (LUNs, a unique identifier used on an SCSI bus to distinguish between
devices that share the same bus) was crucial in keeping costs reasonable when
the controller hardware was large and expensive. It became much less
significant later. (That's not to say it's not still in use today; more on
this later.)
SCSI's design as, essentially, a peer-to-peer network allowed all sorts of
creativity. A computer lab I saw in 1989 had seven computers hooked up to a
single hard drive. Even more recent devices use similar techniques. An SCSI-based sampler might well have its own SCSI ID, allowing it to share its
internal disk with a music workstation.
SCSI-2: Bringing standardization to a point
At this early stage, though, what SCSI needed was better performance (and
a standardized command set). It got it with SCSI-2. The SCSI-2 standard
(originating in 1985, before the ink was dry on the SCSI-1 standard and it was
formally approved) was released in 1990, then retracted for a few changes and
re-released in 1994. There are still some references to the 1990 standard,
but there aren't all that many changes -- it seems the committee just wanted
to get a few points nailed down. SCSI-2 provided for fast SCSI (10 MHz) and
for wide SCSI (16 bits per transfer instead of 8). In fact, with fast and wide
SCSI, you could (in theory) move 20 MBps. Performance was a big improvement,
but it might not have been the biggest alteration.
SCSI-2 also standardized device command sets. The SCSI-1 standard was
weak in this area, resulting in an explosion of custom drivers for a given
disk. The Macintosh showed long-term effects of this problem -- the Mac
assumed that each disk would have its own drivers stored on the disk; it
simply would not attempt to drive a disk for which it did not have specific
drivers.
The result of this chaos was a market in third-party disk drivers and
utilities. The same thing happened with CD-ROM drives -- a CD-ROM drive not
on Apple's list simply wouldn't do anything until drivers had been loaded.
SCSI-2 fixed the underlying problem, but Apple didn't really address the
software implications until Mac OS X.
Still, since the SCSI-2 standard came out, SCSI
devices have no reason to be incompatible. Real incompatibilities are now very rare.
SCSI-2 also dramatically improved the available choices in cabling and
signaling, as well as adding support for command queuing. Command queuing
is one of the features which has continued to keep SCSI subsystems as a good
option for workstations and servers, allowing a drive to respond to multiple
commands in the most efficient order rather than in the order in which they
were received. On a busy system, the performance difference can be quite
impressive.
SCSI-3: Widening the reach
The SCSI-3 standard started in 1993, once again before SCSI-2 had
finished being approved. SCSI-3, rather than being a single unified standard,
is a family of standards which work together. It is possible to comply with
the SCSI-3 command set while not using any of the suggested electrical
interfaces. This has been used heavily to provide a command protocol for
devices that use some other bus to transport SCSI packets back and forth.
Today, the SCSI protocol is very heavily used in ATAPI and USB devices,
not just for devices with actual SCSI cables. While USB and FireWire have
eaten away a lot of the market for SCSI scanners, vast numbers of high-end
SCSI scanners and similar devices still exist and are still in quite
active use. Similarly, while many see SCSI as an industrial server
feature, serious power users continue to use SCSI disks for high-performance
systems. The performance advantage is quite noticeable under heavy loads.
Technical quirks
The technical quirks of early SCSI are famous. The early SCSI standard
depended heavily on resistor packs placed strategically on an SCSI cable (in
theory, at both ends). Devices simply assumed the signaling was correct and
shoved the bits around. "Bad termination" could mean nearly anything and
could have unpredictable effects, ranging from data loss to poor performance.
Drives might be detected at a strange or implausible data rate, occasionally
timeout on commands, or just plain hand back garbage.
A couple of typical quotes from a fortune cookie database set the tone for
what it was like to deal with early SCSI:
Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning black candles.
-- Anthony DeBoer
SCSI is NOT magic. There are fundamental technical reasons why it is necessary to sacrifice a young goat to your SCSI chain now and then.
-- John Woods
This is, of course, an exaggeration. I don't know why these guys were
fixated on goats -- a chicken will do just fine. On a more serious note, the
amount of work that goes into this is not inconsiderable. On one of my Sun®
3/80 systems, I could run a hard drive with no termination in one drive bay or
with inline termination (between the drive and the board!) in the
other. I still have somewhere six different 25- to 50-pin SCSI cables of
which exactly one allowed me to use my SCSI tape drive and external SCSI disk
at the same time on an old Amiga.
Modern SCSI is dramatically more stable. Low-voltage differential (LVD)
cabling and cards which can perform "automatic" termination solve a great
number of problems. Nonetheless, I still have a drawer full of "passive" and
"active" terminators, inline terminators, and SCSI cables (each of which I
think is particularly lucky -- it never hurts to have a charm).
SCSI termination problems are often cited as a reason to prefer other
protocols, such as ATA/IDE, but in practice, mention of these problems mostly
only comes up when an SCSI chain is doing something (such as connecting seven
devices) which ATA can't even dream of doing.
SCSI over other wires
Using the SCSI specification to describe messages which are then transmitted
atop other protocols -- such as the USB mass storage specification, the ATAPI specification, or
even FireWire -- shows something important about standardization: The world
really did need a specification for some of the common tasks of disk access.
The decision in SCSI-3 to provide multiple distinct components of the standard
made it possible for people working on other standards to incorporate useful
bits of the SCSI design. This is the essence of standardization in its
finest example: Not only do people use the SCSI standard to make SCSI devices,
but they also use it to make other standards more compatible with each other!
The ATAPI specification is essentially a way to send SCSI packets over an ATA bus,
providing an SCSI interface to devices, most often CD drives or tape drives.
Some operating systems just provide an SCSI interface to these devices, and
others provide it as an emulation layer. The ATAPI/SCSI emulation layer is
particularly crucial to such things as programs that wish to talk to a CD or
DVD burner.
Not everything that uses the IDE bus talks SCSI. Most ATA disks use the
somewhat simpler (and less flexible) ATA specification instead. At least one vendor
has produced an IDE tape drive using an entirely custom protocol --
annoyingly, the vendor has advertised it as "ATAPI" even though it isn't.
Still, most vendors have played nice and ATAPI has offered a single stable
interface to a broad variety of devices.
The SCSI protocol is used for USB mass storage devices, too. This has had
the effect of resurrecting the LUNs (which have otherwise been fading into
obscurity). I have a card reader which reads a reasonably broad subset of the
currently available varieties of flash memory. It has four slots (allowing it
to read something like eight varieties of memory) which show up as four SCSI
LUNs over a standard USB mass storage driver. This is an excellent example of
what SCSI LUNs were supposed to be used for, and it's nice to notice that
they're still being used.
Another good example of using the SCSI protocol is iSCSI, which uses TCP/IP
transport to move SCSI commands around. Once again, the SCSI protocol is
being used because it gives a good, standardized way to interact with devices,
especially disks. Some vendors aren't so hot on this idea -- SCSI's design
isn't a perfect match for the performance characteristics of TCP/IP, but it is
a good illustration of the way in which protocol and electronic specifications can be
separated.
Non-disk SCSI devices
Time and time again, people forget that SCSI was ever used for anything
but disk drives, but one of the strengths of SCSI was its comparatively high
speed. Until USB 2.0 and FireWire came on the scene, nothing else (except
maybe fiber channel which the consumer market reasonably chose to disregard)
was even close. This speed led to using SCSI in scanners since they tend
to ship a lot of data around. Given that a scan of even a single 35mm slide
could easily run to 16-plus megabytes of data, the ability to move that data
quickly matters.
Furthermore, the SCSI protocol does a lot of the low-level work for such a
device. A vendor using SCSI didn't necessarily need to reinvent the entire
communications protocol. (Many scanners used an additional driver layer
called TWAIN which provided a consistent interface to scanner capabilities.)
Musical hardware has a disproportionate tendency to support SCSI. This
might have something to do with the popularity of Macintosh hardware among
musicians since SCSI was more widely available than say, parallel ports. The
SCSI performance was another important consideration since moving a 30-second
CD-quality sample over a serial port line is just plain painful.
Finally, remember that the computer itself is just
another SCSI device. While convention dictates that the computer be at SCSI
ID 7, some systems allow this to be overridden. Multiple systems sharing a
single disk can be risky or confusing -- but when disks were expensive, this
scheme could be worth it.
Multiple systems sharing a disk but only reading from it is another
possible use. Some of the larger Xerox printers had support for sharing a
disk with a workstation; this could deliver huge print jobs to them quickly
and reliably.
Cost, performance, and reliability
The cost of SCSI disks reflects both economies of scale and the economic
reality -- server hardware can cost as much as it wants to. Not that long
ago, there were disks where the IDE and SCSI versions of the same disk were
the same hardware with a different controller card bolted on. The SCSI one
might well cost more -- and might come with a better warranty -- but this is no
longer the case.
For comparable amounts of money today, you can get a 73 GB SCSI disk or a
250 GB IDE disk. SCSI disks have rigidly stuck to a progression based on 4.5
GB disks; 9 GB disks led to 18, 36, and 73 GB disks. (Expect some rounding
error.) Costs are generally higher than typical consumers are willing to pay,
and an SCSI controller can easily cost five times what an IDE controller would.
On the other hand, IDE controllers tend to be 33 MHz, 32-bit PCI devices, while
SCSI controllers are often designed to work in 66 MHz, 64-bit slots.
The fundamental issue here is obviously not the performance of a single
disk; disks don't generally provide 320 MBps of bandwidth. However, server
systems might well have a half-dozen disks or more striped together into giant,
fast RAID systems. This makes "IDE RAID controllers" seem sort of like a
joke.
In short, SCSI users today are generally paying a premium for performance.
While IDE has improved dramatically from the days of CPU-intensive polling,
it's still really not trying to compete with the bandwidth or features of
SCSI. SCSI disks take command queuing for granted, and toggling support for
this feature makes a noticeable difference. SCSI systems are designed to
support six or more disks, all pushing data as fast as they can; IDE
controllers are limited to two disks per "channel" and generally don't put as
much work into bus arbitration.
Summary, looking forward
The irony of the SCSI acronym has become fairly pronounced, as even Apple
and Sun have stopped using it except on high-end servers. An interface
originally intended to make hobbyist computers and personal desktops more
affordable has ended up being most used on server systems and high-end
workstations -- "small" computers are not the ones using this systems interface
today.
The SCSI specification though, deserves a lot of credit for bringing stability to
the peripheral market. SCSI introduced the concepts and technology that make
many devices, even some using other busses, compatible and efficient. The SCSI
standard is still usable a full 25 years after the first development work on
it; very few computer standards can make that claim. This reflects not only
the technical merit of the standard, but the obvious benefit to everyone
involved of having a unified standard for device communications.
The SCSI protocol will probably be with us for a long time. The hardware
specification seems to be holding its own just fine in the high-end, high-performance
hardware arena, and some users (myself certainly among them) will continue
building machines with SCSI disks to get noticeably better performance under
load.
You can still use SCSI on a desktop, and if you've got a lot of disk
activity going, it's probably worth it. If you want something bigger, maybe a
mainframe or even just a high-reliability server, SCSI is still your best
choice.
Resources
About the author | 
| | Peter Seebach has a fine collection of ancient SCSI drives which he believes probably still have a few files he can't find. He will eventually
look through them all. |
Rate this page
| 
