Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!ames!husc6!rutgers!cbmvax!ditto From: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Newsgroups: comp.sys.amiga Subject: Re: Request to Commodore (Bad Blocks) Summary: Ok, I understand the suggestion now (but the numbers are still right) Keywords: trackdisk Message-ID: <4806@cbmvax.UUCP> Date: 23 Sep 88 07:35:21 GMT References: <8891@cup.portal.com> <5660018@hpcvca.HP.COM> Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Organization: Commodore Technology, West Chester, PA Lines: 52 In article <5660018@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >I will paraphrase what I said: > ------------------------------------------------------------------- > * DO NOT CHANGE THE WAY YOU READ. ONLY CHANGE THE WAY YOU WRITE. * > ------------------------------------------------------------------- Ok, I was confused about your suggestion. (I went back and read the first article and now your second article makes sense; thanks to Peter DaSilva for kicking me in the right direction). Most of the rest of my article makes sense only if we are comparing trackdisk to non-trackdisk (as I thought we were), but you were comparing trackdisk to hypothetical-modified-trackdisk and your figures did make sense all along to anyone who read your original posting. >> 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. Again, I was replying to a completely different interpretation of your message so I wasn't making much sense. But "usefulness" does have a lot to do with trackdisk input; those other ten sectors that are automatically read in when you ask for the first one can't be counted toward the throughput figures unless they will actually be requested and used by some program before they are flushed. This does not affect your proposal though. >We gave up track reliability for at best a 7% increase in overall >floppy speed. I think this statement is what led me off onto the wrong track... you make it sound as if we *used* to have this capability and lost it by going to track-at-a-time reads. But I realize you are suggesting an improvement to trackdisk, which can gain us this capability at only a slight performance penalty. I also agree with the way you came up with the 7% estimate. >It amazes me how easy it is to respond to a note without reading it. Actually, the problem was that I didn't read the first one, therefore the second one made no sense. Sorry. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.cbm.commodore.com