Back to the top of the comp.arch.storage FAQ.


8. (Device) Interfaces

There is a new web site with lots of info at www.cit.ac.nz (rdv, 96/2/21) Looks like it's class notes, so no idea how long it will stay up. Don't forget to see www.cmpcmm.com.


8.1. SCSI {Full}

SCSI is the Small Computer System Interface. It is standardized by ANSI X3T9.2. It is mostly aimed at storage devices, with command sets defined for disks, tapes, and autochangers, but also includes communications devices, printers, and scanners.

It's daisy-chained, with a maximum of eight devices (including the host computer) on a single narrow bus (there are non-standard schemes for 16 devices on a wide bus). Any device can be an initiator, so it's possible to use the bus for sharing devices between hosts, provided your software can manage it.

See also the newsgroup comp.periphs.scsi, especially for "How do I hook up a Brand X diskdrive to my Atavachron 9000 PDA?" type questions.

There is also an FTP site for some working documents for the SCSI-3 committees and other X3T10 documents. See ftp://ftp.symbios.com or ftp.hmpd.com.

You'll find good info at www.symbios.com and at www.scsita.com.


8.1.1. Single ended vs differential

This distinction is at the eletrical signalling level. However, single-ended is limited to total bus lengths of 6.0 meters, while differential can go up to 25 meters (SCSI-II). Differential is generally more robust to noise and cross-talk, but the bus drivers are more expensive. In theory no difference in transfer speed or capabilities, but in practice the added noise margin could mean higher _reliable_ transfer rates on your system, especially if your bus is long.

Most disk drives and most low-end products are available only with a single-ended interface. A few devices are available with either as a purchase option, and a few are switchable by the user.

The cables and connectors are the same for both, though the pinouts are (naturally) somewhat different.

Plugging a single-ended device into a running differential bus or vice-versa may result in damage to one or more devices. Most newer devices have fuses or protection circuits utilitizing the DIFFSENSE signal to prevent device damage.

There are now recommended icons used to distinguish between the two:


single-ended                    differential
  /\                             //\
 /  \                           //  \
<   --                         <<   --
 \  /                           \\  /
  \/                             \\/

Converters do exist that will allow you to hook up single-ended devices to a differential bus and vice-versa. People who have used them say they work great, but in theory they shouldn't work :-). As I understand it, changing the signalling introduces delays in some of the control signals that means that some devices could miss certain signal transitions. The best advice is to borrow one and try it, and see if it works in your system. One company's name is Paralan, (619)560-7266.


8.1.2. Asynchronous vs Synchronous Transfers

Asynchronous transfers mean that every single byte must be acknowledged before the next can be transfered. Synchronous means that the device sending data can drop a series of transfers onto the bus, toggling REQ or ACK (as appropriate), and then sit back and wait for the corresponding pulses to return from the other device.

Async transfers, involving much more waiting, are correspondingly slower. 2-4 MB/sec are good values for async transfers.

Sync transfer speeds are established during a negotiation between the initiator and target, but devices are not required to use the full speed they negotiate for. This speed represents the maximum burst rate your device will use. Common values are 5 and 10 MB/sec.

In practice, virtually every modern device supports synchronous transfers, but some implementations are better than others.


8.1.3. SCSI-I vs SCSI-II vs SCSI-III

