Path: utzoo!censor!geac!maccs!cs4g6ag
From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: (Disk) Cache problems...
Keywords: Cache
Message-ID: <2574A18E.4928@maccs.dcss.mcmaster.ca>
Date: 30 Nov 89 03:42:05 GMT
References: <638@ariadne.csi.forth.GR>
Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn)
Distribution: comp
Organization: McMaster University, Hamilton, Ontario
Lines: 28

In article <638@ariadne.csi.forth.GR> bluguras@csi.forth.gr (Blougouras Dimitris) writes:
$Machine : IBM AT 6Mhz, 30 Meg. Hard disk, 1.5 Meg. extended memory.
$                         No Cache     |  PC-CACHE  
$                        --------------+---------------
$          Norton's DI      1.9        |    4.9    
$          Coretest       202.9 Kb/sec |  985.6 Kb/sec
$          Compiling       77 sec      |   75 sec
 
   That's really odd!  With 1.5M of cache, your entire compiler, source,
object, and libraries should easily fit into the cache.  Of course, shifting
back and forth between protected mode and real mode takes time, but it
shouldn't take _that_ much time!  You are using the whole 1.5M of extended
memory as a cache, right?

   Have you tried playing with PC-Cache's parameters, such as the number
of sectors to batch transfer at once?

   BTW, figures returned by any program which simply tests the data trans-
fer rate by repeatedly reading one or two tracks will be absolutely
meaningless.  My disk drive has a data transfer rate of roughly 200Kb/s,
but coretest reports over 1.5 Mb/s with a 384K cache.   This is quite
unrealistic for any program except one that repeatedly reads the same
track or two.
-- 
Stephen M. Dunn                               cs4g6ag@maccs.dcss.mcmaster.ca
          <std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
They say the best in life is free // but if you don't pay then you don't eat