Path: utzoo!censor!geac!maccs!cs4g6ag
From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn)
Newsgroups: comp.sys.ibm.pc
Subject: Re: What is the best way to determine cache size?
Message-ID: <25E952E9.160@maccs.dcss.mcmaster.ca>
Date: 26 Feb 90 16:01:44 GMT
References: <2525@leah.Albany.Edu> <16019@oregon.uoregon.edu> <537@cpqhou.UUCP>
Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn)
Organization: McMaster University, Hamilton, Ontario
Lines: 55

In article <537@cpqhou.UUCP> scotts@cpqhou.UUCP (Scott Shaffer) writes:
$Well, I think the answer lies in what disk-cache you are using and what
$algorithm they use.  It is a fact that the larger the cache you have, the
$larger the look-up table must be.  Since this table is what the driver
$uses to determine what is in the cache and whether to get it from a cache
$buffer or read from the disk.  If you have a large disk, and the algorithm
$cache's, say, 1-8 sectors at a time, then it is possible that a large
$cache will actually have a performance degredation over a smaller one, due
$to the fact that searching the table will require a little time.  However,
$if the program uses an algorithm that cache's entire tracks (like Compaq's),
$then there is *NO* performance degredation, even with caches of 16MB.  Thus,
$the answer should be to a) figure out what algorithm the cache uses, and
$b) figure out how much memory you are willing to give up for the cache.
$I personally run 4MB of cache because I have the memory and use it for
$nothing else (I also run 2MB VDISK and 9MB EMM).

   Yes, it's a fact that for a large cache, a larger look-up table must
be used.  However, large look-up table does not necessarily mean long
look-up times, and neither does caching individual sectors.  The smart way
to implement a look-up table for a disk cache is through hashing, and a
well-designed hashing algorithm will show about the same look-up time on
average for a large table as for a small one.

$The algorithm that cache's whole tracks is under the assumption that most
$disk accesses will be sequential (sector to sector), so cacheing the whole
$track will result in significant better performance by a program that is
$going to read multiple sectors from the same track (this is most common in
$database applications, and CAD work).  If, however, you acesses different
$tracks, then you will have cache misses.  One person noted that this will
$actually take more time (it will), but this will be negligable, because even
$if the cache table is 20KB (for large caches only), the time it takes to
$CMP AX,[cache] that 20KB will be VERY little on 386/25 machines. 

   Even caches which don't read in the entire track may well do look-ahead
reads ... PC-Cache, for example, will do "batch copies" if you want, and this
means that when you access one sector, it will read in up to the remainder
of the current track (not including sectors earlier than this one, I believe)
based on the assumption of primarily sequential access, yet it is a sector-
oriented cache.  IBMCACHE.SYS will also read multiple sectors if you want it
to, and I would imagine that at least some versions of PC-Kwik will do this
too, since PC-Cache is licenced from them.

$Obviously, if you can add to the controller cards memory cache, that will
$be the best solution (unfortunately, this probably isn't an option).

   Although some software (don't ask me what packages specifically) won't
work correctly with caching controllers or with memory-resident disk
caches, and in the case of such software you're better off with a software
cache because you can remove it at will (at the worst, you'd have to
reboot, and some caches can be removed without rebooting).
-- 
Stephen M. Dunn                               cs4g6ag@maccs.dcss.mcmaster.ca
          <std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
               I Think I'm Going Bald - Caress of Steel, Rush