Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxb!mhuxn!mhuxm!mhuxj!houxm!whuxlm!harpo!decvax!decwrl!sun!wmb
From: wmb@sun.uucp (Mitch Bradley)
Newsgroups: net.periphs,net.micro,net.arch
Subject: Re: simple SASI/SCSI interfaces
Message-ID: <1993@sun.uucp>
Date: Wed, 13-Feb-85 22:24:57 EST
Article-I.D.: sun.1993
Posted: Wed Feb 13 22:24:57 1985
Date-Received: Fri, 15-Feb-85 05:39:57 EST
References: <5043@utzoo.UUCP>
Reply-To: wmb@sun.UUCP (Mitch Bradley)
Organization: Sun Microsystems, Inc.
Lines: 66
Xref: watmath net.periphs:667 net.micro:9380 net.arch:812
Summary: 


> 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