Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucsdhub!hp-sdd!hplabs!nsc!pyramid!cbmvax!ditto From: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Newsgroups: comp.sys.amiga Subject: Re: Request to Commodore (Bad Blocks) Summary: trackdisk (vs. sectordisk?) is a reasonably good idea Keywords: trackdisk floppy format Message-ID: <4774@cbmvax.UUCP> Date: 20 Sep 88 07:11:35 GMT References: <8891@cup.portal.com> <5660016@hpcvca.HP.COM> Reply-To: ditto@cbmvax.UUCP (Michael "Ford" Ditto) Organization: Commodore Technology, West Chester, PA Lines: 51 In article <5660016@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >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. 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. 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. 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. 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. 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). 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. A disadvantage of trackdisk, however, is the CPU processing required to "find" the sectors in the track of raw data, and the need to un-MFM the data. I don't know how long these operations take. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com