Disk Interfaces for the High End
PC Tech Journal - v7 n2 p76 February 1989
by Peter G. Aitken

---------------------------------------------------------------------------

A 25-MHz, 80386-based system without the right peripheral interface is just
a fast machine spinning its wheels. Two hard-disk interfaces, ESDI and
SCSI, keep pace with today's high-end machines. You can get ahead of
yourself more quickly in computing than most any field. No sooner do you
upgrade one component in your system--just to keep stride with the
industry--when another appears miserably slow by comparison. So it goes.

When the IBM PC/XT was introduced in 1983, its 10MB 100-millisecond hard
disk was a marvel of technology, with unheard-of storage capacity and
speed. The hard disk connected to the PC's 8-bit bus (which ran at a
"blazing" 4.77 MHz) via the popular ST-506 hard-disk interface developed by
Al Shugart of Seagate Technologies.

Technology has progressed such that ST-506 no longer keeps pace with
high-end systems. Two interface standards have supplanted ST-506: the
enhanced small device interface (ESDI) and the small computer systems
interface (SCSI). Both are considerably faster, and each has
characteristics that recommend it for certain configurations.

During its tenure, ST-506 was more than adequate for the job. In fact, the
ST-506/disk combination transferred data much faster than the computer
could process them. This forced hardware designers to reduce the hard
disk's data-transfer rate by formatting it with an interleave factor of 6,
thereby synchronizing the transfer rate with the host system's processing
speed. The effective transfer rate was approximately 85KB per second
(KB/s).

Computer hardware engineers simply have a penchant for making things go
faster. They soon produced faster (and larger) hard disks, with typical
access times of 40 ms, and faster computers--the PC/AT came out of the gate
in 1984 running its 16-bit bus at 6, then 8 MHz. Yet, the ST-506 interface
was still up to the task, achieving data-transfer rates of about 165 KB/s
in an AT, roughly double that in an XT.

Enter the 80386 in 1986 and, not long after, a rush of 20- and 25-MHz
computers, with hard-disk access times in the teens of milliseconds. Now
an ST-506 interface creates a serious data flow bottleneck because its
maximum data-transfer rate is significantly slower than the throughput
capacities of the disk and the computer. Some manufacturers enhance ST-506
performance with faster transfer speeds and run length limited (RLL) data
encoding to increase data density on the disk. Nevertheless, inherent
ST-506 limitations (primarily its slow transfer rate) make enhancing its
performance impossible for today's high-end systems.

Not surprisingly, 1986 also saw the establishment of ESDI and SCSI.
Together, they have almost completely displaced ST-506 as the interface of
choice for network file servers and other high-performance applications.
Most high-end PC systems are available with ESDI controllers as standard
equipment, and many vendors offer both ESDI and SCSI hard-disk systems as
upgrade units.

These two interfaces are superior to ST-506 primarily in their high
transfer rates--about an order of magnitude faster. The maximum







data-transfer rate of a hard-disk system is limited by the rate that data
pass the read head, which is a function of two factors: rotation speed and
recording density. All 5.25-inch hard disks rotate at 60 revolutions per
second. ST-506 disks use 512 bytes per sector and 17 sectors per track.
The result is a best-case transfer rate of (60*512*17*8) or 4,177,920 bits
per second. Higher rates can be obtained by increasing either the sectors
per track or the sector size. However, ST-506 is further limited because it
is designed to transmit data at 5 megabits per second. With transmission
rates of 10 megabits per second and higher, ESDI and SCSI can exploit
higher recording densities.

The ESDI specification describes the electrical and physical interface
between a disk controller and an external-storage device, as shown in
figure 1. ESDI covers neither the communications between controller and
host system nor the details of recording data on the external device.

In contrast, SCSI defines a system bus for data transfer between a host
system and several external devices, each with its own controller (see
figure 2). Besides the electrical and physical characteristics of this
bus, the SCSI specification defines a set of commands through which devices
on the bus communicate with each other. Like ESDI, SCSI leaves open the
details on both ends of the connection--how host software communicates with
the SCSI adapter and how the individual controllers implement the commands
they read from the bus.


CONTROLLING WITH ESDI
The ESDI specification merges three narrower specifications: the enhanced
small disk (magnetic) interface, the enhanced small tape interface, and the
enhanced small disk (optical) interface. As an ANSI draft standard, it is
circulating for comment before final approval.

