riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (09/24/88)
In article <40244@linus.UUCP> eachus@mitre-bedford.arpa (Robert I. Eachus) writes: [somebody else wrote this, but the attribution has gotten lost. *sigh* ] >> * 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. >>We gave up track reliability for at best a 7% increase in overall >>floppy speed. > Not quite, Charles, adding track reliablity won't cost even that >much. Right now, trackdisk.device must rewrite an entire track even if >only one sector is changed, and more important must read a track >completely to write one sector. If a "smart" trackdisk.device knows >where sectors are located, it can do single sector writes in an >average of 0.7 rotations, instead of 2.2. I was under the impression that you could not do single sector writes without increasing the inter-sector gaps, which would mean giving up a sector/track. As it stands now, there is not enough space between sectors to reliably place the heads for a single sector write. Wasn't the extra space part of the point of having a trackdisk.device? Also, I would think you would want to sync reads to the index mark when you are trying to recover sectors from a damaged track. Otherwise, you have to rely on ferreting out where the track starts from damaged information, which seems a lot less reliable than knowing where on your damaged track the sectors should be. -dan riley (dsr@ln61.tn.cornell.edu, dsr@crnlns.bitnet) -wilson lab, cornell u.
jesup@cbmvax.UUCP (Randell Jesup) (09/24/88)
In article <40244@linus.UUCP> eachus@mitre-bedford.arpa (Robert I. Eachus) writes: > 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. >>We gave up track reliability for at best a 7% increase in overall >>floppy speed. 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)). 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). > Not quite, Charles, adding track reliablity won't cost even that >much. Right now, trackdisk.device must rewrite an entire track even if >only one sector is changed, and more important must read a track >completely to write one sector. True, you must currently read a track before writing it. > If a "smart" trackdisk.device knows >where sectors are located, it can do single sector writes in an >average of 0.7 rotations, instead of 2.2. No, because the inter-sector gaps are not large enough to support this (which is also why we can squeeze 880K onto a floppy, instead of 720k (11 sectors/track/side, vs 9)). If we cut down the storage to 720K, we could do that (which is how we read/write IBM disks now). 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
charles@hpcvca.HP.COM (Charles Brown) (09/25/88)
>> 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
ncreed@ndsuvax.UUCP (Walter Reed) (09/26/88)
Well, I've been following this discussion about coupling track writes to the index hole on the disk. Since this is 100% backward compatible, why not put out a version of the trackdisk.device that does this and call it something like indextrack.device and let people mount it on their floppies and try it out for themselves. Then a companion program could assigndev df1: to the mounted device (fd1:) and everything would be rosey. Geez, this wouldn't be THAT hard would it? It's the same thing (close enough anyway) as the way FFS runs on floppies now. God it would be nice to UnMount devices (please add to 1.4...) -- ------ Walter Reed ------ + uunet!ndsuvax!ncreed or ncreed@ndsuvax.BITNET "There's no point in being + or ncreed@plains.NoDak.edu grown up if you can't be + childish sometimes!" Dr. Who + USnAIL: 925 9th Ave W. West Fargo, ND 58078
Sullivan@cup.portal.com (09/28/88)
> > > 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. > I think he was taking issue with your statement "at *BEST* a 7% increase..." > > > 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. > My experience with 3" floppies has been: Single sided disks have many flaws on their untested sides. Disks which commonly sell for less than $1.20 ea. have innumerable flaws on both sides (dual sided or not.) FUJI disks have no flaws (I haven't encountered a single error in the more than 200 fuji disks that I am now using, and have used for the past year and a half. Mileage may vary. Kodak disks also give me no problems Sony, Precision, and Generic are the worst offenders of those I've tried, listed from worst to best. No company truly produces nothing but flawless disks, but there is sufficient margin for error in the media that it really doesn't matter, as long as they have high standards and reasonable levels of QA. (In my experience about 3 in 10 Sony's were bad, 2 in 10 Precisions and 2 in 10 Generic, depending on the batch, with an unusually large standard deviation.) > --------------------------------------------------------------------- > > 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. > > Charles Brown charles%hpcvca@hplabs.hp.com -Sullivan Segall (still looking for a 68881 that can be piggy-backed on a 68000) _____________________________________________________________ /V\ My opinions are guaranteed to be worth at least what you ' paid for them. If you are dissatisfied, please return them to the nearest vendor for a full and prompt refund. To Quote the immortal Socrates: "I drank what?" -Sullivan _____________________________________________________________ Mail to: ...sun!portal!cup.portal.com!Sullivan or Sullivan@cup.portal.com
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (09/29/88)
In article <40244@linus.UUCP>, Robert I. Eachus (eachus@mitre-bedford.arpa) was commenting on a suggestion to begin floppy disk writes at the index hole when he wrote: > . . . Right now, trackdisk.device must rewrite an entire track even if > only one sector is changed, and more important must read a track > completely to write one sector. If a "smart" trackdisk.device knows > where sectors are located, it can do single sector writes in an > average of 0.7 rotations, instead of 2.2. . . . Nope. In order to get 880K bytes on a disk (instead of 720K), trackdisk writes 11 sectors in succession, *without* the intersector gaps that are found in the "normal" (i.e., 720K) format. Attempting to write a single sector would result in trashing the end of the previous sector or the beginning of the next, depending on the relative timing of the write to that of the previous ones. Thus, it is still necessary to both read and write a track at a time. Steve Rice ----------------------------------------------------------------------------- * Every knee shall bow, and every tongue confess that Jesus Christ is Lord! * new: stever@videovax.tv.Tek.com [phone (503) 627-1320] old: {decvax | hplabs | uunet | uw-beaver}!tektronix!videovax!stever
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (10/01/88)
Out of over 6000 Sony double-sided bulk floppies I have used, I have had about 12 go bad. -tom
thad@cup.portal.com (10/02/88)
Out of over 3,000 SONY 3.5" DS/DD disks I have, only 1 went "bad". In retrospect, the "badness" was before I installed proper surge protection and AC line conditioning to the Amigas; absolutely NO problems in the almost 3 years since (the UPS installation). In any event, the "bad" disk provided an opportunity to satisfy my curiousity re: "what's in there?" :-) Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
jburnes@pnet02.cts.com (Jim Burnes) (10/03/88)
oh steve:
by the way...i dont think that my knees are going to do any bowing
or my tongue any confessing about jesus christ being lord. this is
a tech group not a religious summit.
j burnes
UUCP: {ames!elroy, <backbone>}!gryphon!pnet02!jburnes
INET: jburnes@pnet02.cts.com