henry@utzoo.UUCP (Henry Spencer) (02/09/85)
A group of friends have asked my opinion on several questions of
hardware design, including one that I'm unsure of the answer to.
The context is a desire to make it possible to connect "fast" devices
to a small computer, while not incurring much expense in the basic
system. The system has no expansion-oriented bus. For various reasons,
providing DMA for the fast-device connection is out. The cpu is hefty,
on the order of a 10 MHz 68000, and can copy data as fast as most any DMA
device could. Of course, it wants to do the copying in one huge burst,
starting at a time of its own choosing, rather than in little dribbles
as the fast device runs. Fast devices of interest are disks, tapes,
and Ethernet.
An interesting-looking possibility is a very simple host adapter for the
SASI/SCSI bus, not much more than some parallel ports with a few hooks
for interrupts and such. The question is, how well does this meet the
objectives? I'm not very familiar with either SCSI, or the currently-
available SCSI controllers, so...
Is it possible to find SCSI disk and tape controllers with reasonable
performance? (Defined as delivering a useful fraction of the potential
speed of the device, i.e. not requiring 5:1 interleaving on the disk
because the stupid controller can't keep up.) General impressions and
specific pointers both welcome.
Is anybody making an SCSI Ethernet interface? Planning to?
Is the idea of a very simple host adapter, with the cpu doing most of the
work except for the bare-bones handshaking, reasonable? Or is decent
performance impossible without smarts in the adapter? (Two obvious
issues are whether common SCSI controllers want their data in dribbles
instead of full-speed burst transfers, and whether they demand tight
real-time response from the host at any time.) Investing some cpu time
in exchange for the simple adapter is acceptable, but having the cpu
spending all of its time managing the SCSI interactions is not.
My understanding is that SCSI is about to be an ANSI standard but isn't
quite there yet. How can I get the current draft? (I know how to get
ANSI standards, but don't know who to contact for an SCSI draft.) To
what extent has ANSI changed/complicated/messed-up SCSI? Badly enough
to shoot down the idea of a dead-simple interface? I hear evil rumors.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrywmb@sun.uucp (Mitch Bradley) (02/14/85)
> Is it possible to find SCSI disk and tape controllers with reasonable > performance? (Defined as delivering a useful fraction of the potential > speed of the device, i.e. not requiring 5:1 interleaving on the disk > because the stupid controller can't keep up.) Yes. A number of manufacturers are making non-interleaved SCSI disk controllers. For instance, Adaptec, Emulex, ADSI, Western Digital, OMTI, XEBEC. The number of sectors that you can read in one command without missing revs depends on two things: a) the size of the buffer on the controller (2K is common; we are asking for 8K for future products) b) Whether or not the CPU's SCSI Host Adapter can empty the buffer fast enough to keep up with the data rate from the device (for ST-506, 5Mbits/sec == 1.6usec/byte == 3.2usec/word. For ESDI, 10Mbits/sec). For cartridge tape controllers, the major problem is to keep the tape streaming. This can be challenging with Unix, as you have to do something with the data coming off the tape pretty quickly in order to be ready for the next chunk. > Is anybody making an SCSI Ethernet interface? Planning to? Not that I know of. > Is the idea of a very simple host adapter, with the cpu doing most of the > work except for the bare-bones handshaking, reasonable? Or is decent > performance impossible without smarts in the adapter? (Two obvious > issues are whether common SCSI controllers want their data in dribbles > instead of full-speed burst transfers, and whether they demand tight > real-time response from the host at any time.) Investing some cpu time > in exchange for the simple adapter is acceptable, but having the cpu > spending all of its time managing the SCSI interactions is not. SCSI controllers have buffers on them, and the bus protocol is asynchronous, with a complete handshake for each BYTE. The controller doesn't care how long it takes you to empty or fill the buffer, except that if you are trying to do transfers longer than the buffer size, you have to deal with the buffered data fast enough to keep the disk from blowing revs between bufferfulls (the system will still work, but you will possibly take a performance hit). You could do it with 68000 programmed I/O, but you would have to be careful that the polling loop which decided when a new byte was ready did not slow you down too much. It might be possible to have the 6800 just go ahead and do a read or write, but hold up the DTACK until the controller was ready. Real time interrupt response is not likely to be a serious problem. > My understanding is that SCSI is about to be an ANSI standard but isn't > quite there yet. How can I get the current draft? (I know how to get > ANSI standards, but don't know who to contact for an SCSI draft.) To > what extent has ANSI changed/complicated/messed-up SCSI? Badly enough > to shoot down the idea of a dead-simple interface? I hear evil rumors. The ANSI additions haven't messed up things too badly. The additional features don't screw up the simple interfaces; dead-simple interfaces will still work with full-blown controllers, and vice versa. The additions primarily affect systems with several controllers on the same SCSI bus. They allow some degree of simultaneous action among the controllers, which the old SASI version couldn't do. I don't know where to get a current spec anymore. The contact used to be at Shugart, but Shugart is sort of getting taken apart. I'm sure Adaptec could point you in the right direction. Adaptec, Inc. 580 Cottonwood Drive, Milpitas, CA 95035 (408)946-8600 Mitch Bradley Sun Microsystems
rpw3@redwood.UUCP (Rob Warnock) (02/16/85)
Henry Spencer <utzoo!henry> writes in <5043@utzoo.UUCP>: +--------------- | The context is a desire to make it possible to connect "fast" devices | to a small computer, while not incurring much expense in the basic | system. The system has no expansion-oriented bus... | An interesting-looking possibility is a very simple host adapter for the | SASI/SCSI bus, not much more than some parallel ports with a few hooks | for interrupts and such. The question is, how well does this meet the | objectives? +--------------- Probably pretty well, if the interface is carefully matched to the use of it (as with the 68000 DTACK method you mentioned later). Early prototypes of the Fortune System used Xebec SASI-to-ST506 controllers and a "dumb" parallel port for the UNIX filesystem (polling for each character, etc.). Worked fine. There were throughput problems, but it was more due to improper disk layout than to the PIO method. Don't let the performance of early Lisas scare you... even with very crude hardware you can get good performance (relative to the disk latency) with careful analysis and tuning of the "bit-twiddling" code. +--------------- | Is it possible to find SCSI disk and tape controllers with reasonable | performance? (Defined as delivering a useful fraction of the potential | speed of the device, i.e. not requiring 5:1 interleaving on the disk | because the stupid controller can't keep up.)... | Is the idea of a very simple host adapter, with the cpu doing most of the | work except for the bare-bones handshaking, reasonable? Or is decent | performance impossible without smarts in the adapter? +--------------- Surpisingly, 1:1 is possible. While earlier SASI/SCSI controllers were all of the single-buffer type, newer (and still low-cost) boards from Adaptec, OMTI, and (maybe) Western Digital are all capable of 1:1 operation (they look like FIFOs). A simple "loop mode" byte-copy on a 68010 at 10 MHz moves data at 1.4 us/byte or over 5.7 megabits/sec transfer rate, well in excess of ST-506 rates. Your parallel port needs to designed very carefully to achieve such synchronized operation, but the cost would be low. You need to be careful with your interrupt-level assignments, since you don't want disk activity to cause you to lose serial data interrupts. And even with 1:1 transfers for swapping, your user filesystems will probably want 1:2 or 1:3 interlace ("system" interlace in mkfs) to match delays in the UNIX buffer handling code. Note that by using a small state machine to gather bytes into words, and by using a move-long in loop mode on a 10Mhz 68010, you can get over 14 Mbit/sec transfer rates from "programmed I/O". (Makes one think about SCSI & SMD, eh?) +--------------- | Is anybody making an SCSI Ethernet interface? Planning to? +--------------- Er... Ummmm.. I've thought about it, myself... but I don't know of anyone else who is planning to. (Further discussion of this should probably be via mail.) +--------------- | ... Investing some cpu time | in exchange for the simple adapter is acceptable, but having the cpu | spending all of its time managing the SCSI interactions is not. +--------------- I think it's perfectly reasonable. So does a guy by the name of John Bass <...!ihnp4!fortune!dmsd!bass>, who is currently building a single-board computer (68008-based) with just such a "bus" on it. (He gave a talk recently at a local computer club. Look for a product announcement soon.) He's using the NCR 5380 chip that handles most of the low-level handshake of SCSI (and includes the bus driver/receivers), and is talking to it directly with the 68k (although he was thinking about using DMA). Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
jones@fortune.UUCP (Dan Jones) (02/20/85)
The latest draft proposal for SCSI (X3T9.2) that I am aware of is REV 14 A.
You should be able to get a copy from either:
William E. Burr (X3T9.2 Chairmain) John B. Lohmeyer (X3T9.2 Vice Chairman)
U.S. Department of Commerce NCR Corporation
National Bureau of Standards 3718 N. Rock Road
Technology A-216 Wichita, KS 67226
Washington, D.C. 20234 (316) 688-8703
(301) 921-3723
--
Dan Jones
UUCP: {ihnp4,ucbvax!amd70,hpda,sri-unix,harpo}!fortune!jones
DDD: (415)594-2440
USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065henry@utzoo.UUCP (Henry Spencer) (02/26/85)
Thanks to everybody who replied, both by followup and by mail, to my query about SCSI controllers and host adapters. The following is a very quick summary of what I found out. > Is it possible to find SCSI disk and tape controllers with reasonable > performance? ... Yes. The host adapter is more likely to be the bottleneck, in fact. A number of companies make decent (although imperfect) controllers. > Is anybody making an SCSI Ethernet interface? Planning to? Nothing announced yet, although there is interest. > Is the idea of a very simple host adapter, with the cpu doing most of the > work except for the bare-bones handshaking, reasonable? ... Yes, if done carefully. Some small amount of hardware help might be useful in three specific areas: (1) stretching the cpu memory access until data is ready, to avoid having to poll; (2) combining more than one data byte into a single word for cpu data transfer; and (3) watching to see whether the type of data-transfer request has changed underfoot. But it's certainly possible, and has been done successfully, without any of these extras. Moreover, performance can be quite good. Several people mentioned the NCR 5385 chip that does a lot of the work. I already had a datasheet on it, in fact. Unfortunately, I don't believe it's second-sourced yet. Otherwise it looks good. > My understanding is that SCSI is about to be an ANSI standard but isn't > quite there yet. How can I get the current draft? ... The official source, which charges money (circa $30), is Ms. Martha Prinsen X3 Secretariat/CBEMA 311 First Street NW Suite 500 Washington, DC 20001 The magic word to indicate what you want is "X3T9.2 rev 14A". > ... To what extent has ANSI changed/complicated/messed-up SCSI? ... Not very much. In particular, even old host adapters should be able to run new peripherals. The additions mostly concern multi-controller systems where parallel activities are desired; the old versions basically insist on doing one thing (with one controller) at a time. This is a wart with things like magtapes because operations like rewinds can tie up the bus for a long time. An alternate approach to this is to have an SASI/SCSI bus per controller. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry