burr@nbsvms (BURR, WILLIAM) (07/11/85)
Folks around here who follow info-micro have recently
given me copies of netmail with questions and answers on various interface
standards, some with incorrect or at least incomplete information. I am
chairman of X3T9.2, the SCSI committee and vice-chairman of its parent committee
X3T9. I am pretty much aware of everything going on in what is called,
somewhat improperly, "ANSI" interface standards activity, as opposed to
IEEE activities, which I try to track but do not participate in. In general,
the IEEE does backplane bus standards and X3T9 ("ANSI") does peripheral device
interface standards. At any rate what follows is my attempt to set the record
straight on some of the things I've seen discussed.
First X3.80-1981, the Flexible Disk interface standard is more or less current,
and the only problems with it at the moment involve the new 1.6 Mbyte 5.25"
drives, some of which use one or two lines a little differently than other
5.25" drives. X3T9.3 is considering what to do about the new drives.
The other two published ANSI interface standards are X3.91-1982 for Storage
Module Interfaces, which is being revised to accommodate the new SMD drives
which transfer at rates above 9.67 MHz, and X3.101-1984, "Interface Between
Rigid Disk Drive(s) and Host(s)," sometimes advertised as the "ANSI"
interface (I do not recommend its use on the pragmatic grounds that it
hasn't much cought on). All of these are device level interfaces, rather like
ST506 or ST412, for which there is, regrettably, no published standard.
All can be ordered from ANSI, 1430 Broadway, New York, NY 10018.
There are a large number of interface standards under development at the moment
in various X3T9 Task Groups including:
Intelligent Peripheral Interface (IPI) - This addresses large,
high performance disk and tape drives, cpmes in several (too many)
flavors, and is really an updated version of the IBM I/O channel, getting
more than twice the transfer rate through half as many wires. Products
are not yet available, but it's pretty clear that they will be.
Fiber Distributed Data Interface (FDDI) - This is a 100 Mbit/s
fiber ring, smilar to IEEE 802.5, but ever so much faster. Support for it
is very broad and it looks like it will be possible to accommodate both
data communications and telephony on it gracefully. Expect products
in about 3 years.
Local Distributed Data Interface (LDDI) -This has now become
a formalization of a DEC interface, the CI, a 70 Mbit/s passive star broadcast
network with a 45 m radius. It is what makes a VAXCLUSTER work. There are
something over 2000 of them now installed. The real issue here is will DEC
throw in MSCP and SCS, the higher level protocols used by the network, and
particularly file servers?
Device Level interface for Straeming Cartridge and Cassette Tape
Drives - This is an 8-bit parallel interface for up to 4 small streaming
tape drives. I believe that it is loosely decended frome something called
QIC-02.
Small Computer System Interface (SCSI) - This is an 8-bit parallel
bus for attaching small computers to intelligent storage peripherals (ie
peripherals with built-in controllers) and each other. The ANSI standard
will be X3.131 and will probably be published in 1986. Most of what follows
is about SCSI.
There is no entirely clear distinction between SASI and SCSI. The SCSI or
Small Computer Systems Interface is derived from the SASI or Shugart Associates
System Interface. When we set out to do an ANSI standard based upon the SASI
the first thing we did was change the name, for obvious reasons. It did
not occur to any of us, who debated the choice of names for an afternoon,
that SCSI would be pronounced SCUZZY. When several months later someone noticed
this, the marketing types were horrified, but by then we were stuck with the
name and it doesn't seem to have hurt.
I digress. The point is that there is no specific, clear distinction between
the two, and the choice of names is a marketing decision. In
many cases, however, manufacturers do try to distinguish between those products
which implement only the most basic functions, or which do not conform to the
proposed standard at all, calling them SASI, and those which implement more
functionality, calling them SCSI. In general, though the very earliest
SASI documents apparently included arbitration, people frequently use the term
SASI to denote a peripheral or host adaptor which does not do arbitration,
and in some cases may not be able to coexist on the same bus with devices which
do arbitrate. There are, I'm told, some SASI devices which don't coexist with
much of anything else, which is OK I suppose, as long as you use the bus as a
dedicated point-to-point connection. This undoubtedly is the case in many SASI
applications.
Any device which calls itself SCSI may or may not be capable of arbitration and
disconnecting during long latencies, but at least should co-exist on the bus
with other bus devices which do arbitrate, disconnect and reconnect. SCSI
host adaptors also may or may not implement arbitration, and, if not, should not
be used in multihost buses. The logic for this (other than to do otherwise
would antagonize vendors with existing products) is simply that many, perhaps
most, applications of SCSI involve a single host adaptor and only one or two
peripheral devices. There is no reason to arbitrate, disconnect and reconnect
in such systems, and some cost (small with VLSI) to doing so. With the
apperance of commercial LSI SCSI interface chips, such as the 5380 and 5385,
the cost of arbitration, etc. is nearly nothing and I expect that before much
longer most SCSI products will do arbitration.
While there are a number of SCSI options involving the bus (single-ended
vs differential, parity, arbitration, etc.) which can confound plug and play
interchangability of peripherals, I believe that the LSI parts will soon
relieve many of these problems and whether a product arguably meets the letter
of the standard or not, it will be perceived as incompatable if bus level
incompatabilities exist with the 5380 or 5385 and other forthcoming variants.
The real problem is command sets. The standard is more a "catalog" of commands
and options, than a real standard. The probability that a BIOS level driver
written for one SCSI disk drive will work with another drive from another vendor
is not high, even though the host adaptor and all the drives use the same
SCSI interface chip. Except for emulating host adaptors (ie those which
pretend to the host system to be some native peripheral) it will almost always
be possible to write a driver which runs the new device, but most of us
don't want to write a new driver every time we buy a new peripheral.
This doesn't deter some OEM's very much, who make their living integrating
devices, host adaptors, controllers and the like, but it does reduce the utility
of the interface for end users. It also is a problem for system houses who
want to use drives from a number of suppliers, and who may not wish to maintain
a different driver for each drive model they might use. There are INQUIRY
commands which, in principle, allow a driver to find out what the drive
does or doesn't do, but their use is spotty and I'm not aware of any broadly
selfadapting driver software. The promise is there but it is as yet largely
unrealized. The standard also reserves a lot of "Vendor Unique" code points,
and the use of these can really confound drivers. The FORMAT command is
a particular problem, because there are so many variations on how drives
are formatted.
Well this is not an entirely accaptable situation. End users don't have
too much direct leverage in standards committees (even when they are, as
I am, the chairman), because the drive and controller makers, who really
initiate the standards, don't much sell to end users. The system houses
do, however, and they want second sources. Drive and controller vendors
then find that they have to be compatable with others, or its hard to sell
the product, a fact which is often overlooked in the rush to get there
first with a product. System houses don't make interface commitments until
long after drive and controller houses, and the first thing they discover
is all the incompatabilities. Then they finally show up in the standards
meetings to complain. They're finally showing up in some force, and
the drive vendors are starting to realize that a higher degree of compatability
is a real market advantage. There are two really good things about the
SCSI community: (1) with the exception of Big Blue, practically everybody
who is anybody in the US, Japan and Europe is now using or planning to use
SCSI in their small computer products, and many are joining the committee, and
(2) the SCSI committee (X3T9.2) has been and is a surprisingly accommodating
group, with more cooperation and give and take than I've seen elsewhere
in similar efforts. We now have an intensive if informal effort under way
to define a "common command subset" for disk devices.
Hopefully this will be resolved before our August meeting; we hope
to forward our draft standard (for the second time) for further processing
by X3 as a draft proposed American National Standard by our October meeting,
and to publish the first version of the ANSI standard in 1986. We won't
be done then, however. People are already jumping out of the woodworks with
proposals for up to 64 devices, a 16-bit transfer path, and new device types,
such as network gateways, optical scanners and so on. We really need to
get something published, however, because the demand for copies can hardly be
met by the informal distribution of drafts, and literally hundreds of companies
are now building products to those drafts, often many revisions out of date.
I would be interested in reports on the ease or difficulty of integrating
various SCSI products in small computer systems. I cannot, however, provide
comments on the quality of various products, nor, usually, upon who makes
what, because it would violate NBS policy (we don't intend to become a
competitor to Consumer's Reports).
The current draft is Revision 15 and Revision 16 is on the way. The big
difference will be the inclusion of a second, shielded connector, called
a miniature ribbon, or sometimes a "Centronics" type connector.
We hope Rev. 16 will be the draft that ANSI publishes.
You can order a copy of Rev. 15 from:
X3 Secretariat
CBEMA
311 first Street, N. W.
Suite 500
Washington, D. C. 20006
Just ask for "SCSI," not X3.131, which is still officially Rev. 14B.
Anyone working to any revision earlier than 13 should definately get
a new copy. The price is $20.
I will try to answer interface standards questions sent to me. Please be
patient, I travel a lot, and may therfore not log on for weeks at a time.
My address is BURR@NBS-VMS-VGR.ARPA.
------