Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!dual!forbrk!mats
From: mats@forbrk.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Berkeley FFS and SCSI
Message-ID: <331@forbrk.UUCP>
Date: Mon, 15-Jun-87 15:58:22 EDT
Article-I.D.: forbrk.331
Posted: Mon Jun 15 15:58:22 1987
Date-Received: Wed, 17-Jun-87 01:43:07 EDT
References: <16753@amdcad.AMD.COM> <324@forbrk.UUCP> <1142@rocksvax.UUCP>
Reply-To: mats@forbrk.UUCP (Mats Wichmann)
Organization: Fortune Systems/SCI Technology  (Berkeley CA)
Lines: 72

In article <1142@rocksvax.UUCP> martyl@rocksvax.UUCP (Marty Leisner) writes:
>In article <324@forbrk.UUCP> mats@forbrk.UUCP (Mats Wichmann) writes:
>>SCSI is an essentially low-performance peripheral interface. Its' main
>>advantage is ease of integration of new peripherals. 
>
>I was under the impression SCSI could transfer data at several megabytes/
>second (1.5-4? depending on whether it is asynchronous or synchronous?)  
>This sounds pretty high performance to me.  What CPU can eat data that
>fast?
Peak burst transfer rates can indeed be in the 3-4 MB range, if you use
the synchronous option which I haven't seen implemented yet. Disk type
devices have all been in the 5 to 10 megabit transfer rate range. Really
not a problem with the spec per se, but with the fact that the spec was 
introduced so as to encourage the use of existing technology - ST506-type
disk drives. This was a necessity for accepance, but....

>>My biggest problem with SCSI is that you are too far removed from the disk. 
>>I would *like* my disk controller to buffer lots of data, and preferably 
>>to keep reading stuff and storing it away while there are no other requests 
>>pending (non-intrusive readahead). 
>
>Is this a problem with the interface or the boards being built for it?
>
It is, of course, a problem with the boards being built - but sort of with
the interface itself. Let me explain what I mean: a lot of performance
can be gained by doing a real bang-up job on the controller which is on
the drive's end of the SCSI. This puts the job of building a high-performance
controller with people who have not done it before (and who may perhaps
not have much interest in it): the drive manufacturers, and away from
companies who have made a living from disk controllers - people like
Emulex, Xylogics, and even Dual (whom I used to work for). This is not
necessarily a "good thing".

>If caching is done on both ends (host adapter and disk controller) and with
>a low performance microprocessor on each end, it looks like impressive
>performance could be achieved.  Whenever a read request is made to disk,
>the process needing the data has to hang on the disk access anyway -- once
>the request is initiated, the host cpu shouldn't be bothered with the 
>pending request until it receives acknowledgement the operation is complete.
>From a device driver point of view, I like to pass linear sector numbers to
>the controller and let the controller figure out the head/track/sector.  
>
I really don't argue with this reasoning, although someone needs to convince
the drive mfgs. to put intelligent caching on their drives, which is something
that will be driven by demand. As Fortune, we are not in any position to
make these demands; and everytime we say something to CDC or Micropolis, 
they tell us nobody else has ever asked for that, so the demand must not
be out there yet - maybe never will be. The type of intelligence I am
looking for, is filling of buffers while nothing else is going on - i.e., 
soaking up dead time, waiting for the heads to get to the right sector, etc. 
The kind SCSI mfgs. are doing now causes the original request to often
take longer to be satisfied.

>Also, SCSI appears to have the capability to do interesting things with 
>multiple hosts sharing multiple disks (I'm thinking of buying a SCSI disk 
>for my PC AT at work).  
>
It does that, although from reading (not from actually implementing) it
appears that the "reserve" functions are not especially useful, which
means that there will be some logistical problems with sharing disks -
I wouldn't feel comfortable sharing anything that wasn't effectively
"read-only".

In all, Marty made me think of things in a slightly new light. I am still
not really too thrilled about SCSI, but it is a little hard to justify,
in an absolute sense, my views that SCSI is inherently low-performance.
Instead, I now feel that the implementation approach, which makes many
of the high-performance features optional, along with the way the standard
has been introduced, while not in and of themselves bad things, doom
SCSI to *effectively* be low performance in most cases.

Mats