Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!ucscc.ucsc.edu!gorn!filbo
From: filbo@gorn.santa-cruz.ca.us (Bela Lubkin)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Smooth Operator (for disks)
Summary: You want a track cache
Message-ID: <81.filbo@gorn.santa-cruz.ca.us>
Date: 9 Nov 89 03:27:36 GMT
References: <5850@ucdavis.ucdavis.edu>
Organization: R Pentomino
Lines: 51
X-Claimer: I >am< R Pentomino!

In article <5850@ucdavis.ucdavis.edu> Tak (UlTech) AuYeung writes:
>I noticed that disk accesses are mostly delayed by the seek time
>of the disk head (vs. the actual transfer time), especially in
>a multitasking environment.  Even if you use a disk optimizer,
>two processes trying to access data on different cylinders will
>make the disk seeking mechanism very busy.  For hard disks
>owner, this problem may be minute, but for most floppy-only
>Amigans, the seek operation is noisy, slow and bad for the
>media (floppy disks).

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.

The point so far is: if you had a magic drive with 0 seek time you would
still wait an average of 1/4 (3/10?) sec for each competing disk access.

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...

Proposal: trackdisk.device should cache a user-settable number of tracks
for each drive.  The cached tracks should be in data format (i.e., after
being run through the blitter) and should optionally be storable in fast
memory (at the expense of using the 68000 to move them there).

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.

Likewise, though ASDG's FACCII helps, it caches sectors, not tracks, and
does not seem to keep sectors that were read because a different part of
the track was needed.  The documentation does not say anything about it;
perhaps Perry or someone else from ASDG can comment?

Anyway, I'd rather have a simple two-track cacher than FACCII; ARes does
most of what I would need a floppy cacher for and a 2- or 3-track cacher
would handle the rest...

{Don't you hate it when your first 3-4 lines match up so neatly that you
just HAVE to finish the rest of the message that way?  ;-}

Bela Lubkin    * *    //  filbo@gorn.santa-cruz.ca.us  CompuServe: 73047,1112
     @       * *     //   ....ucbvax!ucscc!gorn!filbo  ^^^-VERY slow [months]
R Pentomino    *   \X/    Filbo @ Pyrzqxgl +408-476-4633 & XBBS +408-476-4945