ESDI interfaces the computer's bus to a specific hardware device, which can
include magnetic tape, optical hard disks, printers, and
host-communications adapters, as well as magnetic hard disks (considered
here). Controller circuitry is located on the host adapter, which is either
on a circuit board plugged into an expansion slot or incorporated onto the
system board. One controller board controls as many as seven disk drives.

Physical connections between controller and drives consist of two cables
that carry data and control signals. A 20-conductor data cable is
connected radially, a separate cable going to each drive; a 34-conductor
control cable is daisy-chained from drive to drive. Maximum cable length is
3 meters. Data are transmitted serially over two pairs of differential
signal lines, one pair for each direction.

The controller exchanges control and status information with the disk in
two ways. In the first, the controller activates the appropriate dedicated
control lines: 15 in the control cable (10 sending requests from controller
to drive, 5 from drive to controller), plus 5 in the data cable (1 from
controller to disk, 4 from disk to controller).

In the second, the controller sends command words via the serial command
data line in the control cable. Some commands request status from the
disk, which is transmitted serially back to the controller on the
configuration/status data line. All commands and responses are 16 bits,
plus 1 parity bit. Only 11 commands are available, two of which request a
response from the disk (see table 1). Host software never directly issues
these commands nor sees responses.







Actual data are transmitted serially between controller and drive at the
rate of the read/write clock (currently specified as 10 MHz). Assuming an
average 10 bits per data byte (allowing for error correction and address
data), this produces an effective transfer rate of about 1MB per second
(MB/s).

The controller specifies the location of data to be read or written by
physical address consisting of cylinder number, head number, and sector
number. As shown in table 2, the number of bits and signal lines available
to specify the various components of the address allows a maximum
theoretical capacity of one terabyte (1TB--that is, 240 bytes, or 1 million
megabytes). The limitations of the host system, however, can impose
different limits on the device. For example, DOS and OS/2 require a sector
size of 512 bytes, cutting the maximum capacity by a factor of eight, to
"only" 137GB.

The focus of ESDI is quite narrow. It leaves many details on both sides of
the controller-disk interface undefined, most importantly, the software
interface between host and controller. Implementors can choose different
command structures, so that two ESDI controllers are incompatible at the
software level. The device drivers, whether in ROM BIOS or in RAM, must
adapt different devices to an operating system.

For example, the host command structure for the ESDI controller in the IBM
PS/2 Model 70 (for both 60MB and 120MB disks) specifies disk locations in
terms of 32-bit logical sector numbers, rather than cylinder, head, and
sector. The host-controller interface can restructure the drive into
logical dimensions that differ from the physical ones. More specifically,

the 120MB disk on the PS/2 Model 70-121 has 920 cylinders, 8 heads, and 32
sectors per track. DOS, however, reports the disk as having 115 cylinders,
64 heads, and 32 sectors per track. Each logical cylinder, therefore,
contains exactly 220 bytes (1MB), making it easier to specify partition
sizes in cylinders when partitioning the disk with FDISK.

On the other side of the controller, the ESDI specification does not
mandate the actual recording methodology, redundancy for error recovery, or
format of sector address marks. Within the controller itself, the standard
makes no requirement for buffering or error correction. An original
equipment manufacturer (OEM) can provide a design for these aspects of the
disk subsystem. Thus, the range of possible implementations of an ESDI
disk subsystem is quite broad, with a corresponding spread of performance.


SCSI CONNECTIONS
The SCSI specification, defined by ANSI standard X3.131-1986, grew out of
the earlier SASI (Shugart Associates System Interface) developed in 1979 to
connect 8-inch Winchester disk drives to microcomputers. It since has been
enhanced to control tape drives, printers, coprocessors, and optical disks.

SCSI is not a device interface, but rather specifies the physical and
electrical characteristics of a bus for interconnecting several
peripherals, a set of commands for controlling them, and a protocol for
arbitrating contention and controlling communications among them. The bus
is a 50-conductor cable that daisy-chains as many as eight devices. The
maximum length between devices is 6 meters if the cable is wired with
single-ended signal pairs (one wire of each pair grounded) or 25 meters
with differential signal pairs (complementary signals on the wires of a
pair). The current SCSI standard specifies an 8-bit data width within this
bus; the proposed SCSI II specification expands this to 32 bits (see the
accompanying sidebar, "SCSI II is Due").






