reisert@tallis.enet.dec.com (Jim Reisert) (05/31/90)
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 01460reisert@tallis.enet.dec.com (Jim Reisert) (06/01/90)
Hello Again, At the suggestion of Rich Wilson (richw@hplsla.hp.com), I measured the cache performance while compiling a 58K .C demo included with my Quick-C package. For all the tests, I loaded the cache from scratch, entered Quick-C, compiled the file (into an executable image), exited Quick-C, and took the cache measurements. I also timed the compile time, which varied from 22 seconds (no cache) to 20 seconds (using Super PC-Kwik or PC Tools version 5.5). Here are the stats: PC Tools v 5.5 cache, 384K in expanded memory (MAX=4): 276 reads saved / 646 reads = 42% saved PC Tools v 5.5 cache, 384K in expanded memory (MAX=20): 364 reads saved / 701 reads = 51% saved PC Tools v 6.0 cache, 384K in expanded memory (MAX=4): 632 reads saved / 3594 reads = 17% saved Super PC-Kwik v 3.19 cache, 384K in extended memory: 367 reads saved / 824 reads = 44% saved So caching didn't really save any time (maybe I need some bigger test programs), but there are some definite differences between the above programs. I was also told there was a new version of the PC Tools v 6.0 cache on the Central Point BBS - I'm going to try to download it tonight and see if it makes a difference. Ciao for now. 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
scholes@snoopy.Colorado.EDU (SCHOLES MARTIN LEE) (06/01/90)
I posted a couple of months ago looking for a cacher that could deal with me having a 386 running QEMM, and my MScribe 3085 (>1024 cyls). I recieved few responses, and I had tried at least 2 dozen cachers (and rebuilt my scrambled drive after each test). Finally I was told to try FLASH! from software masters. I payed the stiff $75 price, with the assurance that ANY incompatibility problems would be resolved. The result? This little piece of software moves. After I writhed my way through the barrage of copy protection, I had a very fast, very small (8k of conventional memory), and very solid cache. Every single cacher I tried prior to this either: ran slower than no cache, locked up for no reason, locked up when trying to write the inner >1024 cyls of my drive, refused to write the inner cyls of my drive (chkdsk loved this), or wrote the inner cyls VERY slowly. With the exception of the lame copy protection, this is the best cacher I've ever used. Anyone looking for one should at least call this company at (317)253-8088. scholes@snoopy.colorado.edu
reisert@tallis.enet.dec.com (Jim Reisert) (06/01/90)
In article <12113@shlump.nac.dec.com>, I write, >PC Tools v 5.5 cache, 384K in expanded memory (MAX=4): > 276 reads saved / 646 reads = 42% saved >PC Tools v 5.5 cache, 384K in expanded memory (MAX=20): > 364 reads saved / 701 reads = 51% saved >PC Tools v 6.0 cache, 384K in expanded memory (MAX=4): > 632 reads saved / 3594 reads = 17% saved >Super PC-Kwik v 3.19 cache, 384K in extended memory: > 367 reads saved / 824 reads = 44% saved I downloaded the new PC Tools v 6 cache from the Central Point BBS last night (I think the new cache is version 6.03, if I read the timestamp right as being 18:03). Anyway, using the same parameters as above, the compile completed in 19 seconds (vs 20-21 secs. for the other caches above) and the hit rate rose to around 21% or so. Still nothing to write home about, in my book, but maybe they do figure writes in the count of logical transfers (only makes sense). But that doesn't explain why there are so so many more logical transfers when I boot than with the v5.5 cache. Does anything get written to the disk when you boot, normally? I think not. Further bulletins as events warrant. 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
joel@peora.ccur.com (Joel Upchurch) (06/03/90)
I noticed the same problem where my hit ratio went way down when I
"upgraded" from PC-Cache 5.5 to 6.0. I use a 1 megabyte expanded
memory cache. I think that the problem is real, because I can see
disk accesses happening (via the disk access light). I tried adjusting
some of the parameters, especially the MAX= one, but it didn't seem
to help. I've heard that the new PC-Cache is a complete rewrite from
the old one. I think that the new version, just plain has some bugs.
I wonder if the problem might be because I have a 65 megabyte drive,
set up as a single logical volume under DOS 4.01. I've went back to
the 5.5 version for the time being.
--
Joel Upchurch/Upchurch Computer Consulting/718 Galsworthy/Orlando, FL 32809
joel@peora.ccur.com {uiucuxc,hoptoad,petsd,ucf-cs}!peora!joel (407) 859-0982DOUG@ysub.ysu.edu (Doug Sewell) (06/03/90)
The way I heard it:
The cache in PCTOOLS 4.0-4.11 or so was written by Central Point.
It was buggy, particularly in the way it handled Extended memory.
In PCTOOLS 4.22 (I had copies of both 4.11 and 4.22), the cache
was changed to PC-Kwik, licensed from the vendor. It didn't have
all of the bells-and-whistles of Super-PC-Kwik.
This difference caused grief for a friend that swore he had a bad
ram-chip (instead, it was the 4.11 cache - when he upgraded to 5.x,
he got the new cache and the problem went away).
The cache in 6.0 is reported to be Central Point's - and apparently
it still has some lingering bugs. I haven't gotten my R6 yet, but
I've already decided to save my R5.5 cache program.
Doug Sewell, Tech Support, Computer Center,
Youngstown State University, Youngstown, OH 44555
E-mail: DOUG@YSUB.BITNET, DOUG@YSUB.YSU.EDU, ...!uunet!ysub.ysu.edu!doug
>> I am not a wizard. What I do isn't magic. I am a computer professional.ted@helios.ucsc.edu (Ted Cantrall) (06/06/90)
In article <90153.161322DOUG@ysub.ysu.edu> DOUG@ysub.ysu.edu (Doug Sewell) writes: >The cache in 6.0 is reported to be Central Point's - and apparently >it still has some lingering bugs. I haven't gotten my R6 yet, but >I've already decided to save my R5.5 cache program. > Doug, I am in the same place you are in terms of up-grade. But I am wondering if R5.5 CACHE will even work in the R6.0 environment. You seem to think it will: please tell me why. -ted- ------------------------------------------------------------------------------- ted@helios.ucsc.edu | "If I get any phone calls while I'm gone, (408)459-2110 | just don't answer them." -------------------------------------------------------------------------------