Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!bu-cs!mirror!prism!rob
From: rob@prism.TMC.COM
Newsgroups: comp.sys.ibm.pc
Subject: Re: (Disk) Cache problems...
Message-ID: <206900142@prism>
Date: 27 Nov 89 13:51:00 GMT
References: <638@ariadne.csi.forth.GR>
Lines: 39
Nf-ID: #R:ariadne.csi.forth.GR:-63800:prism:206900142:000:1922
Nf-From: prism.TMC.COM!rob    Nov 27 08:51:00 1989


>Problem : CACHE programs.
>Machine : IBM AT 6Mhz, 30 Meg. Hard disk, 1.5 Meg. extended memory.
>Symptom : 
>                         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
>    
>          This means that when I compile a C program I develop, I see NO
>          difference in compile times, whether using the cache or not.
>          I notice the same phenomenon even when I use the Compaq's or
>          Zenith's Cache programs, but I mention PC-CACHE because its 
>          performance is the best of all.
>          (I use command line version of Microsoft C 5.1 and/or Quick C)
>Question: What is going on there?

   Two things - first, on a 6Mhz machine, the disk is probably not your
real bottleneck unless it's a very slow disk. As a result, speeding up
your disk access times can only go so far to speed up your overall
compile times.

   Second, the benchmarks you cited check disk transfer rate (actually, 
Norton's DI checks both access time and transfer rate). This is only one
element of disk performance, and the way these benchmarks measure it 
produces unrealistic numbers when used with a cache.

   Most transfer rate benchmarks work by reading the same sector many
times, and checking how long this takes. When you're using a disk cache,
only the first read (out of perhaps 1000) actually involves going to the
disk. From then on, the data is in the cache, so you're simply timing
the speed of memory moves. The result is an excessively high figure,
that won't be duplicated, or even approached, using 'real world'
applications.

   (I have a machine - a Dell 325 - that, when measured with a disk cache,
produces a transfer rate of 4Mb/second. I wish that were a meaningful
number, but it's not.)