Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucsdhub!hp-sdd!hplabs!nsc!pyramid!cbmvax!ditto
From: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Newsgroups: comp.sys.amiga
Subject: Re: Request to Commodore (Bad Blocks)
Summary: trackdisk (vs. sectordisk?) is a reasonably good idea
Keywords: trackdisk floppy format
Message-ID: <4774@cbmvax.UUCP>
Date: 20 Sep 88 07:11:35 GMT
References: <8891@cup.portal.com> <5660016@hpcvca.HP.COM>
Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto)
Organization: Commodore Technology, West Chester, PA
Lines: 51

In article <5660016@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes:
>The following numbers represent time in terms of track rotations:
>		  write	+ read (weighed)
> index coupled:   1.5	+ 5*1.1		= 7.0
> index decoupled: 1	+ 5*1.1		= 6.5
>Now the advantage of decoupled index drops to 6.5/7.0=0.93 or 7%
>
>So we gave up track reliability for at best a 7% increase in overall
>floppy speed.  That strikes STILL me as a bad trade.

But now you're using the "decoupled" figure of 1.1 in the "coupled" row.

In the case of a random sector read, the average would be 1.5, not 1.1,
giving a ratio of (6.5 : 9) == 0.72, a 28% savings.

Also, your figures don't take into account that the 1.1 rotations of
trackdisk result in up to eleven sector I/Os ("up to" because I won't
assume that all the data on that track would be useful at that time),
while the index-synced method would take 1.5 rotations to read ONE sector.
Now, granted, the "conventional" method, under the right conditions, can
then proceed to read several consecutive sectors, but this requires that
the disk interleave be tuned to the specific application or it becomes
1.1 rotations per sector.

The trackdisk strategy also relies on sequential access to boost
performance; if sectors are being read sequentially it can be *eleven
times* faster than the basic figures.

On top of all that, the trackdisk method only needs fairly simple
hardware, and has a much lower software overhead in terms of interrupt
processing (only one interrupt per 11 sectors, instead of at least one
for each sector) and in terms of real-time demands (the CPU doesn't have
any real-time constraints with trackdisk, since it starts the DMA whenever
it "feels like it", and the process completes automatically, with no
immediate CPU responce required).

Now, by "simulating" trackdisk with a conventional controller, (with track
bufferring and always reading a whole track in (typically) 1.5 rotations),
you can get back to the 28% difference in throughput, but index-syncing
will still have extra CPU demands.

A disadvantage of trackdisk, however, is the CPU processing required to
"find" the sectors in the track of raw data, and the need to un-MFM the
data.  I don't know how long these operations take.
-- 
					-=] Ford [=-

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