Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!decuac!shlump.nac.dec.com!tallis.enet.dec.com!reisert
From: reisert@tallis.enet.dec.com (Jim Reisert)
Newsgroups: comp.sys.ibm.pc
Subject: Disk Caches - PC-Tools & Super PC-Kwik
Message-ID: <12067@shlump.nac.dec.com>
Date: 30 May 90 20:27:14 GMT
Sender: newsdaemon@shlump.nac.dec.com
Organization: Digital Equipment Corporation
Lines: 109

Hi,

I am baffled by the performance of the disk cache included in PC Tools
release 6.0.  It seemed to have a much lower hit rate than the cache
included with release 5.5.  I'm looking for any insight as to the
differences.

First, from what I understand, Central Point licensed Multisoft's cache for
use in PC-Tools 5.5.  I heard a rumor today that they the wrote their own
cache for version 6.0.

Using a 256K expanded memory cache (more on this later) with a MAX=8, I
obtained the following readings from PC-CACHE 5.5:

	127 logical reads
	 69 physical reads
	 58 reads saved
	 45% saved

Here are the corresponding numbers from PC-CACHE 6.0:

	774 logical reads
	706 physical reads
	 68 reads saved
	  8% saved

Somethings seemed rotton in Denmark - why so many more reads using the
second cache? I bumped MAX up to 20 (according to the manual, this should
buffer entire tracks if one sector is read from a track).  I obtained
similar numbers.

More on the expanded memory cache.  Someone here at work suggested I use an
extended, rather than an expanded memory cache.  I did this by telling QEMM
to reserve 256K of extended memory.  I was somewhat perplexed by the
results.  According to the memory command in 4DOS, I had the following
memory available before I started the cache:

	Conventional:	601,696
	Extended:	262,144
	Expanded:	835,584

[Note: This was the same amount of expanded memory I had available after
       starting PC-CACHE in expanded memory.]

Next, I started PC-CACHE 5.5 with a /SIZEXT=256 parameter (256K extended
memory cache).  Then my numbers read as follows:

	Conventional:	601,696
	Extended:	262,144
	Expanded:	573,440

It appeared that the cache had pulled memory out of the *expanded* pool, not
the extended pool.  I found this to be unusual, and I wonder if anyone can
explain it.

Finally, I tried my good 'old Super PC-KWIK cache that came with the
computer.  This cache would only run in extended memory (although it's help
suggested that the "/A" parameter would load the cache into expanded memory,
however, neither the program nor the documentation supported this).  Loading
it into a clean system resulted in the following numbers:

	Conventional:	601,450
	Extended:	no free extended memory listed
	Expanded:	835,584

This seemed more 'normal' to me than the experience with PC-CACHE running in
extended memory (where expanded, not extended, memory vaporized).

Finally, I booted the system using the SuperPCK cache (as I had done
originally), and checked the measurements:

	128 logical reads
	103 physical reads
	 25 reads saved
	 19% saved

One thing to note is that according to the Super-PCK documentation, each
time a sector is read in from a track, the entire track is read into the
cache.

So from all this I gather that:

1.  I don't believe the measurements from the PC Tools 5.5 cache.  The hit
    rate seems much too high.

2.  I don't believe the measurements from the PC Tools 6.0 cache.  Why
    should there have been six times as many logical requests, since booting
    did the same thing each time?

I went on the 'best two out of three' philosophy.  If you believe that the
cache with the very high hit rate is bogus, as is the cache with the very
high logical read rate, then the only cache I can believe is Multisoft's
Super PC-Kwik.  Time to send in my registration card so I can call Central
Point Software (makers of PC Tools) and find out what's up!

If anyone wishes to share any insight, it would be muchly appreciated.

jim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

"The opinions expressed here in no way represent the views of Digital
 Equipment Corporation."

James J. Reisert                Internet: reisert@tallis.enet.dec.com
Digital Equipment Corp.         UUCP:     ...decwrl!tallis.enet!reisert
295 Foster Street
P.O. Box 1123
Littleton, MA  01460