SCSI (now commonly known as SCSI-I) was the original 1986 standard, X3.131-1986. It specified the electrical level and some of the mid-layer issues involving messages and packet structure, but (I believe, my memory's bad) didn't formalize the Common Command Set (CCS), that was done independently. It supported a maximum burst rate of 5 MB/sec. on an 8-bit bus.

ADDITIONAL INFORMATION

Consult the SCSI standards documents, and the manuals for the device you are working with for more information. The "SCSI 1" specification document is called SCSI Specification, ANSI X3T9.2/86-109. Also of interest is the Common Command Set specification document SCSI CCS Specification, ANSI X3T9.2/85-3

SCSI-II received final approval in early 1994, but has been a de facto standard for several years. The CCS was standardized for a variety of different types of peripherals. The max allowable transfer rate was raised to 10 MT/s (see below). A 16-bit bus (Wide SCSI) and 32-bit bus (double-wide SCSI) are specified (see below).

SCSI-III is the latest effort, and involves more cleanly separating the functionality into layers; the command layer is defined independently from the physical layer. In addition to the traditional parallel cable, there are efforts going on to define physical layers for Fibre Channel and a more generic Serial SCSI. Thus, there will be no SCSI-IV; only the individual pieces will be updated as necessary.


8.1.4. Fast-Wide SCSI

The max allowable transfer rate was raised to 10 MT/s (mega-transfers per second) in SCSI-2, referred to as Fast SCSI. Note that this is NOT required, devices running at ANY speed below that may claim to be SCSI-II compliant! Fast implies SCSI-II, not the other way around! Fast Narrow is thus 10 MB/sec. Both the initiator (computer) and target (peripheral) must support fast transfer for it to be of any use, but intermixing fast and slow devices on a bus presents no operational problems (only performance ones).

A 16-bit bus (Wide SCSI) and 32-bit bus (double-wide SCSI) are specified in SCSI-2. The wide busses require the use of a second cable in SCSI-2. The first cable is 50 pins, known as the A cable; the 2nd is 68 pins, known as the B cable. I know of no one actually using 32-bit SCSI, but it would also run on an A/B cable pair. Slow (or Normal) Wide is thus 5 MT/s * 2 Bytes/T, 10 MB/sec. Fast Wide is 20 MB/sec. Fast Double Wide would be 40 MB/sec.

In the SCSI-3 physical layer spec (SCSI-PH), a single 68-pin cable, known as the P cable, is allowable for 8 or 16-bit busses. This is the option most people who have implemented Wide SCSI have chosen for the cabling, even though their upper layer is generally SCSI-2.

There is a small movement (heard here on the net occassionally) to promote an Ultra-SCSI high-speed bus, with a burst rate of something like 20 MT/sec on very short cables. At present it is unclear what will happen to this effort. There is also talk, in conjunction with a change to low-voltage differential signalling, to go to 40MT/sec.


8.1.5. Shared Busses / Performance {Brief}

Also known as, "It's only a 500KB/sec. tape drive, why do I care if the burst rate is only 2 MB/sec.?" or gets good marks for "plays well with others".

Most of this is relevant to all shared busses, not just SCSI. burst v. sustained performance, disconnect, command overhead, etc.


8.1.6. Cabling/Hot Plugging {Brief}

Nominally not supported.


8.1.7. Third Party Transfers/Separation of Control & Data Paths {Brief}

SCSI-2 has commands that support third-party copying of data; one initiator tells device A to copy to device B. I don't know of any devices actually using this.

Separation of control & data paths is a popular topic these days; can somebody comment on whether or not SCSI-3 supports this? I don't think so. (SHMO)


8.2. IDE {Brief}

PC use Does not support overlapped I/O.


8.3. IPI {None}


8.4. HIPPI {Brief}

32-bit transfers at 25 MT/sec., 100 MB/sec. High Performance Parallel Interface is a unidirectional channel, i.e. you have to have an OUT cable and and IN cable for bidirectional transfers (you could have just one, if it's a read-only device like a scanner or write-only like a frame buffer). HiPPI is not a shared bus, but its frames can be switched through a crossbar switch (Network Systems is the premiere vendor).

HiPPI is used for supercomputer-to-supercomputer networking (TCP/IP, no less), for RAID arrays (from Maximum Strategy, IBM and others), tape drives (Sony ID-1 drive), frame buffers and increasingly workstations (SGI and IBM support HiPPI, and 3rd-party Sbus cards exist for Sun).

Due partly to the high overhead of HiPPI connections, many devices have elected to separate the control path from the data path. A common control path in that case is ethernet.

Good resources from the HiPPI Networking Forum on the web at www.esscom.com.


8.4.1. HIPPI-6400 {Brief}

An effort aimed at reaching 6400 Mbps (800 Mbytes/sec.) around the end of 1996.

From rev 0.15 of the HIPPI-6400-PH specification, dated March 4, 1996, ftp'ed from ftp.network.com.

Looks like the copper interface will be a cable with 44 micro-coax conductors, 22 in each direction. That's 16 data, 4 control, clock, and frame. A micro-packet is 32 data bytes and 64 bits of control information. I guess this means they're planning on 400 Mbps on each data line. The fiber variant uses 12 multimode fibers (in each direction, I presume, though it doesn't seem to say that): 8 data + 2 control + frame + clock, so presumably 800 Mbps on each fiber. Cable lengths in both cases TBD.


8.5. Ultranet {Brief}

Fiber to the host, a hub with a backplane running at a total rate of ~1Gbps.


8.6. Ethernet {Brief}

Generally related to normal inter-host networking, but also used as a control path for some HiPPI devices. Ampex also uses NetSCSI over ethernet to control their autochangers. Also, obviously, used for connecting many servers to their clients. Standard today is 10 Mbps, 100 Mbps (fast ethernet) is becoming more common.


8.7. FDDI {None}


8.8. Fibre Channel Standard (FCS)

Rich Taborek of Amdahl has created an excellent web page on Fibre Channel at www.amdahl.com.

ftp.network.com [Has draft Fibre Channel documents] playground.sun.com [Has FCSI Fibre Channel Profiles] (rdv, 95/5/18 from Louis Grantham )

Fibre Channel runs over coax or optical fibre (single or multimode), and even twisted pair. Fibre Channel comes in two basic forms -- Aribtrated Loop and switched fabric, which aren't (yet) interoperable. The host interfaces are rapidly becoming cheaper, but the switches are still expensive.

Fibre Channel standards define several functional levels, from the physical interface up to the mapping to upper level functionality, e.g. how to do SCSI commands over FC. FC provides several "classes" of service, including dedicated circuit and acknowledged and unacknowledged datagrams. Can also be used for IP. (rdv, 96/10/28)


8.9. ESCONN/SBCON {Brief}

Enterprise Systems CONNect. IBM's new mainframe attach -- fiber, I believe. The standardized version of this is known as SBCON, and Rich Taborek has once again created an excellent web page at www.amdahl.com.


8.10. IEEE P1394 (Serial Bus)

Apple's new standard for connecting devices via a high-speed serial bus. Good info at www.skipstone.com. Also some info FTPable at ftp.apple.com (I think that's where I got those papers.) (rdv, 95/5/15)

After having been somewhat dormant for a while, standards activity on new versions of 1394 is heating up again. Faster versions are in the works, as is a protocol for doing disks across it. (rdv, 96/10/28)


8.11. Serial Storage Architecture (SSA)

IBM's new offering in the serial device interface sweepstakes. Some docs and tentative working standards available on the SCSI ftp site: ftp.symbios.com The SSA Industry Association has a web server at www.ssaia.org. Disk drives from Conner and Micropolis, and Pathlight and Adaptec and expected to do host adapters.


8.12. S2I: IEEE P1285 Scalable Storage Interface

Chaired by Martin Freeman, Philips Research, this is an effort to standardize attaching disk drives directly to a system bus, making the disk's buffers readable as regular memory to the CPU. Sort of the opposite of network-attached storage, this couples the storage device design more closely to the hardware and OS of the host system. See sunrise.scu.edu for more info. (rdv, 1995/12/22)


8.13. Multibus, Unibus, Mainframe Channels, and other history {None}


My Home Page at Caltech

email me at rdv@isi.edu

Copyright 1996 Rod Van Meter