Each device on the bus is an initiator that makes requests of other devices
(for example, a host computer), a target that carries out the request (for
example, a disk drive), or both (for example, a coprocessor that responds
to the CPU and requests services from disk or memory subsystems). An
initiator connects to the bus through a SCSI host adapter, which, like a
device controller, is either plugged into an expansion slot or built onto
the host system board. Each target device consists of a SCSI peripheral
adapter, a device controller, and as many as eight peripherals. One SCSI
bus thus connects a single host to as many as 56 peripherals.

Only two devices can communicate over the SCSI bus at one time. An
initiator must wait for the bus to be free before taking control; if
several initiators request the bus simultaneously, the one with the highest
priority gets it (priorities are fixed at installation time). A
higher-priority device cannot preempt the bus; the priorities matter only
in arbitrating multiple requests when the bus is free. In systems with
only one initiator, the host interface can be configured without this
arbitration logic.

Once the initiator controls the bus, it establishes communications with a
target device by means of hardware handshake lines, then gives the target
control. Thereafter, the target controls the transfer of all data on the
bus: it requests the commands from the initiator, indicates when it is
ready to send or receive data or send status information, and frees the bus
at the completion of the command. In a system with bus arbitration
enabled, the target can release the bus before the completion of the
command (for example, during a disk seek), then request the bus, as if it
were an initiator, when the time-consuming operation ends.

The default data-transfer protocol on the SCSI bus is asynchronous, in
which the target and initiator exchange a request/acknowledge handshake for
each byte of data transferred. In this mode, the transfer rate is about 1
MB/s. Manufacturers can configure devices to support a synchronous protocol
that sends data bytes at fixed intervals without handshaking; this method
achieves a rate of 3 to 4 MB/s.

A large portion of the SCSI standard describes the command set that the
initiator uses to request services from the target. Table 3 lists the
commands for read/write disk drives. For each type of device, the commands
divide into four types: mandatory, extended, optional, and vendor-unique.

All SCSI implementations must support mandatory commands. The extended
command set supports devices of higher capacity and enables
self-configuring software drivers dynamically to determine the
characteristics of extended-mode devices. Optional commands add
functionality but are not required for conformance to SCSI. The standard
does not specify vendor-unique commands, but manufacturers can define them
as appropriate.

The data space of a SCSI device is organized logically as a linear array of
blocks. Data-transfer commands specify a logical block number and the
number of blocks to transfer. The mandatory set of commands allows 21 bits
for the block address (about 2 million blocks) and 8 bits for the block
count; the extended set uses a 32-bit block address and 16 bits for the
block count. The maximum length of a block is 16MB in the mandatory set
and 4GB in the extended, yielding theoretical maximum capacities on the
order of 1012 and 1018 bytes, respectively. The realities of host software
on one end and peripheral construction on the other limit actual
capacities. APPLES AND TENNIS BALLS Comparing SCSI with ESDI is like
comparing apples with tennis balls. SCSI is not a hard-disk controller,






but rather a bus, with a command set, that connects a computer to the
actual hard-disk controller located on the peripheral, which
could--theoretically--be an ESDI controller. The two standards were
designed for quite different purposes.

When selecting a high-performance, hard-disk system, your choice will be
between ESDI and SCSI. Hardware specifications, such as data-transfer
speed, are only part of the comparison. The choice of interface affects
system design in many other ways.

The maximum data transfer rate of an interface is the fastest rate the
interface transfers data between the computer and the hard disk under ideal
conditions--that is, when neither the computer nor the hard disk slows the
system down. In this measure, ESDI and SCSI are, for all practical
purposes, equivalent. Current implementations of both operate at 10 MHz,
or 10 million bits per second (Mbps), which, at 8 bits per byte, translates
to 1.25 MB/s. Not all of these bytes are user data, however (some are error
correction code and address marks), so these speeds trans- late into a
maximum data-transfer rate of just less than 1 MB/s.

Accessing a hard disk involves more than the data transfer itself. The
interface must translate commands from the operating system or application
program into signals that control the hard-disk hardware. With ESDI, this
is a one-step process performed by controller circuitry on the host
adapter.

SCSI, on the other hand, requires two steps. First, the host adapter
converts the operating system commands to SCSI bus commands. Then, the
circuitry on the hard disk converts the SCSI bus commands to hard-disk
control signals. This SCSI processing overhead gives ESDI the edge in raw
transfer rate; thus, other factors being equal, ESDI takes slightly less
time to read or write a given disk file.

