Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!sri-unix!sri-spam!ames!amdcad!amd!intelca!oliveb!enchant
From: enchant@oliveb.UUCP (Dan Crocker)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Interleave factor on a 6300
Message-ID: <2999@oliveb.UUCP>
Date: Tue, 11-Aug-87 16:09:47 EDT
Article-I.D.: oliveb.2999
Posted: Tue Aug 11 16:09:47 1987
Date-Received: Thu, 13-Aug-87 06:33:48 EDT
References: <2928@mtgzz.UUCP> <1844@ttrdc.UUCP> <300@cpsc6b.cpsc6a.att.com>
Organization: Olivetti ATC; Cupertino, Ca
Lines: 46

> The default interleave factor for hard disks varies from manufacturer to
> manufacturer, and I don't know of any sure way to find it other than to
> read the manual for the specific hard disk you are using, or perhaps to
> contact the manufacturer.


For those programmers out there, it shouldn't be too hard to write a program
to calculate interleave.  The following should be the basic algorithm:
1. Issue an INT 13 to read sector #1
2. Start a timer
3. Issue an INT 13 to read sector #2
4. Stop timer

The results of this sequence can be interpreted in the program or manually.
Basically, there are two possible results:
a. The number is less than 16.7 ms
   If this is the case, then the time is your interleave.  This is due to
   the fact that each sector on a 17 sector track is about 1ms long (16.7/17).
   For an interleave of 3:1, it will take about 2ms to arrive at the beginning
   of sector 2 and 1ms to read it.  There are extra delays due to BIOS overhead
   and data transfer to the system, but these cancel each other out when the
   timer is started and stopped.  This idea can be expanded to handle other
   track sizes such as RLL (26 sec/trk) or ESDI (34,35,36), although the
   numbers are not as nice.

b. The number is greater than 16.7ms
   This means that you missed a revolution between reading sector #1 and #2.
   The case above (a) can be arrived at by simply subtracting 16.7.  Then you
   can proceed as before.
   This result is also an indication that your interleave is too small.  
   You should probably increase it by one until you get a number that is less
   than 16.7ms.


All of the above is based on the assumption that there are no problems with
reading ID's or errors in the data field.  Soft (random) errors in either case
could give strange results.

I hope this is helpful to someone.

				Dan 
-- 
Here comes the supernatural anesthetist
If he wants you to snuff it
All he has to do is puff it
He's such a fine dancer