Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!ames!oliveb!pyramid!cbmvax!ditto
From: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Newsgroups: comp.sys.amiga
Subject: Re: Request to Commodore (Bad Blocks)
Summary: Non-index-synced reads *are* faster
Keywords: floppy format index
Message-ID: <4726@cbmvax.UUCP>
Date: 14 Sep 88 05:49:34 GMT
References: <8891@cup.portal.com> <5660015@hpcvca.HP.COM>
Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Organization: Commodore Technology, West Chester, PA
Lines: 36

In article <5660015@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes:
>Read:
>	Reading does not depend upon the index hole anyway.  It really
>	only depends upon where the track was started when it was
>	written.

It doesn't even have to depend on that, and in fact, the trackdisk.device
doesn't even care...

>	If you always start a track read at the beginning of a track
>	(as written) you will on the average have a 1/2 rotation
>	latency waiting for the disk to turn to the start of that
>	track.  So decoupling the index hole from the the start of
>	track did not speed up reads AT ALL.

But you don't always start a read at the beginning of a track.
Trackdisk.device starts reading wherever the head is, and reads one
full revolution plus enough extra to make sure it gets at least one
intact copy of the sector it started reading on.  So the total track
read time should be constant:

	1 rotation + 1 sector time + 1 index gap time.

Since the gap varies due to variation in disk speed, etc., you have to
allow some slop.  I'd roughly estimate the result as being 1.1 rotations,
not the 1.5 you came up with, so it does save a fair amount of time.

Waiting for the index hole would also mean one more interrupt to process
per sector.
-- 
					-=] Ford [=-

	.		.		(In Real Life: Mike Ditto)
.	    :	       ,		ford@kenobi.cts.com
This space under construction,		...!ucsd!elgar!ford
pardon our dust.			ditto@cbmvax.commodore.com