SCSI, however, offers its own benefits. Two advantages result from its
configuration, which places separate controller circuitry directly on each
hard disk (or other peripheral). For one, the developer can select the
best controller design for each drive, rather than relying on a generic
central controller that might not match exactly the characteristics of
different drives. For another, the data lines between controller and drive
are less subject to noise because they are so short.

A more fundamental SCSI advantage is that, for a high-level subsystem, it
has a fair amount of stand-alone intelligence. The command structure
permits fairly complex transfers between SCSI devices on the same bus, once
started, to proceed without the host intervening further. Thus, a hard
disk can be backing up to tape while the computer goes about other
business; or transfer requests can be given some priority other than
arrival time, so that a lengthy transfer could be interrupted to perform a
shorter one.

Another SCSI advantage is that it connects as many as seven targets to a
single SCSI host adapter. The daisy-chain configuration makes cabling
relatively simple. Theoretically, any SCSI device can connect to a SCSI
port; this includes hard disks, tape drives, CD-ROM players, scanners, and
write-once-read-many (WORM) drives. Devoting one precious expansion slot
(are there ever enough?) to a SCSI host adapter is an exceptionally
effective way to maximize the unit's expansion capabilities. If you are a
real peripheral hog, you can put as many as four SCSI host adapters in one
system unit.







Although the ESDI specification allows for devices other than hard disks,
and for connecting as many as seven devices to one controller, all current
PC implementations are limited to two hard disks (for no particular
reason).

On the surface, SCSI seems to be the hard-disk interface of choice for all
systems except single-user configurations in which every iota of hard-disk
speed is more important than expandability. This conclusion is justified if
based solely on the idealized specifications and abilities of each
interface.

Developers and integrators know, however, that a functional system is not
constructed out of idealized specifications. The realities are what is
commercially available, how much it costs, which system software it works
with, and so on. In the real world, an intelligent choice of hard-disk
interface is more than simply choosing between ESDI and SCSI on the basis
of design; other factors are involved.

To digress momentarily, the ST-506 interface is relatively simple and has
been around for many years. Standards have evolved, so when you purchase
an ST-506, you know exactly what you are getting. One manufacturer's
ST-506 controller will work with a variety of hard disks--witness the many
Adaptec, Western Digital, and Xebec controllers that run CDC, Miniscribe,
Rodime, and Seagate disks in millions of XTs and ATs. With the new
interfaces, however, a vendor must design an ESDI or SCSI drive integrally
with its interface.

An ESDI or SCSI hard-disk system consists not only of the host adapter and
the hard disk; software drivers are also essential components. The sheer
complexity of ESDI and SCSI makes it tricky for all of this hardware and
software to work together smoothly.

The software drivers must work smoothly with the operating environment. A
mass-storage system that works perfectly well with 3Com might not work with
Banyan because software drivers are not available. For OS/2, BIOS drivers
burned into on-board ROM are useless; a disk system needs protected-mode
drivers implemented either in IBM's ABIOS firmware or entirely in software.

Besides the potential problems with systems software, the question of
compatibility with applications arises, especially disk utilities. No
problem should arise where these utilities limit disk access to methods
officially sanctioned by the operating system or at least the BIOS;
however, programs behave differently. A benchmark that times
track-to-track access could produce unexpected results if it steps by
logical tracks and if the logical track does not correspond to a physical
track. (In the 120MB ESDI disk of the PS/2 Model 70-121, when the software
driver steps by one track, the read/ write heads move across eight physical
tracks, understating this aspect of the disk's performance by a factor of
8.)


MORE TRADE-OFFS
Various factors give the cost advantage to ESDI. To be specific, three
fundamental aspects of the SCSI design combine to increase its cost over a
comparable ESDI installation. One factor was listed above as a SCSI
advantage: the SCSI intelligence. In the digital world, more intelligence
means more logic elements, and more logic elements mean more chips, more
printed circuits, and so on, all of which add to the cost of a system. The
second factor is a direct result of SCSI being an independent bus rather
than a device-specific interface. This means that each computer-peripheral






link contains two separate interfaces, one between the computer's bus and
the SCSI bus, and one between the SCSI bus and the peripheral controller.

The third factor has to do with internal versus external mounting of
peripherals. ESDI hard disks are, almost without exception, mounted inside
the system unit where they share its case and power supply. SCSI hard
disks can be mounted internally, but external mounting is necessary to take
advantage of the interchangeability of SCSI peripherals (which is, after
all, one of its selling points). An external peripheral must have its own
case and power supply; this adds to the cost.

