Tuning SYSVR3 (Esix Rev D) (LONG!)

[Floyd Ferguson ENG]

>->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.
> 
There was some considerable discussion about this maybe two years ago
with regards to the Motorola UNIX product. Their version used a linear
search to scan for dirty buffers, which worked well until the total
buffer cache exceeded 2 MB, then things would periodically get very
slow. I don't know if this was pre- or post- bdflush.

The other factor that can really slow things down is a controller (or
driver) that does not group writes. For instance, the 3.2.0 SCO
driver for the HP Vectra ESDI controller will read about 700 KB/sec,
but will only write at 70 KB. Needless to say, writing a lot of
dirty buffers out will take a while.

In article <1990Dec4.162751.12224 at bilver.uucp> bill at bilver.UUCP (Bill Vermillion) writes:
>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.  
> .......
>that I really WANT one myself.
>
I would wait until we find out how they work on the new systems
(V.4) that are no longer burdened with the problem of statically
defined buffer cache allocation. Cache memory is cache memory,
regardless of which side of the host bus it resides. The only difference
is the algorithm used to access it.

Floyd Ferguson		uunet!iphase!floydf