On Sat, 6 Nov 1999, NetBSD Bob wrote:

> Anyone have any feeling as to what is the best approach to increase
> throughput on a little MicroVAX 3100/20?  I want to try to make it
> as fast as possible, by whatever means works reasonably well, and
> try to understand what it is that is making things better.

To alrge extent, any fine tuning is going to depend on what task you're
looking to optimize. Lets assume this is compiling C code under NetBSD.
Seperating filesystems, and spreading them across multiple disks is a good
step, but you want to be sure you've done this intelligently.  Not only do
you want to spread I/O across the disks, you'll also want to do this
across the two SCSI busses you have.  Make full use of the available I/O
bandwidth such that bottlenecking in minimized.

Depending on how much RAM you have available, you can really be very
clever in gaining performance improvements.  If you find your machine
actively swapping during compiles, you'll want to move your swap area to a
seperate disk on which there's not a whole lot of other disk activity.
In a case where you're swapping a lot, I'd even say put the swap on
seperate disk, your fastest disk in fact, and put that on a seperate bus
from where most of the file I/O activity is occuring.  You may also want
to put your /tmp on a seperate disk from your C source files because GCC
uses /tmp to hold all of the intermediate and assembly language files
during the compile process.

In the case of Chuck who's got 64Megs of RAM, he's unlikely to hit swap at
all unless he's running a lot of concurrent processes.  And if he's not
swapping, then all that free RAM is going to waste :-) I'd suggest he set
aside like 20-24Megs of his memory as an MFS (Memory file system), mount
this on /tmp and then all of those intermediate compiler files will be
written and read at blinding speeds.

Also, the NetBSD distribution and the pkgsrc stuff allow you specify a
compile destination directory.  You can use this to your advantage by
keeping the source data and compiled output in seperate locations, across
two drives possibly on seperate busses.  (Being sensitive to the placement
and activity of your swap space though).

And don't forget your ethernet bus either.  It offers a whole other pool
of bandwidth for your use.  If your ethernet segment is mostly idle, you
can do things like set your source files on an NFS server, direct your
compiled output to some disk on one of your busses, putting your swap on a
fast disk on the second SCSI bus.  And if you've got 64Megs of RAM, set
aside a 20Meg MFS for the intermediate GCC files on /tmp.

-brian.
--- Brian Chase | bdc@world.std.com | http://world.std.com/~bdc/ -----
         "Never program a computer you can lift." -- Barry Shein