> > For fun I did a load of 1.3.2 on the MVII, and compared things like
> > ethernet rate, boot speed, etc., and the 1.3.2 far outran the 1.5_BETA
> > on the MVII, even with a stripped to the bare bones 1.5 kernel.  Ethernet
> > speeds, for example were 33% faster on the 1.3.2 with generic kernel,
> > compared to the 1.5_BETA with stripped kernel.  That includes disk
> > I/O time.  Boot time on the 1.3.2 was about 30-45 seconds.  Boot time
> > on the 1.5_BETA was approaching FIVE MINUTES.  Yikes!
> >
> 	Out of curiosity, could you try a 1.4.3 (or 1.4.2) as well?

Sure.   Is there a 1.4.3 port available for the VAX?  I don't remember
seeing anything there last time I perused that tree.  I archived all
the different VAX ports I could find onto my M76, so other than the
several hours it takes to manually unroll, twiddle configs, then reboot,
it should be no problem.

Permission on the 1.4.3 tree not permitted.....(:+}}.... pointer me
towards the extant 1.4.3 suite?

> 	Can you test the ethernet vs disk speeds separately?

Not easily.... I was going on the seconds it took to send an 80mb
file from the MVII to the M76 and then reverse, and then seconds
to boot to login prompt.

For fairness, I should probably use the generic kernels for each
revision level and standardize on say a 100mb tarball or such
between the machines.  I could stack it up against an Alpha
3000/300 class machine, where its speed would not have any
potential limiting factors.  The M76 is much faster than the
MVII, so I expect speed on its end is not that much of a bottleneck.

I should probably also do a 100mb file transfer between HD's in the
same system to get some insight into relative disk I/O.

> 	ttcp and bonnie from pkgsrc may prove useful.

I will look them up.

Any other things I should tabulate?

> > Is there anything that can be done to speed along the aging MVII critter
> > with a current NetBSD VAX port?
> >
> 	Work out where the bottleneck is:)

Code bloat.... code bloat.... code bloat.

No flack intended, but I just sent a followup with some kernel sizes.
Ouch!  We have bloated a bit, for sure.  I have a sneaking suspicion
it is gcc based, since I have seen this bloat occurring everywhere
gcc is used, even on my old 4.3BSD IBM RISC box.  Sure, we have added
features, but things have grown more exponentially than proportionally
to the features added.  That suggests compiler inefficiencies.

Dinosaurian MVII class machines (fun, and more than worth the effort
for the one-upsmanship of the things) need all the help they can get.
Anything to speed them along is most helpful.

Bob