Planning ahead can impact overall cost effectiveness. For a two-disk
network file server that will be locked in a closet for the next five
years, ESDI interface disks may indeed save money. If, on the other hand,
you are designing networked workstations for a growing firm, spending a
little more on SCSI now can save money down the road when your client adds
scanners and optical drives to each station.


PROMISES, PROMISES
In evaluating either interface, deal with the reality of available hardware
and software and not just with the promise of potential capabilities.
Fully documented ANSI standards exist for both; however (and this is
particularly true for SCSI), the standards are very flexible. Different
implementations can exist, all of which adhere to published standards, but
none of which is completely compatible with the others.

One of SCSI's strongest selling points is the ability to plug any SCSI
peripheral into a SCSI host adapter and be off and running. Thus, not only
can you attach as many as seven target devices to a single SCSI port on
your PC, but also, theoretically, you can move a SCSI hard disk and its
data between computers--and not just from PC to PC, but from PC to
Macintosh, PC to VAX, and so on.

This connection between computers, although true in theory, is not
necessarily so in practice, for two reasons. First, SCSI buses come in two
different flavors--single-ended and differential. Second, the command set
is so loosely defined that any manufacturer can radically redefine it by
implementing a set of unique commands. You cannot assume that a SCSI
peripheral from one vendor will function on a SCSI host adapter from
another vendor.

If you are planning to hang a lot of different peripherals on your SCSI
port, look for a vendor that supplies not only the host adapter, but all
the peripherals you need as well. Purchasing all components from one
vendor minimizes incompatibilities. Price, in this situation, becomes a
secondary consideration. If you do mix hardware from different vendors, be
sure to test for compatibility.

Speed improvements are imminent for both interfaces. SCSI chip sets with
double and quadruple the transfer rate of current hardware are currently in
the prototype stage, as are ESDI controllers that operate at 15 MHz and 24
MHz instead of the current 10 MHz.

Which is better, ESDI or SCSI? A definitive answer is impossible. A look
at what the industry is doing is no help either--it is a mixed bag. Some
manufacturers supply only one type or the other, but most supply both,
indicating that the market has shown no marked preference for one or the
other. Selecting a high-performance, hard-disk interface is not as simple
as deciding between ESDI or SCSI. Developers must determine which specific






mass-storage implementation will work best in an individual operating
environment, including the hardware, the network, the operating system,
plans for future expansion, and so on. No simple task, but then, progress
and simplicity seldom go hand-in-hand.

---------------------------------------------------------------------------

SCSI II IS DUE
An ANSI committee is currently working on the final draft of the standard
for SCSI II, known officially as X3T9.2/86-109. ANSI intends for this new
standard to remain hardware- and software-compatible with the cur- rent
SCSI standard (SCSI I), while at the same time offering dramatic
improvements in speed and capabilities. One indication of the magnitude of
changes suggested to the current standard is the sheer size of the draft
document--more than 500 pages, compared with 212 for SCSI I.

In SCSI II, major hardware changes are made in the bus width and maximum
data-transfer speed. SCSI II remains compatible with SCSI I's 8-bit data
path, but also offers 16- and 32-bit data paths. Maximum data- transfer
rate is increased to more than 10MB per second, up from 3MB to 4MB per
second, the maximum currently possible.

Another important addition is command queuing, which permits multiple
commands to be sent at one time to a single SCSI bus target. This saves
time because a device can parse a second command while the previous one is
executing. The new standard also contains a SCSI command set specifically
for CD-ROMs. These devices have been difficult to program because, unlike
disk drives, they do not have a consistent data block size. Other
improvements include enhanced automatic configuration capabilities and
improvements in the copy commands (which in SCSI I sometimes operate
improperly when copying between devices with different block sizes).

Many SCSI features that are now specific to particular implementations will
become part of the SCSI II stan- dard. Once the new standard is approved
and implemented, the industry will enjoy not only much better performance
but, perhaps more importantly, a much higher degree of compatibility among
manufacturers. If the present timetable is observed, final approval could
come as early as the summer of 1989. --Peter G. Aitken

---------------------------------------------------------------------------

Peter G. Aitken, Ph.D., is an assistant professor in the physiology
department at the Duke University Medical Center in Durham, North Carolina,
where he uses IBM PCs extensively in his research. As a freelance
consultant and programmer, he has written and marketed laboratory software.

===========================================================================