For the sake of discussion.....

I am a great lover of NetBSD VAX, and have been for several
years, especially on old machines.  I run 4 qbus boxes, and
around a dozen other VAXen ranging from MVII's and VS2000
boxes on the slow end to the moderately zippy 4000/60's on
the other end.  Alas, I am woefully short on 4000/705A class
and up machines (someday.....(:+}}...), and short on the big
ancient iron like 11/750's and up (someday an 11/750, someday,
someday.....(:+}}...).  But, I am running into problems on the
older machines that make NetBSD VAX less and less fun,
from any sort of practical sense.  About a year or two back,
I posted some observations comparing 4.3BSD Tahoe (the
Quasijarus 0a suite), NetBSD's 1.0A, 1.1, 1.2, 1.3, 1.4.1,
and 1.5, and 1.5.1beta) with the general conclusion that
1.4.x was about as good as it got on the old hardware
(typically anything 1 vup and under).  I was chided a bit,
in a cheerful and for discussion sort of way, that I should
get modern and it would get better.  Well, after further
testing, over the past couple of months on 1.6, and the
currents, up through 1.6P,  which is as late as my bits
go, I have to stick by my guns, and suggest that on the
old machines, anything after 1.4.x is a great leap backward.
I don't say that in a derogatory way, but in a manner that
hopefully will let others consider the problems, and maybe
make some adjustments in where things are going in the
great ol' NetBSD VAXland.  In my opinion, NetBSD-1.4.x
(1.4.3 or thereabouts) is as good as it gets on the old slow
hardware.  Anything 1.5 and later is definitely slowing down,
even the currents.  Anything later is definitely bloating, even
the currents (on kernels and general compiles).  I wish it
were not so, but everything I try to do indicates that it is
becoming a problem.

The test machine I am using is a KA650 (MVIII) machine with
24mb of ram, and a scsi mscp controller with 1g drives (up to
7 with various OS levels on each).  I tried KA630 (MVII) board
sets in the box, but things got so bad in terms of usable speed,
as to be laughable.  What do I mean by usable speed... well,
10 minutes to boot a current on a 1 vup machine is laughable.
Kernel compiles of 12 hours and more on it are laughable.
Such speed makes the machines approach a limit of unusablility
except for the diehard Luddite type that really wants to do it on
such a slow machine.  A whole system build is approaching a
forever time limit on such a machine.  I shudder to think what
it would take on an 11/750 (Ragge?  How long on yours for a
boot/kernel-compile/system-build?  (:+}}...).

The point is, for the sake of discussion, that we need to try to
do something to speed the older machines along, or it just ain't
much fun anymore.  My approach for now is to keep a 4000/60
build box around for doing kernel compiles and builds of things
and then just ftp bits into the 1 vup boxes.  That is fine for me
and others, but may not be very fine for the poor fellow stuck
on the KA630 class machine as the only machine.

Is there a solution to the problem, .... dunno, probably not, but,
maybe there are some tweaks that the big guns could do to
help move the slow boxes along.

As reference points, on my machine (the MVIII box described,
above), I ran some rather simple tests to see what kinds of speed
and throughput the old box had on my 1.4.3 suite compared to
the latest current build (1.6P is the latest I can find that has 
actually built).  The following table describes what I did, and what
I observed.....

FEATURE                  NBSD-1.4.3                        NBSD-1.6P

1. Boot time                54 s                                  195 s

2. Stripped MV23
    kernel size              468823                              690504

3. Stripped MV23
    kernel build time      3.8 h                                 6.5 h

4. File i/o time 16mb    68 s                                  139 s
                                  240941 b/s                         117777 
b/s

5. File i/o time ftp time out to a 266mhz alpha server (16mb)

                                  59 s                                  63 s
                                  275 k/s                              255 k/s

6. File i/o time ftp time in from a 266mhz alpha server (16mb)

                                  45 s                                  72 s
                                  357 k/s                             256 k/s

7. Program compile on 1833 line 51K a2ps program

                                  39 s                                  58 s
                                  68581 b                             91867 b


Discussion:

1.  Boot time....  the rc.d fiasco is absolutely a laugh
on slow machines.  This really slows things down,
if you are kernel testing or testing multiple systems
on the same machine.  At one time, I thought there might
be a fix in the boot scripting process, but it does not seem
to help much, unless there are other ways around it.
On fast boxes, i.e., 5 vup and up, it is not yet a problem.
On slow boxes, it is becoming a problem.

2.  Stripped kernel size.... I use a very stripped down config
file with almost nothing in it, for comparisons, so I can run the
thing on anything from Tahoe on up.  The Tahoe kernel is about
170K in size, while the 1.4.3 kernel is 468K in size, compared
to the 1.6P kernel of  690K.  To me, that looks like bloat, and
not all that much featuritis.  The stripped kernel has only the
MVII, MVIII cpus, one controller,FFS, DHV-11, loop and ptys.
It is the bare minimum necessary to run.  Something has grown
there....

3. Kernel build time...  I can't attribute that kind of doubling in
time to anything but compiler huffing and puffing.  The overall
efficiency has taken a dive into the ash can.  The Tahoe kernel
compiles, using pcc, in 15 minutes!  gcc needs more than a
2500% increase in time.  That is getting to be limiting, to say
the least.

4.  Disk file i/o time on a 16mb file..... Clearly current is slowing
way down with a 200% increase in time to write the file with dd.
It was merely a /dev/zero of count=32000.

5.  Ftp file upload to a fast server with a 16mb file.....  Here, the
upload speeds are about the same, indicating that the relative
output efficiency on the qbus ethernet cards is about at the
limit of where it might go.  It is about 4x faster than Ultrix, tho,
which is a good sign.

6. Ftp file download from a fast server with a 16mb file..... Here,
anything later than 1.5.3 up through current has problems on
the qbus ethernet cards.  I don't know exactly what it is, but,
it has significant packet resends and wastes a lot of time
with that, compared to the 1.4.3.  I sense it is probably some
timing or buffering issues, but am not enough of a code jock
to do anything with it.  The alpha end reports frames too long,
up to several hundred per 16mb file.  Anything from 1.5.3 and
on seems to have this problem, to some extent, with more of
them the later the build (e.g., 1.6L was totally useless with
constant packet problems, yet 1.6 and 1.6P mostly work with
only a few problems).

7.  Program compile times and sizes..... This was a test of the
compiler on a small, not to intense program that converts ascii
to postscript.  The later compilers take longer to compile the
static version of the program, and have much larger sizes.
Some of that may be due to disk i/o speed, and some of that
may be due to compiler bloat and inefficiency.  That is not that
much of a reference point, but in compiling large suites of code,
e.g., TeX and friends, it takes a toll on small and slow machines.

Anyway, I don't have much in the way of solutions to these
problems, but, I am beginning to hesitate to use anything
after 1.4.3 (or my version of code just a bit after 1.4.3 but
before the rc.d cruft crept in) on these slow 1 vup and under
machines.  IFF this kind of thing continues, the 1 vup and
under machines just won't be able to practically handle
NetBSD anymore.  That is not necessarily good, nor bad,
but just the way things seem to be going.

Any insights or suggestions to improve the efficiency on
these older machines, is kindly appreciated.

Thanks,

Bob Keys