Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!uwmcsd1!lakesys!jason
From: jason@lakesys.UUCP (Jason)
Newsgroups: comp.sys.atari.st
Subject: Re: my ideal cache program
Summary: No, but it wouldn't have to always be a Track, persay
Message-ID: <796@lakesys.UUCP>
Date: 6 Jul 88 03:08:41 GMT
References: <157@cstw01.UUCP> <2752@bath63.ux63.bath.ac.uk>
Organization: Lake Systems, Milwaukee Wisconsin
Lines: 29

In article <2752@bath63.ux63.bath.ac.uk>, pes@ux63.bath.ac.uk (Smee) writes:
> 
> My (rather limited) investigations lead me to believe that your '(optional)
> read-ahead' -- i.e. convert sector reads to track reads and cache the whole
> track -- unless of course you've already got it -- probably offers the
> greatest potential for speedup.  However, I haven't yet designed such a thing
> clever enough to deal with the fact that not all my disks are laid out with
> the same number of sectors/track.
> 
> Cheers, Paul

	No, you wouldn't be able to figure out exactly what a track was, but
it wouldn't seem that it would matter all that much... The things that need
the most speedup are the floppies, so you could use the Sectors/Track value
from the floppies (Of course, there may be problems there too, due to the
different formatters running around), and just use the same value for HD
buffering. It would seem that even though you'd get more seeks than would be
completely optimal, it'd be an improvement over the original (non-buffered)
scheme.

	Of course, you could have a config (or run-time if it were a DA) that
would allow the user to set different sector/track ratios for each unit (drive
letter, whatever you want to call it), with reasonable default values. This
would allow for a very respectable speedup for those who don't know much about
the guts of their machine, and a larger speedup for the techies in the crowd.

-- 

	Jason - Not your average iconoclast