Tuning SYSVR3 (Esix Rev D) (LONG!)

[Bill Vermillion]

In article <1990Dec4.031037.2718 at jwt.UUCP-> john at jwt.UUCP (John Temples) writes:
->In article <1990Dec02.001311.16727 at virtech.uucp> cpcahil at virtech.UUCP (Conor P. Cahill) writes:
->>Even if you set this variable to some high value, it is still possible 
->>that at that new time period following a large disk update, the system 
->>will slow down momentarily due to many dirty pages that still need to 
->>be written out, so you may be in a no-win situation.
 
->Is a cached hard disk controller a win in this situation?  If you
->flush a bunch of stuff to disk (but not so much as to overflow the
->controller's cache), does the system's response still feel "snappy"?
->What happens when you give the controller a read request while it's
->flushing its cache to the disk -- does the read take priority?  Or
->must you wait till the controller finishes?  The only gripe I have
->about 386 UNIX is that when you have two or more processes contending
->for the disk, the system comes to a near halt.  Will a cached
->controller help or eliminate this problem?

I can't tell you what takes priority in a caching controller, but I will
tell you this, it more than makes a system feel snappy.  "Sudden" is
perhaps a more apt description.  That applies systems with the only cache
controller I am familiar with, the DPT units from Distributed Processing
Technology.  They aren't cheap but they are fast.

I have a client with a 20MHz '386 with the DPT with 4 Megs of ram, a 330
meg esdi drive (10Mb/sec) and it definately feels a lot fast than my system
with no cache, a 25MHz '368 with a 15 Mb/sec esdi.

One of the first instances of "sudden" was when I was setting it up and I
exited a WP program.  I thought I accidentally hit break.  Reads through a
data base are very fast.

I haven't done any timings on the actually speeds, but it's fast enough
that I really WANT one myself.

-- 
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
                      : bill at bilver.UUCP