> I see that the general issue of the startup system present in 1.5 has
> once again surfaced.  I'll try to not fan the flames, but I can't help
> but note that I see many already-voiced opinions (what a surprise!).
> What you do "in the privacy of your own vax system" when you merge or
> upgrade your etc installation set when moving to 1.5 is entirely up to
> you, but note that what is "supported" is what's shipped as part of the
> system.  Please realize that several tradeoffs were made between the
> various factors relevant to the design, and IMHO the tradeoffs made were
> all quite reasonable for normal use.

Ahh, but one could make the case, now that things have become burdensome
in startup, at least on old machines, that it may be time to diverge
a special port with tradeoffs in favor of the slow machines.  That
was mostly what my original thoughts were on the issue.  If we have
reached a brick wall for the old machines then it is time to split
out a custom set for them.  If we have not reached that brick well,
yet, then we still need to consider some issues relating to them.

> I don't know enough about the innards of the vax port to comment on what
> might be causing the perceived slowdown of process forking in 1.5
> compared to earlier releases.  Perhaps some others in this discussion
> have something to contribute here?  Of course, if that is indeed what's
> happening, it will hit the vax port even harder in terms of slowness in
> the startup scripts.

0.9vup and under really makes the point of slowness, on anything.
 
> Perhaps someone could at least run a benchmark to measure this
> effect on two otherwise identical systems with two different OS
> releases installed, say 1.4.3 vs. 1.5?

I have just set up such a machine:  MVII, 13mb ram, 4x 1 gig identical
                                    scsi drives, 1.4.3 generic and
                                    1.5 generic loaded on individual
                                    drives with room for 2 more setups
                                    using stripped kernels.

IF someone will send me what is considered to be the most highly stripped
and bare and fastest MVII kernel config, I will run that up on 1.4.3 and
1.5 on the other two disks.  You gurus decide what is needed.  The
config must contain tk50, deqna, radisk and ka630 support, and really
nothing else.

IF someone will tell me what info they need out of what kinds of test
runs, and tell me how to get the machine there (yeah, I know, I am the
dummy on some of these issues), then I will be more than happy to do
the testing.
 
> As already noted, I don't understand why the speed of the boot-up
> process is such a major issue.  I would have guessed that under normal
> usage these sort of machines are not booted several times a day?!?  Of
> course, the more general problem of speed of process forking is rather
> more serious, but also more difficult to tackle.

I do a lot of fiddling with the MVII, such as comparing releases, doing
4.3 builds, and that kind of thing, so reboots for me are quite common.
I do a lot of ftp'ing out of my other VAXen for materials to run up on
the MVII, so tcpip stack efficiency is important.  That is picking at
nits, on an MVII, but that is where the issues arise.  On the M76 box,
who cares.  It is fast enough that those are non-issues.  What happens
on a 0.3 VUP box?  That is even 3 times slower than my MVII.  We don't
have any support for that slow a box, yet, but the 11/750 at .65 VUP
probably shows the effect.

Anyway, I have such a machine ready for testing....

Bob