: Now for a question I posted in response to a suggestion that I use 16Mb
: (or so) of RAM for I/O buffering. Would that imply manually setting NBUF
: (and related parameters) manually as opposed to allowing SCO to set it at
: boot time?
SCO 3.2v4.2 is delivered with a MAXBUF=600 value as the
default. This means that the boot time NBUF=0 auto configuration
will not grab more than 600KBytes of NBUF disk bufferin.
This is fine for a 4MB ram system and is rediculously small
for todays megabloat servers.
At first, I thought that increasing the value of MAXBUF was the
right way and to let the kernel decide how much it wants. Not
a good idea. NHBUF is suppose to be about 1/4 of NBUF and the
auto configuration doesn't change this. Therefore, set NBUF
to whatever you consider reasonable, set NHBUF to approx 1/4
of this (rounded off to a binary number), and leave MAXBUF alone.
A few things have changed in the last few years. Processors
have increased in speed by factors of 4 to 10, while disk drives
have improved in speed (data transfer rate) by factors of 2-3.
This tends to create a bottleneck in the drive subsystem. I
recently upgraded a 486 server to a Pentium 90 and was cursed
with SLOWER performance. The difference was that the 486 had
16MB of hardware cache on the SCSI adapter, while the Pentium
only had 4MB. After much seat of the pants testing using Unify
DBM as a benchmark, I ended up with 16MB of SCSI adapter cache,
NBUF=12000, NHBUF=4096, and the remaining 48MB of ram was left
to the OS. That's 1/3 of the total memory in disk buffers and
it is FAST! Sar's waiting for i/o (an indication of a disk
bottleneck) went from 80% to 15% with about 80 users pounding
This exercise gave me a chance to test the merits of having all
the disk cache in main ram as NBUF and NHBUF, verses the same
amount on a cacheing controller. My tests were far from rigorous
but my *GUESS* is that with 64MB of total ram, the cacheing
controller (DPT 2122) is about 15% faster because it can be
readin/rightin the data to/from the disk while the processor
is doing other things. A crude form of multitasking but effective.
I also had a chance to test various caching adapters. The
EISA Mylex DAC960E is about 15% faster than the DTC 2122.
However, the Mylex is tended to hang the system with a parity
check when faced with heavy traffic (HP C1533 DAT write to disk)
while the DPT is solid and quite reliable with ECC ram.
There is always the concern about what happens if the power fails.
When the power fails and all the data in BOTH the NBUF and
the hardware cache disappear, you're going to lose your data
and your job. I think nothing of buying $1000 SPS's to insure
integrity. That's cheap insurance. IMHO, there is no way that
you can run todays servers without a monster buffer making
protection manditory. You should also consider error correcting
(ECC) ram on both the main memory and harware cache. A one bit
error can ruin your whole day (and night).
# Jeff Liebermann Box 272 1540 Jackson Ave Ben Lomond CA 95005
# 408.699.0483 digital_pager 73557,2074 cis [don't]