Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!texbell!ssbn!bill
From: bill@ssbn.WLK.COM (Bill Kennedy)
Newsgroups: comp.unix.i386
Subject: Re: ESDI caching disk controllers: Reprise
Keywords: ESDI cache
Message-ID: <1440@ssbn.WLK.COM>
Date: 2 May 90 12:35:40 GMT
References: <274@caslon.cs.arizona.edu> <873@sixhub.UUCP> <1424@ssbn.WLK.COM> <1736@serene.UUCP> <263E613E.23840@paris.ics.uci.edu>
Reply-To: bill@ssbn.WLK.COM (Bill Kennedy)
Distribution: na
Organization: W. L. Kennedy Jr. and Associates, Pipe Creek, TX
Lines: 46

In article <263E613E.23840@paris.ics.uci.edu> baxter@ics.uci.edu (Ira Baxter) writes:
>In article <1424@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'm sorry I didn't see this when I followed up the earlier post, I'd have
combined them.

>I have never understood this.  If a caching disk controller with 4Mb gives
>you a high hit rate, why not put the 4Mb of RAM into your CPU, and
>let UNIX use it as a cache?  The hit rate should be the same.

This is certainly true for reads and, depending on NAUTOUP, for writes.  My
system is on a UPS so I set NAUTOUP to two minutes so the buffers are not
flushed so frequently.

>The win is that the OS should be able to divide the RAM between disk
>cache and process space (I assume UNIX isn't brain-dead in this regard?).
>Then you have the best of both worlds.

I don't think it works this way, so put a question mark in if approrpiate.
You specify the size of the kernel cache with the NBUFS tunable parameter,
I don't think that the kernel sizes up or down on the fly.  It probably
does something like that with the process space when it starts swapping,
but I think the disk cache is fixed at wherever you have it set.  In my
case, I had already ascertained the "optimal" number of buffers so I was
going for the time wasted waiting on the spindle/heads to get positioned.

>Or am I missing something?
>--
>Ira Baxter

Yes, Ira, I think you are.  I agree that things get fuzzy with regard to
reading, kernel buffers work at memory speed and the controller cache at
I/O speed.  Writing is a different story though.  The logical write is
disconnected from the physical write.  The kernel dumps off its stuff at
I/O speed without regard to seek time or rotational latency and the
controller worries about the physical write.  The kernel buffers can't
help you a bit if you have to wait on the disk mechanism to get to the
right place, a caching controller can.  The other issue (in my case) was
cost.  SIMM's for the controller are a lot cheaper than column static
main memory.
-- 
Bill Kennedy  usenet      {texbell,att,cs.utexas.edu,sun!daver}!ssbn!bill
              internet    bill@ssbn.WLK.COM   or attmail!ssbn!bill