Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!yale!cs.utexas.edu!usc!srhqla!nrcvax!rick
From: rick@NRC.COM (Rick Wagner)
Newsgroups: comp.sys.ibm.pc
Subject: Re: What is the best way to determine cache size?
Message-ID: <473@nrcvax.NRC.COM>
Date: 14 Feb 90 00:13:02 GMT
References: <537@cpqhou.UUCP>
Reply-To: rick@nrcvax.UUCP (Rick Wagner)
Distribution: usa
Organization: Network Research Corp., Oxnard CA
Lines: 49

In article <537@cpqhou.UUCP> scotts@cpqhou.UUCP (Scott Shaffer) writes:
>> In article <2525@leah.Albany.Edu>, emb978@leah.Albany.Edu (Eric M. Boehm) writes:

(stuff deleted):

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

If your cache software uses the track buffering method, then you
should definately consider using a disk optimizer.  This will ensure
that you get the most sequential data, using up fewer of your buffers.
The cache program I wrote uses track buffers, and is happiest with an
optimized disk.

While it is true that in random access applications (i.e. databases)
you may get alot of misses on the data fields, the key file, which
is repeatedly accessed, as well as the DOS FAT table, will be in
cache.  Caching these blocks will "buy" you alot, even if you can't
hold the entire data base itself.

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

This is a rather broad statement; I'm not sure I would completely
agree.  I have not looked the caching hard disk controllers, so I
don't know the quality of their design.  But, given equal amounts of
memory to use for cache, I would guess a well written cache utility
runnning on a fast (16+ Mhz '386) would hold its own against the same
machine using a less efficiant algorithm on the controller.  At least
in a DOS enviroment, where the CPU would not be doing anything usefull
while waiting for the controller to search its cache, and transfer
from the controller.
	
	--rick
-- 
===============================================================================
Rick Wagner						Network Research Corp.
rick@nrc.com						2380 North Rose Ave.
(805) 485-2700	FAX: (805) 485-8204			Oxnard, CA 93030
Don't hate yourself in the morning; sleep til noon.