ESDI caching disk controllers: Reprise

[Bill Kennedy]

In article <1736 at serene.UUCP> rfarris at serene.UU.NET (Rick Farris) writes:
>In article <1424 at ssbn.WLK.COM> I wrote:
>
>> With a 768K cache memory on one card I routinely get 32% cache hits
>> and with 4Mb on the one in ssbn I get 48-52% cache hits.

I need to make that more clear.  I managed to confuse Rick and confused
myself when I re-read it.  The CompuAdd utility only runs under DOS, it
won't work in VP/ix, maybe with its own driver.  I usually boot native
DOS to check the stats on the way back up from a full backup.  That's got
to wreak havoc with the hit rate.

>That brings up an interesting point.  I think I remember learning
>that without a cache-hit rate of 90% or better, you're generally
>better off without a cache, due to the overhead involved in cache
>misses.  

I think that this is probably true of a memory cache and might be for
a disk cache, I'm not well versed in such things.  In a disk cache the
overhead for a miss is only a little greater than a non-caching card
but subsequent reads are a big win.  CompuAdd keeps "sets" of sectors
and dumps least recently used stuff first.  It also reads ahead betting
that if you wanted sector 2, you'll probably want sector 3 next.  Couple
that with the buffers that the kernel keeps and I'm not sure that there
is a good number for what hit rate is optimal.  From my universal sample
of one :-) the hard cache is the most visible performance improvement
I've seen on this old (1987) system.

>Yet Bill tells us that subjectively the machine seems faster.  Is
>this a special case?  Is the 90% number only effective with the much
>smaller differential in access speed between cache and core?  Does
>the larger spread between core and disk mean that a lower hit rate is
>effective?

Again, I'll speculate that the 90% number is for a main memory cache.
When you add up the wait states to dump to slow memory and reload from
slow memory it would appear that you're lots better off staying in
the cache.  I'm dubious that there is a "right number" (my quotes, not
Rick's) for a disk controller cache because of the varieties of
caching techniques (the DPT is visibly faster than the CompuAdd) and
configuration of kernel buffers.  I think my NBUFS is either 1024 or
2048, but you get my point.  My sar says I'm getting 90%+ hit rate
on the kernel buffers; that would actually aggravate the LRU scheme in
the disk controller.  Example: ps -ef is really fast when the system
is busy and very slow when it's near idle for a long time.

>And Bill, have you found out who *really* makes that card?  If
>CompuAdd can sell them for $500, somebody ought to have them for
>$300... :-)

No I haven't, nor have I found anyone on CompuAdd's payroll who really
understands how it works.  Their panacea is to suggest the most recent
firmware and BIOS EPROM's and in my case that was a retrograde performance
change.  You're also on thin ice with that board with ISC, it's not on
the known-to-work list.  I've got two of them and am not inclined to
change, I got what I wanted.  Another neighbor had to send his back when
it simply would *not* work with a CDC Wren >600Mb.  CompuAdd sells the
same drive that wouldn't work for him, new or old firmware/BIOS, didn't
matter.  The WD1007-SE2 works just dandy, so caveat emptor.
>
>Rick Farris   RF Engineering  POB M  Del Mar, CA  92014   voice (619) 259-6793
>rfarris at serene.uu.net      ...!uunet!serene!rfarris       serene.UUCP 259-7757

Sorry for the length, I don't know what the "right number" is and I doubt
there is one.  People I know who have tried both say that the DPT is a much
better performer, but I couldn't justify the additional $500; my throughput
suits me just fine.
-- 
Bill Kennedy  usenet      {texbell,att,cs.utexas.edu,sun!daver}!ssbn!bill
              internet    bill at ssbn.WLK.COM   or attmail!ssbn!bill