Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!ico!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.unix.i386
Subject: Re: ESDI caching disk controllers: Reprise
Summary: transfer time, avoiding latency
Message-ID: <1990May3.221553.19712@ico.isc.com>
Date: 3 May 90 22:15:53 GMT
References: <274@caslon.cs.arizona.edu> <873@sixhub.UUCP> <1424@ssbn.WLK.COM> <263E613E.23840@paris.ics.uci.edu>
Distribution: na
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 20

baxter@ics.uci.edu (Ira Baxter) writes:
> 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.

But the caching controller can slurp up data while the CPU is busy doing
something else.  You go grab one (or a few) sectors from a track, and hand
them over to a process to start munching.  In the meantime, the controller
swallows the rest of the track and has it ready when you go back and ask
for the next chunk of data, where if you waited until the program needed it
until you went to disk, it might already have gone under the heads.

Note that you can't just transfer the track into main memory the way the
controller does, without a serious performance hit:  Bill K was talking
about getting ~ 50% cache hits, so that would mean you'd be bringing in
about 50% more data than you need.  (Remember that hard disk I/O is PIO,
not DMA.)  You can't really "track-cache" data into main memory cheaply.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Lately it occurs to me what a long, strange trip it's been.