Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!xstor!bang!iverson
From: iverson@bang.uucp (Tim Iverson)
Newsgroups: comp.periphs.scsi
Subject: Re: Controller Cache vs. Software Cache
Message-ID: <1991Jun16.023800.4398@bang.uucp>
Date: 16 Jun 91 02:38:00 GMT
References: <30738@hydra.gatech.EDU> <633@zds-ux.UUCP>
Reply-To: iverson@xstor.com
Organization: SH5
Lines: 42

In article <633@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes:
>Logically, software caching must be faster (assuming reasonalble

Not *must be* faster, but certainly *could be*.  Personally, I prefer the
software angle - using a hardware cache is too much like throwing money at
the problem.

>implementations in both cases), in the case of a cache hit because it
>can just hand over the data rather than needing to perform an I/O

No.  Good software cacheing beats hardware cacheing because of inside
information - the OS has a much better idea of what it would like to keep
around than the host adapter ever could.  Unfortunately, few OSes take
advantage of this info.  For PC's (Unix/DOS/Netware), smart software
cacheing is simply not done; at best just simple LRU is used.

Hardware cacheing adapters have two very strong points: they're generally
easier to add than software for the end user, and they offload processing
from the main CPU.  Unless the software cache does a good job (simple LRU
isn't enough), these two points will win every time, but they cost big $$.

>operation.  On the other hand, there is one type of hardware caching
>that does make sense, read-ahead track buffering, but even this can
>be handled to some extent in software, and it's better done in the
>drive itself if your going to do it at all (and some drives do).

The best place to put any cache is on the other side of an expensively
crossed data path.  If you have lots of active devices on your SCSI bus (an
expensive path), then even though the drive's builtin controller performs a
read-ahead, bus contention may make it moot.

>Now, this doesn't mean there aren't other reasons for wanting a cache
>on the controller; for example, so you can implement special multi-drive
>features such as mirroring, arrays, etc.  If the controller designer

A cache might make the designer's job easier in these cases, but it
certainly is not required.

>Gerry Gleason

- Tim Iverson
  iverson@xstor.com -/- uunet!xstor!iverson