Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!cpqhou!scotts
From: scotts@cpqhou.UUCP (Scott Shaffer)
Newsgroups: comp.sys.ibm.pc
Subject: Re: What is the best way to determine cache size?
Message-ID: <537@cpqhou.UUCP>
Date: 12 Feb 90 06:00:00 GMT
References: <2525@leah.Albany.Edu> <16019@oregon.uoregon.edu>
Distribution: usa
Lines: 45

> In article <2525@leah.Albany.Edu>, emb978@leah.Albany.Edu (Eric M. Boehm) writes:
> > I currently use a disk cache on my 386/25. I had previously set it to 1
> > MB. However, this is ridiculously large (so as to be counterproductive).
> > I downsized it to 384 KB. This is probably still much too large. I
> > received a suggestion that 64 KB is probably a better size (since that
> > is the size of hardware caches on most machines with hardware caches).
> > That doesn't seem like a real good reason to me.
> 

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

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. 

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


+==========================================================================+
| Scott Shaffer    |  Compaq Computer Corporation @ Houston TX             |
| Systems Engr     | (These opinions do not necessarily reflect those of my|
|		   |  employer, friends or any living person.)		   |
+==========================================================================+
"Well son, regret is a funny thing; it's better to regret something you
 have done, than to regret something you haven't done."