Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!uccba!uceng!ndcheg!iuvax!purdue!gatech!uflorida!rex!ukma!cwjcc!hal!nic.MR.NET!csd4.milw.wisc.edu!bionet!agate!ucbvax!decwrl!decvax!tektronix!uunet!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Apple HD SC 80 does not support Asynch i/o.
Message-ID: <13320@cup.portal.com>
Date: 8 Jan 89 13:01:10 GMT
References: <11605@dartvax.Dartmouth.EDU> <271@berlin.acss.umn.edu> <27318@ucbvax.BERKELEY.EDU> <13271@cup.portal.com>
Organization: The Portal System (TM)
Lines: 77

I've done some measurements, and the results are interesting.  I had
a program that did reads of random blocks from a SCSI disk.  The
logic for doing the reads went like this:

	SCSIGet
	SCSISelect
	SCSICmd
	wait for bus to be in DATA IN phase
	SCSIRBlind
	SCSIComplete

The program would read a few hundred random blocks in the first 32 meg of
the disk.  The function that performed the above operations kept track
of how long it took for the scsi bus to enter the DATA IN phase after
the command ( by counting the number of times it had to read the bus
status before findind the correct phase ).

Here are the results for two drives I have on my Mac II:

	SyQuest SQ555

		Average access time according to manufacturer
			25 msec
		Average measured time for read command via SCSI manager
			40 msec
		Average measured time command until DATA IN phase
			1 msec

	Quantum ProDrive 80

		Average access time according to manufacturer
			18 msec
		Average measured time for read command via SCSI manager
			32 msec
		Average measured time from command until DATA IN phase
			25 msec

Thus, it appears that a driver that returned after the command was issued
and polled via the Time Manager every millisecond would be able to give
the application about 25 msec of extra run time if the drive being used
is a Quantum ProDrive 80, but only 1 millisecond on the SyQuest SQ555.

Thus, an asynchronous driver looks possible for the ProDrive 80.  The
SQ555 is more doubtful, because the average delay is so close to the
resolution of the Time Manager.

Of course, real usage does not follow the random access pattern of my
test program.  Another test program I had did sequential access, and
the delay after the command while waiting for DATA IN was much shorter.
To determine if an asynchronous driver makes sense, someone needs to
determine the average delay under real world access patterns.

These numbers are interesting because the Quantum is the faster drive.
I would conjecture that the SyQuest is putting the bus in DATA IN phase
before it actually has the data, while the Quantum is waiting until it
is ready to transfer the data.

The other interesting this is the measured times vs. the manufacturers
claimed times.  Sure, I expect my times to be slower, because of SCSI
manager overhead and stuff like that, but 1.8 times as slow?

Also, note that the time from SCSICmd() returning to the time the drive
places the bus in DATA IN phase has nothing to do with the Macintosh.
This is purely determined by the drive.  For the ProDrive 80, this time
was longer than the claimed average access time.  I don't understand
how a drive with an average access time of 18 msec can take an average
of 25 msec to switch to DATA IN phase.

On the other hand, the ratio of measured read times to claimed average
access time was pretty close to the same for both drives.  Perhaps
"average access time" means the time it takes the drive to seek and
rotate to the data, rather than the time it takes the drive to actually
process the command and get the data out on the SCSI bus?  Is this what
drive manufacturers mean when they quote average access time figures?


						Tim Smith