Caching disk controllers and 386 multiprocessor

[Steve Nuchia]

There are exceptions to the general rule that more main memory for
the unix block cache beats caching controllers and ram disks.  The
exceptions arrise when there is something wrong with your computer
system that, for one reason or another, you can't fix while you
*can* add the special-purpose device.

Examples:
	limited memory address space: Petes are the classic example,
	limited to 4mb by the Qbus so a couple of extra Mb on
	the disk controller or a bank-switched ram disk can really help.
	Also applies to 286s.

	Depending on how the system is balanced, it may make sense
	to use slow, cheap ram on the disk controller or for a
	ram disk when you can't afford fast, expensive, main memory.

	You've got a binary distribution of "The Unix (tm) Operating
	System" with the slow(tm) file system.  Large sparse cache
	in the disk controller may help, particularly when an
	rm -r starts the disk arm in its washer-walk mode.

	You've got a binary-only driver that is too slow to run
	at a reasonable interleave.  A controller that caches
	a track (or a cylinder) at a crack and feeds it to you
	as fast as you can digest it (spoofing the interface
	your driver expects) wins.

	The "general rule" applies to the mythical "typical job mix."
	There are applications in which a well-implemented ram disk
	is just the thing.

None of these situations *should* happen, but they do.  I'm suffering
from 2, 3, and 4 for instance.
-- 
Steve Nuchia	      South Coast Computing Services
uunet!nuchat!steve    POB 890952  Houston, Texas  77289
(713) 964 2462	      Consultation & Systems, Support for PD Software.