Ian holds a BS in mechanical engineering and an MS in aerospace engineering. He is the principal author of DISSPLA and cofounder of ISSCO. He can be reached at Integral Research, 249 S. Highway 101, Suite 270, Solana Beach, CA 92075.
In my article "Sharing Peripherals Intelligently" (DDJ, November 1994), I described a system called the STAR Peripherals Manager, which furnishes a pool of high-speed devices to a computer workgroup. In this installment, I'll examine how the peripherals manager (PM) uses SCSI-2 as an ultra high-speed, inexpensive network (up to seven Mbytes/sec per client). The STAR PM consists of a standard 486 PC, which handles all the devices; the client workstations use SCSI-2 cables to connect to STAR. The clients do not interface to the devices themselves; this is handled by 32-bit assembly software in the STAR PC.
SCSI was never intended to be a networking protocol. It was designed to standardize the interface to disks, tapes, and other peripherals; see the accompanying text box entitled, "A SCSI Primer." However, the SCSI message architecture lends itself to networking. Theoretically, you could string up to eight clients together (16 with Wide SCSI-2) by daisy chaining SCSI cables between them: The SCSI-2 spec allows hosts to communicate via the Processor Device or Communications Device protocols. The difficulty is that almost all SCSI-2 adapters expect to connect to a disk, tape, or other device (target), not another host (initiator). To be a network node, the adapter must function interchangeably as both initiator and target.
Since almost all current SCSI-2 devices--adapters and peripherals--use one of a handful of SCSI-2 microprocessors (such as the NCR 720), the limitation lies with the adapter-card firmware, not the hardware. Furthermore, most operating systems catering to SCSI-2 do not provide for operation as a target, so any direct use of SCSI-2 as a receptor to another desktop requires writing custom host SCSI-2 drivers and APIs. Since drivers and APIs are specific to each OS and even each platform, the direct use of SCSI-2 as a universal network is impractical. A practical solution requires minimal impact on any platform or its OS.
A well-known SCSI drawback is its limited cable length. Normal cables, which use a single wire per line (single-ended SCSI), are limited to six meters. But differential SCSI, in which each line employs the polarity of a wire pair, can span up to 25 meters. If there are only two devices on the bus, these limits can be relaxed with good-quality cable. This is nowhere near the hundreds of meters permissible with networks, but adequate for the typical intimate workgroup. Since STAR favors just one client per adapter, the distance limitation is not as severe. Applied Concepts (Wilsonville, OR) and Paralan (San Diego, CA) market "SCSI extenders," which convert the parallel SCSI signals into a proprietary serial protocol, and then transmit them via copper or fiber-optic cable. An extender box is placed at each end of the SCSI interconnect, enabling it to traverse well over 1000 meters; see Figure 1. The coming SCSI-3 standard will address high-speed serial transmission. Thus, the SCSI distance limitation can be overcome.
The speed of SCSI-2 makes it practical for huge files and sharing high-performance peripherals, rather than e-mail and small files. This can be accomplished via a central-hub STAR that appears as a target to all the client-host initiators. This is a configuration compatible with all SCSI-2 host adapters and systems. Interhost communication is possible with STAR acting as an intermediary. Although this solves interconnection, there remains the question of protocol. SCSI-2 does not recognize files and defines no interactive protocol; for example, the only commands for disk-data transfer are read/write fixed-length "logical blocks." Names, directories, and even file-allocation tables are alien, so how could a file be specified?
It's possible to implement a protocol on existing adapters via vendor-specific SCSI-2 commands such as Send Diagnostic and Receive Diagnostic Results, which enable arbitrary blocks of data containing file specification and other dialog to be sent as "diagnostic data." Again, the shortcoming is that it would require custom client-driver and API modifications to accommodate the unsupported commands. To be universally viable, the protocol should be sent via device commands supported by almost every platform: disk, CD-ROM, and tape. However, disk can be ruled out because high-level disk I/O is modified and encapsulated by almost every OS, so the protocol data is buried somewhere in the final SCSI-2 read/write requests and may even be cached to memory (RAM disk). CD-ROM shares these shortcomings with the additional caveat that writes are frowned upon. This leaves tape.
Most systems have tape utilities such as TAR and SYTOS, but almost all support direct tape-record read/write from high-level software (SunOS permits tape I/O via C read/write to dev/mt0). Data records can be passed unadulterated to the "tape" device without modifying the client system; caching to memory, if present, can usually be disabled or circumvented. Tape I/O as a vehicle is employed by STAR and Springboard, a PC-based image processing system.
Clients pass commands to STAR via tape writes and read back information via tape reads. The protocol is open architecture with all commands as ASCII text records to simplify implementation on diverse platforms. The commands can be sent directly from client app code or from a C-based, interactive utility. There is no need for STAR to possess an actual tape drive; as long as STAR mimics a tape, the client OS is none the wiser. "Virtual tape" becomes the mechanism by which information is passed between high-level client software and STAR.
Figure 2 illustrates a protocol session. The sequence queries the devices available on STAR, assigns a tape drive, reads an index of the tape contents from the last record, and then positions to tape file 53. Command mode is entered by writing the text record mAgIc, which also flags that subsequent records are commands, not actual tape I/O. The session is terminated via the Exit command, whereupon all further read/writes are considered legitimate tape I/O (until the next mAgIc record). The protocol presupposes that an actual tape write with the 5-byte text mAgIc is extremely unlikely--a reasonable assumption. Each tape-write command is always followed by a tape-read command, which returns status, if no data. A tape write followed by an immediate read causes most systems grief. (How can you read blank tape?) The OS usually issues a write filemark, then a rewind command prior to the read; alternatively the STAR interface code may have to insert them to placate the OS. STAR ignores these superfluous SCSI-2 commands until the exit, whereupon they are considered legitimate tape ops.
EXIT NO_POSN causes STAR to ignore any OS or app tape-movement commands, providing a mechanism for the client user to override device requests coming from vendor software over which he or she has no control. For example, Adobe Photoshop may issue rewind or other unwanted tape-positioning commands. STAR's ability to override or change SCSI-2 commands (transparent to the client app or OS) is a powerful, client-platform independent mechanism for modifying the I/O handling of popular apps without banging on the app vendor. (I/O and device handling are generally the areas where customization is most needed.) The protocol enables the customizing information to be passed to STAR prior to executing the app; STAR can then modify subsequent app I/O as instructed. Since the STAR interface utility can generally be executed from within a local shell, protocol sessions can be conducted from a standard app without terminating it. The ability to filter and transform data coming from the actual medium provides additional control over standard apps.
The actual protocol commands are not as important as the fact that an extensive dialog can transpire between a user and STAR transparent to UNIX, Windows NT, OS/2, or any other system--or even the client app itself. Since the client OS has no influence over the content of the command records or data returned by STAR, the scheme has complete flexibility. The commands are used to specify disk files, interrogate disk directories, install data-transformation algorithms, and perform other device activities unrelated to tape. Actual tape I/O complicates the STAR end because legitimate I/O is interspersed with protocol sessions. But the burden of implementation rests on the STAR PC, not the client, because STAR must detect the special records before caching actual tape I/O, discard superfluous client SCSI-2 commands, and decode and execute the protocol requests. The client needs only to send the virtual tape records and read the STAR responses. Without an intelligent server programmed to respond at the SCSI-2 interface level, the virtual-tape scheme is not viable.
There is no limit to the uses for a virtual-tape protocol; network functions such as interclient communication, even e-mail, can be implemented by storing messages from one client in STAR and forwarding them to the recipient. The only requirement is that the STAR PC be programmed to recognize and execute enhancements to the command set.
A mechanism is available on STAR to recognize user custom commands and divert them to user-supplied STAR-based code. Virtual tape provides communication flexibility without sacrificing ultra high-speed SCSI-2 data transfer, impacting existing client SCSI-2 devices, or requiring TSRs and other system mods.
"Small Computer System Interface (SCSI-2)" Working Draft, Project 375D, ANSI X3T9.2 Committee, March 1994.
Small Computer Systems Interface (SCSI) has evolved into a platform-independent specification for interfacing a wide range of peripherals and has become the standard for almost all desktops. The original 1985 ANSI specification, generally referred to as "SCSI-1," afforded latitude to device manufacturers, inevitably leading to incompatibility between platforms and peripherals. The current ANSI SCSI-2 specification nails down the hardware timings and eliminates most of the different software interpretations. SCSI-2 provides a rich command set and versatile options to link multiple commands (for speed). It enables time-consuming commands (rewind, for example) to release the bus. SCSI-2 is so extensive it typically requires a dedicated microprocessor, such as the NCR 720. But SCSI-2 is designed for device interface. Its sophistication is concentrated on diagnostics, integrity, and device-control functions--there is no provision for data files, names, or other high-level concepts.
The 8-bit SCSI bus consists of eight data, one parity, and nine signal lines. This is increased to 16 and 32 data lines by 16-bit (Wide) and 32-bit SCSI-2, but all other aspects of the specification remain unchanged. The devices are connected to one another by running a cable from one device to the next as a "daisy chain." SCSI devices communicate via message packets analogous to networks. These 6-, 10-, or 12-byte messages each contain a command and related parameters; for example, to format a specific disk track, skip a given record count, and so on. If the command involves data transfer, the data length is contained as one of the parameters. In the case of a write, the data bytes follow the message; for a read, they are input. Subsequent to the message and data, the command sender (initiator) listens for a status byte from the receiver (target). According to SCSI-2, any device can be an initiator or target interchangeably even between commands; however, most host adapters are configured exclusively as initiators, and most peripherals are targets.
Selection of which devices communicate with one another takes place during the arbitration and selection phases preceding the message phase; see Figure 3. Any device wishing to use the SCSI bus activates one of the data lines at the start of the arbitration phase, each device being unique to one of the data lines (during this phase). If more than one data line is activated, the device with the highest priority wins. Thus each line has a priority 0--7 (typically the host takes 7). Once a device gains control of the bus, it becomes the Initiator, whereupon it activates both its own line and the line for the target (selection phase). The target acknowledges via a signal line and the message phase commences. This scheme allows any device to become a bus master and target any other device. The maximum number of devices on the SCSI bus is limited by the count of data lines: 8, 16, or 32 for normal, Wide, and 32-bit SCSI-2. Unlike single-line networks, 8-bit SCSI-2 has 17 lines to use so its collision resolution is more efficient and consumes less bus cycles, giving it a substantial advantage over a network with the same nominal bytes/sec.
One SCSI myth is the inflated data rate quoted by many vendors, for example, ten Mbytes/sec for synchronous 8-bit (Fast) SCSI-2 devices. This data rate refers only to the data clocking following the Message Phase and does not account for the overhead of the arbitration, selection, and other phases. Once a device gains control of the SCSI bus, it and its target can dally about set up of the data transmission, resulting in a much-reduced actual SCSI throughput. Performance depends on the amount of data accompanying the message; for example, if the arbitration overhead is 5 ms and only one byte is sent with each message, the rate is only 200 bytes/sec, whereas for 256-Kbyte blocks the realized performance is 8.4 Mbytes/sec. Clearly, it is desirable to send as much data as each device can accommodate with a single message, to minimize delays and utilize command linking and other SCSI-2 features that cut overhead. This favors separating real-world host (client) and peripheral I/O into overlapped, independent streams buffered through a high-speed intermediary.
Although SCSI-2 is more rigorous than SCSI-1, many of the SCSI-2 commands are optional, and it is still possible for a device to be SCSI-2 compliant while not honoring certain host-driver requests. On the other hand many of the powerful features of a vendor's peripheral can go unused by an OS geared to the lowest common denominator; for example, fast search on tapes and scatter read/write on disks. By separating the host platforms from the peripherals, STAR is able to take full advantage of advanced, or even vendor-specific SCSI-2 features of a given device, while catering to the minimal expectations of most host systems.
--I.H.
Figure 1 Extending distance between SCSI-2 devices with extender modules at each end of SCSI-2 cable run. This overcomes SCSI-2 distance limitations.
Write: 'mAgIc' Enter protocol mode Read : Status (OK) STAR returns status on each command Write: 'QUERY' Query devices available on STAR Read : Devices list Write: 'ASSIGN 3' Device 3 on STAR list received Read : Status Write: 'TAPE_POSN LAST' Position to last file on tape Read : Status Write: 'READ 32000' Read record up to 32000 bytes Read : Contents+length Write: 'FILE1 53' Position to file 53 of tape (first Read : Status file is 1) Write: 'EXIT NO_POSN' Terminate protocol mode. Ignore SCSI-2 Read : Status position commands until 1st Read. <Further Read/Writes now legitimate tape I/O>
Figure 3 Phase sequence on each SCSI-2 command. Note similarity with network message-packet protocol.
Copyright © 1994, Dr. Dobb's Journal