Programmer 7500/MAX_PROGRAMMERS.iso/PROGRAMS/UTILS/HARDWARE/ESDISCSI.ZIP/ESDISCSI.TXT

Text File | 1989-10-23 | 28.9 KB | 513 lines

     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.

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