Path: utzoo!mnetor!tmsoft!mason
From: mason@tmsoft.uucp (Dave Mason)
Newsgroups: can.usrgroup
Subject: Re: Is it the interleave?
Message-ID: <1989Oct8.192745.20807@tmsoft.uucp>
Date: 8 Oct 89 19:27:45 GMT
References: <891006074552.5152@tmsoft.uucp> <695@ecicrl.UUCP>
Reply-To: mason@tmsoft.UUCP (Dave Mason)
Followup-To: can.usrgroup
Distribution: ont
Organization: TM Software Associates, Toronto
Lines: 56

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 have an 1140 with RLL controller with 175MB.  If he's
right about the other cylinders this would go to 233MB (244,392,960
bytes), still not 305, but that's still a hell of a cheap way to get
an extra 116MB!! (I have 2 of them)  I have a non-AT bus, so
presumably couldn't use the Perstor (unless there's a SCSI version).

>But the Perstor must be doing somewhat more than that - eg: lying
>about the geometry and multiplying the storage per track by something
>close to 3!  Is it doing compression or something?  What's the performance
>like?  1:1 capable?

I'd also like to know what it's doing.  Anybody around who knows any
FACTS on the Perstor?

GUESS time:
	Facts:
		1) a block on disk has some header & trailer bytes
			around it for recognising the block, error
			checking, electronics switching time and
			rounding up to an even multiple of
			blocks/track.  From the sample formats in my
			Docs, this looks to be a minimum of about 56 bytes.
		2) 10416 bytes on MFM disk track (according to my
			Adaptec Documentation)
		3) *1.5 that makes 15624 bytes on RLL disk track
		4) 512*31 (re Brian's note above) = 15872 DATA bytes
			on a Perstor track
	Speculation:
 This is close enough that one possibility that comes to mind is that
it (squeezes the bits VERY slightly (<2%) &) keeps a full track
buffer.  It then would read and write the track as a single 15872 byte
sector, and break it up in the buffer.  This would have some
noticeable performance effects:
	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)
	2) 1:1 interleave would be free.
	3) Once you accessed one block on a track, getting the rest
would be free.
 Over all this should give somewhat worse performance on a (SysV) Unix
file system (though I'd be willing to suffer this for the extra 24%
disk space).  A BSD new file system might be able to make good use of
the track buffer.

	../Dave