Newsgroups: can.usrgroup
Path: utzoo!lsuc!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Subject: Re: Is it the interleave?
Message-ID: <1989Oct10.221219.3571@eci386.uucp>
Reply-To: clewis@eci386.UUCP (Chris Lewis)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
References: <891006074552.5152@tmsoft.uucp> <695@ecicrl.UUCP> <1989Oct8.192745.20807@tmsoft.uucp>
Distribution: ont
Date: Tue, 10 Oct 89 22:12:19 GMT
Lines: 71

In article <1989Oct8.192745.20807@tmsoft.uucp> mason@tmsoft.UUCP (Dave Mason) writes:
|In article <695@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes:
|>In article <891006074552.5152@tmsoft.uucp> brian@ncrcan.Toronto.NCR.COM writes:
|>
|>>I have Maxtor 1140 disks formatted to approx. 305MB (really 319,610,880 bytes).
|>>This is done on PC's with Perstor Controllers (31 Sectors/track) and using
|>>the 1140 disks as if they were 2190's (ie, 1224 cylinders instead of the 
|>>918 as published by Maxtor).  I have yet to come across a Maxtor 1140 on
|>>which this couldn't be done.
|
|Note that Brian's also suggesting that there are more tracks really on
|the disk.

I don't think so.  This is why:

	- ST506 normally allows 1024 cylinders.  If the XT1140 was >988,
	  Maxtor certainly would have at least said 1024.
	- A controller is *not* able to change head step distances (as they
	  were, say, with Apple II floppies), because to the controller,
	  an ST506 disk has a discrete number of head positions that
	  you issue "step head out" and "step head in" and "recalibrate head" 
	  commands to.  Eg: you can't 1/2 step the head.  (Apple II's used
	  this for software copy protect...  but some floppy drives couldn't
	  do it at all....  grumble)

What I think that the Perstor is really doing is getting the number of
sectors per track > 31, running into a DOS limitation, and then spoofing the
geometry so that the number sectors per track remains legal, but the
number of cylinders is upped instead.  This is analogous to the way
the WD1007 handles ESDI disks with 34 sectors/track...

You're right though, *part* of the way this is done could be that the
Perstor formats each track as one *long* physical block, thus you
have relatively little header/trailer lossage.

>	1) average access times would be slightly larger (average
>rotational delay would be 1.5 * rotation time rather than .5 - adding
>16.67ms/access) (making the total average access on the 1140 go from
>36.33 ms (?28 ms seek? + 8.33 ms rotational latency) to 53 ms)

The XT1140 is 28 Ms.  Yes, average "single" block latency would go
up, especially if the buffer parcelling occured in the driver
(major buffering problems), but overall system performance is a much more
complicated thing to predict.  

We (well, in a previous incarnation, my colleagues (including to a certain
extent John Macdonald - I did the Spectrix DPT driver...)) implemented 
driver-based track buffering on the Spectrix 68020 Xenix systems, and 
discovered a pretty substantial performance improvement
*on average*.  Provided that the controller (or driver) manages to
keep a *couple* (or more) full tracks of data around as a next level
of buffer cache, UNIX's tendency to read disk blocks sequentially
(even in archaic file system layouts like Xenix III) will get you a big win.

John Macdonald may remember some of the performance statistics from
the XL.

As a canonical *best* case, just imagine a dd of a blocked disk, *one*
rotation per track read.  Which is on the order of 6 times faster than
systems that don't have or can't fully utilize 1:1 interleave.

Canonical *worst* case is the 53 Ms. average that you calculated.

On the other hand, the DPT left the track buffering Spectrix driver
in the dust....  Woof!
-- 
He's a consultant:             | Chris Lewis, Elegant Communications Inc.
Lend him your watch            | UUCP {uunet!attcan,utzoo}!lsuc!eci386!clewis
and he'll tell you the time.   | Moderator of the Ferret mailing list.
   Don Munroe, Cosmic Commander|