Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hp-pcd!hpcvca!charles
From: charles@hpcvca.HP.COM (Charles Brown)
Newsgroups: comp.sys.amiga
Subject: Re: Request to Commodore (Bad Blocks)
Message-ID: <5660018@hpcvca.HP.COM>
Date: 21 Sep 88 01:24:57 GMT
References: <8891@cup.portal.com>
Organization: Hewlett-Packard Co., Corvallis, Oregon
Lines: 74

>> 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.

I will paraphrase what I said:
 -------------------------------------------------------------------
 * DO NOT CHANGE THE WAY YOU READ.  ONLY CHANGE THE WAY YOU WRITE. *
 -------------------------------------------------------------------
Therefore READS TAKE THE SAME AMOUNT OF TIME whether the writes are
decoupled from the index pulse or not.

> 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.

This is incorrect as noted above.

> 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.

Incorrect.  If you are trying to read or write (not both) 1.1
rotations result in eleven sectors read.  The Amiga trackdisk device
does not read half of a track, it always reads the whole track.
Usefulness has nothing to do with it.  I do not propose to change that.

Your statement (with the term I/O) implys combined reads and writes.
The Amiga does not read or write partial tracks.  It also does not mix
reads with writes during one track operation.  I do not propose to
change that.

> 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.

This is refering to single sector reads.  I am not talking about that.

> 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.

The "basic figures" you are talking about clearly must be single
sector reads.  I am not talking about that.

> 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).

Again you are talking about single sector reads.  I am not talking
about that.

> 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.
> 					-=] Ford [=-

See my first statement in this response.  My numbers remain valid.
We gave up track reliability for at best a 7% increase in overall
floppy speed.

It amazes me how easy it is to respond to a note without reading it.
	Charles Brown		charles%hpcvca@hplabs.hp.com