Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!texsun!texbell!uhnix1!nuchat!steve From: steve@nuchat.UUCP (Steve Nuchia) Newsgroups: comp.unix.xenix Subject: Re: Caching disk controllers and 386 multiprocessor Keywords: multiprocessing, disk controller Message-ID: <10870@nuchat.UUCP> Date: 15 Jun 89 14:26:43 GMT References: <1013@aber-cs.UUCP> Reply-To: steve@nuchat.UUCP (Steve Nuchia) Organization: Houston Public Access Lines: 37 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.