> >What is left to port for in the old VAX line?  I was under the
> >impression that that hardware was mostly cast in stone.  That is
> >a little different than porting things on new hardware architectures.
> 
> The higher end VAXes such as the 6000s, 7000s, 9000s.  Not too easy
> on a hobbyist budget.

Yeah, I an appreciate that, although there is a 7000 box available
that I will be bidding for in January.  If I can pick it up for
peanuts, and find some way to repackage the guts in a standard
relay rack, and run the power supply off of house split phase
110 single phase (i.e., the infamous 220v hack I have seen 
folks use in the past), then maybe.... or else the wife will
throw it and me out to the dogs....(:+{{...

I also have a line on several 4000 7xx boxes from a friend
that says the will go off to the crusher, otherwise.  If those
happen my way rather than the crushers, we will see about
firing them up, too.

.....

> > >       We need to define why 1.5 is slower.
> > >
> > >       So far we have
> > >               - rc.d
> > >               - general code bloat
> >
> >add in:         - slow tcpip (25% or more slower than 1.4.3)
> >                 - no suitable tapebooting system for old machines
> >                 - huge kernels (I dunno if that is a function of
> >                                 gcc or creeping featuritis or both)
> 
> As we get more device and platforms, the kernels get bigger.

But, on a stripped bare-bonz MVII kernel, I find that hard to
accept that it is merely new device hooks.  Remember the old
1.2 MVII stripped kernel was around 380K, compared to a 1.5
stripped kernel more than twice that size.... (I don't remember
the actual since offhand, now, but I think it was around 800K.
Where did 400K of devices come into the picture?  If I strip
the config down to the minimum, it should not be carrying that
much baggage, unless there is some universal bloat throughout
the code (gcc related?).

One of the things I wanted to try to do in getting the 4.3BSD
MVII up and running was compare come identical code on each
machine as to sizes, compile timings, etc., and see if that
might suggest something.  More on that later.....

.....

> >Well, the old VAXes don't have much new hardware to support, so that is
> >not much of an issue?  That was one reason for thinking that a stable
> >divergent or end-of-the-line system might be appropriate for that class
> >hardware, which could be optimally tuned for use only on that class
> >hardware.  But, keeping a well-tuned old-machine-runnable single-code-
> >line tree is better.
> 
> The problem with that line of reasoning is that the changes that make
> a slower machine faster usually make a faster machine as well.

That is true.  If we use the slowest box as the whipping boy, then
the hot-rod boxes will only get zippier.  That is always good.
But, there may be ways to tune the older boxes that we might not
want to carry along in generic code for everymachine.  The rc
fiasco is a simple example.

> If 1.5 is slower booting, why not run kernel profiling and find out where
> it is spending its time?  That way we can see where it's spending its time.
> Is it in the shell?  In the kernel?  where in the kernel?

Let me get another MVII up and reload some 1.5 and I will try to have
at it, monkeywrench in tow...... no guarantees, though.  News at 11.

Bob