🚀 go-pugleaf

In article <81.filbo@gorn.santa-cruz.ca.us> filbo@gorn.santa-cruz.ca.us (Bela Lubkin) writes:
> Transfer rate is not an insignificant problem either: since Amiga-format
> floppies don't use sectors, an entire track must always be read.  At 360
> RPM, that's 1/6 second.  (Or is it 300 RPM and 1/5 sec?)  I suspect that
> trackdisk.device also waits for start-of-track before beginning to read,
> adding another 1/12 sec average latency.

300 RPM; 200 ms.  To make sure it gets all 11 sectors, the trackdisk.device
actually reads about 1.1 revolutions, 220 ms.

Since worst-case seek is 79*3 = 237 ms seek time +15 ms settling time =
252 ms is not much worse than the time to actually read a track, I came to
the conclusion that it's important to get a lot out of a track, but
after that, which track it is isn't terribly important.

> Anyway, what you (and I) want is a track cache.  Why try to speed up the
> seeking when it isn't necessary?  Most of that back-and-forth seeking is
> reading the same two tracks alternately as the 2 processes each read the
> next data.  If trackdisk.device cached just 2 tracks for each drive (the
> previous one and the current one), much of the contention would go away.
> Not all of it, but enough to make me much happier...

Apparently, it's being added.  The original 0.95 (or whatever it's called)
trackdisk.device cached multiple tracks, but then they decided that was too
memory-hungry.  Since memory is getting cheaper, the feature is coming back.

> Just a sanity check here: I don't THINK "AddBuffers" does this.  It sure
> sure SEEMS as if AddBuffers buffers contain only logical "sectors" which
> have already been read, which are exactly those that are NOT going to be
> reread when 2 processes are fighting over a drive for sequential access.

AddBuffers doesn't do this.  Addbuffers is AmigaDOS' cache, and it doesn't
know that the trackdisk.device has already done all the work of reading in
all the other sectors on this track, so AmigaDOS doesn't think to cache
them.  The result, when two reads are being interleaved, is that it reads
one sector from each track before seeking to the next, resulting in less
than 1/11 of the maximum transfer speed.  Bad news.

Read-ahead could also alleviate the problem to a degree.
-- 
	-Colin