Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!hp-pcd!hpcvca!charles
From: charles@hpcvca.HP.COM (Charles Brown)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Request to Commodore (Bad Blocks)
Message-ID: <1410009@hpcvca.HP.COM>
Date: 24 Sep 88 23:56:55 GMT
References: <6392@batcomputer.tn.cornell.edu>
Organization: Hewlett-Packard Co., Corvallis, Oregon
Lines: 102

>>      This is the  key insight.  Writes  can be coupled  to the  index
>>pulse, and  disks written by a  "smarter" trackdisk.device can be read
>>(and written  to) by  an   old  trackdisk.device with  NO compaibility
>>problems.
>	This is correct.

Thank you for understanding!

>	No, we gave it up for at best a 33% increase in speed (for
>writes: (1.5-1.0)/1.5 by your way of calculating, 50% (1.5-1.0/1.0)).

This is deceptive.  The uncoupled trackdisk.device is 33% faster than
the (hypothetical) coupled trackdisk.device FOR WRITES ONLY.  For
reads they are the same speed.  I contend that I read (about) 5 times
as many tracks as I write.  Taking a weighted average gives 7% OVERALL.

  Saying that the uncoupled trackdisk.device is 33% faster than the
  (hypothetical) coupled trackdisk.device is no more valid than saying
  that they are the same speed.  The first statement would be true if
  the system only performed writes.  The second statement would be true
  if the system only performed reads.  My weighted average is a better
  description of the performance the average user will see.  So I still
  say its about 7%.

>Also, read vs write percentages aren't probablistic, since usually you're
>writing something or reading something, rarely both simultaneously.
>(ignoring the requirement to read a track in order to write it).

If I have used my computer for two hours in some activity such as
compiling, the total number of track reads and the total number of
track writes will determine the disk performance I will see.  In that
sense it IS probablistic.  But I really don't see the point of this
statement anyway.  The important thing is how long it takes to get the
task done.

>	Now, assuming we were to lock writes to the index (I'm not saying
>that we will).  What would be the hard advantages (precisely)?  Remember,
>trackdisk is unlikely to do badblock mapping, since it has no spare
>blocks/tracks to play with, and must support both SFS and FFS and anyone
>else who uses it.  Are there any advantages other than DiskSalv being
>slightly better at recovering files on a disk with errors?
>-- 
>Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup

[This goes back to my first posting.  It has probably expired on most
 machines.  In fact I never saw the note this note was responding to.
 Oh well.  Hopefully the part you included is the meat of it.]

> Use disks without flaws.
>	Sullivan Segall

How do you know a disk has no flaws?  Formatting does not tell you.
The format program only puts data on parts of the track.  Other parts
of the track can be flawed and will still pass Format/Verify.
However, these flawed parts can still bite you on later track writes.
That is because the data can be written anywhere on the track, not
just on the originally formatted part.

Question: How much of the track is not used?

If I assume 5% of the track is not used then for any given track, you
have a 5% probability of not noticing it if there is a defect on the
track.  If I format 50 floppys and 3/10 of them have a defect (I saw
this failure rate in a box of brand new Sonys I bought) then there
will be a 54% probability that one of the bad disks will go undetected
during format.  (see derivation below)

So the chances are pretty high that I will have a disk that formatted
OK but has a hidden defect.  There is a 95% probability that the
defect will hit real data the first time I write to the track on that
defective disk.  Yuck!

--------------------------------------------------------------------
derivation:
 Assume 1 defect/disk.  The probability of formatted data landing on
 the defect is 0.95 or 95%.  (This probability is strictly a function
 of the probability for the one track with the defect.)

 Given 50 floppys and a 3/10 defect rate, there will be 15 bad disks.

 Looking only at the bad disks, the probability that all of the
 defects will be caught during Format/Verify is: 0.95**15=0.46 or 46%.

 That probability is not affected by the good floppys: 1**35=1
 0.95**15 * 1**35 = 0.46*1 = 0.46.

 So the probability that one of 15 bad disks will escape detection
 is:  1-0.46=0.54 or 54%.
---------------------------------------------------------------------

All of the above numbers assume the current AmigaDos trackdisk.device
which does not couple to the index pulse.  If you couple the
trackdisk.device, the probability of a defect migrating into the data
area after a successful Format/Verify goes to 0%.  What this buys me
is confidence that a disk which has been Format/Verify'ed is in fact
good.  Without the index coupling I can never have that confidence.

Randell, thank you for responding.  I seem to have trouble
communicating with Ford.  I am trying to write clearly, but sometimes
I fail to.  You seem to be good at decifering my meaning.
--
Charles Brown	charles%hpcvca@hplabs.hp.com