Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!microsoft!w-colinp
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Floppy speed.
Message-ID: <1186@microsoft.UUCP>
Date: 30 Mar 89 11:46:45 GMT
References: <9853@polyslo.CalPoly.EDU> <67@microsoft.UUCP> <6407@cbmvax.UUCP>
Reply-To: w-colinp@microsoft.uucp (Colin Plumb)
Distribution: na
Organization: very little
Lines: 25

jesup@cbmvax.UUCP (Randell Jesup) wrote:
> 	Actually trackdisk overhead comes into play here.  Trackdisk
> throughput is about 21-22K/sec including decode, checksum, and transfer to
> the users buffer for large reads.

H'm... can't the trackdisk.device overlap reading one track and decoding
another?  Actually, I think you'd need multiple track buffers... maybe
you could share them between different floppies?  Yeah, that's the ticket!
It makes the locking a bit more complex, but not too horrible.

(I could envision a scheme where you start decoding a buffer and start
a DMA into the same buffer, relying on the blitter being faster than the
disk DMA.  Now *that's* horrible!)

> 	Overhead should be cut for 1.4, but don't forget filesystem gets
> in there too, and there isn't a lot of overhead.  Most of the time the disk
> is actually spinning or moving the heads.  Even cutting overhead in half
> will only add 10% or so to the transfer rate.

Well, thanks for the info.  Now I know not to wonder so much when my
filesystem fails to do 25K/sec.
-- 
	-Colin (uunet!microsoft!w-colinp)

"Don't listen to me.  I never do." - The Doctor