Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!xstor!billbr
From: billbr@xstor.UUCP (Bill Brothers)
Newsgroups: comp.periphs.scsi
Subject: Re: SCSI disk transfer modes.....
Message-ID: <219@xstor.UUCP>
Date: 18 Dec 90 05:12:25 GMT
References: <28543@usc> <1990Dec5.182853.25111@Solbourne.COM>
Organization: Storage Dimensions, Inc.
Lines: 51

In article <1990Dec5.182853.25111@Solbourne.COM> taylor@chris.Solbourne.COM (Dick Taylor) writes:
>In article <28543@usc> rpinder@phad.hsc.usc.edu (Rich Pinder) writes:
>>Some of the higher capacity SCSI disk drives rate transfer speed in both
>>Synchronous as well as Asynchronous, with the former being rated as much
>>faster.  Is synchronous transfer possible on an Intel based box??  I'm
>>wondering if a NCR 486 microchannel, with the NCR 53C700 SCSI chipped
>>controller, running SCO Unix could address these 5.0 MB/second speeds they
>>claim?  Is it true that a limitation to Synchronous transfer is that there
>>can only be one device running synchronous in a system??  
>
>The transfer rates they quote are, of course, referring only to their
>speed on the SCSI bus, and not to the throughput available from the drive.
>The limit to throughput is still the media data rate, and there aren't
>any drives out there with prolonged throughput anywhere near 5.0 MB/s.

The main problem is that no matter how fast your host adapter and
drive are, you still have to get the data jammed onto the bus and
into the memory. We have reached speeds of 4.7 Mb/sec here in the
lab under VERY controlled situations using bus-mastering style of
host adapters and fairly high speed disks. We have found that
synchronous support really doesn't buy you very much. We support it,
but the average benchmark won't show much (if any) differences.

If however, the limiting factor was the host-adapter, or the drive
itself, synchronous equipment would be a factor. For example, using
a proprietary bus-mastering style of host adapter on an EISA bus
with a 486 does show some differences. 

The main problem that you are seeing has to do with the fact that
the UNIX io-subsystem is CPU bound... Yes, you read correctly. There
is sooo much overhead in the UNIX filesystem, 500-800K/sec is the
max you can really expect on a 33 Mhz 386 system running SCO UNIX
3.3 Release 2. (Release 1 is about half that). There are some 
expensive ways to get more, but so far those are too expensive
for the average joe.

SCO has done a good job of working on the disk performance. Analysis
show that clustering is in effect, and that the average disk request
is now 8-16K instead of the old 1K UNIX subsystem. Depending on the
drive selected, maximum throughput is approached somewhere in the 
64-128K request size. Even on a buffer flush, the kernel takes
300-500 microseconds (on a Compaq systempro) to push the next request
out to the driver.

On UNIX the best performing subsystems are those that can provide
the highest transaction rate. In other words, access time and
SCSI overhead are your worst enemies. 

Bill Brothers
Storage Dimensions, Inc.
uunet!xstor!billbr