Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!cory.Berkeley.EDU!iverson
From: iverson@cory.Berkeley.EDU (Tim Iverson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: PC Cache programs
Message-ID: <3928@pasteur.Berkeley.Edu>
Date: 14 Jun 88 18:40:05 GMT
References: <1304@spdcc.COM>
Sender: news@pasteur.Berkeley.Edu
Reply-To: iverson@cory.Berkeley.EDU.UUCP (Tim Iverson)
Distribution: na
Organization: University of California, Berkeley
Lines: 28

In article <1304@spdcc.COM> eli@spdcc.UUCP (Steve Elias) writes:
>i've benchmarked the Compaq disk cache on my 10 MHz ALR at and
>the results seem to stink...  i'm using 384k of extended memory 
>as cache...  the result is that using the cache actually slows the
>machine down.  the disk drive is not fast, either:  40 ms st251...
>
>i believe that this can be accounted for by the bios calls necessary
>to switch into and out of protected mode.  the overhead must be slowing
>the cache access down...  any comments ??


Before you can decide whether it is in fact the bios block move calls or
not, you would have to know the hit rate on your cache.  At 6Mhz, the bios
block move call can move 512B (the most common sector size) in about 1ms.
Since your drive's latency is 40ms, this might suggest that it is the cache
implementation and not the extended memory transfer.  If the cache tries to
do something moderately fancy like read-ahead, and you're not accessing
sectors sequentialy (sectors, not file records - a sequentialy accessed file
on dos is not guarenteed to result in requests for sequential sectors on the
disk) then performance could indeed be very bad since each read would induce
several other totaly useless read-aheads - thus reducing the hit rate on
the cache.  My guess would be that whoever wrote the cache wasn't really
up to doing a good job.


- Tim Iverson
  iverson@cory.Berkeley.EDU
  ucbvax!cory!iverson