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