Subject: Re: Not time to panic yet. [was Re: Any NetBSD installations on VAX
To: Brian Chase <bdc@world.std.com>
From: NetBSD Bob <nbsdbob@weedcon1.cropsci.ncsu.edu>
List: port-vax
Date: 12/28/2000 12:29:23
> On Thu, 28 Dec 2000, NetBSD Bob wrote:
> > IFF, for the sake of discussion, this kind of testing indicated that
> > there really was a hurdle/bloat/crawl/whatever in the code, then, as
> > Isildur suggested, and apparently some others thought might be of
> > merit, perhaps a fork into a cast-in-stone end-of-the-line stable
> > final (or whatever) lean/mean/trimmed-to-the-bone OT-NetBSD-VAX
> > suite ought to be seriously considered.
> >
> > [...]
> 
> I think it's probably a bit too early to write-off 1.5 and future releases
> for running on the older VAXen.  If we do notice some serious performance
> problems on systems like the MicroVAX-II, we need to note what they are,
> track down their source, and figure out possible solutions to them.

OK, I was merely being the first bozo trying to trying to raise some
issues.  Considering that the early slow machines are really not
going to be considered production class machines, these days,
and that most are tending to be hobby/retro/fun related, it did
occur to me that splitting out that level of system so that future
enhancements would not be so burdened by dragging along the slow
boyz, might be OK.

Still, keeping the code in one tree is good, too.

As to problems.  The rc.d is a killer on the slow machines.
I can only speak for MVII boxes, but maybe someone will roll
up an 11/750 for testing 1.5 on and report back.

The slowness in the tcpip stacks is another problem.  The
1.5 takes a big hit in 1.5 compared to 1.4.3, on the same
machine....MVII/DEQNA.  The 1.4.3 easily runs 220k/s, but
the 1.5 can only muster up 150k/s.  That may or may not
be important, but if one relies on ftp installs, for example,
that is significant.

Another problem is that there is no good booting scheme for
the early machines, except for tape, and that does not yet
exist in 1.5.  Netbooting is not always the best way.
Tapebooting is the traditional default on most all of the
early VAXen, from what I gather.  We seem to have lost the
the art of tapebooting in 1.5.  Chuck, I think it was, ran
off a test boot.fs, but that did not work on the MVII tape,
although it worked fine on 3100/M30 when written to a spare
HD and booted from that.  Interestingly, the 1.4.3 boot is
not fully functional there, either.  It boots, but dies with
installation running out of file system space.  Manual un-
rolling of tarballs works, and was how I got my machine up.
So, tapebooting is a problem that needs readdressing.

Those are the only big gotchas I have found, so far, and, since
MVII's are not biggie production boxes, it probably does not
really matter much, but the effects are beginning to show
on the old hardware.  Thus, my concerns needed some outlet.
 
> Given that 1.5 is a fairly significant release, I imagine we're going to
> see some problems.  This is only to be expected, especially considering
> the NetBSD/vax community contains systems which truly stretch the limits
> of the OS, which is a `good thing.' I think it's healthy for NetBSD in
> general to have to deal with crusty old MicroVAX-IIs and VAX 11/750s.

Agreed.  For the sake of discussion, one approach to handling the
1.0vup and under class machines might be to tune up a special
edition of NetBSD strictly for those machines.  That was mostly
what my line of reasoning was.  Then having 1.5 and up being
responsible for the early machines would not be an issue.
Still, if the burden was not too much on the early machines,
I really would prefer one line of code rather than an OldType
system, too, except for our current discussion.  When the practical
utility of keeping together an every-kind-of-every-VAX suite gets
out of hand, then there may be some good reason to split out a
traditional suite.  That is heresy, but, food for thought.
 
> And from what I've seen of the NetBSD community over the past few years,
> it isn't one to turn a blind eye to issues like these.  As long as we're
> diligent about researching and reporting problems, they'll be solved as
> best as they can.

No, I sense there are good issues being discussed, and out of all the
mess will probably come some good solutions.  I merely tossed out
a heretical one, for starters.   (Where DID I last hang me ol'
musty dusty rusty Inet Flak Suit....(:+}}... nah, not needed on
this list.....(:+}}...)

> If there are significant performance problems beyond the current rc.d
> issues, then we need to work to understand them.  Getting NetBSD to run
> well on the VAX platform is the main purpose of this mailing list
> afterall.

Well, it amounts to some overall decision-making.  IFF the old machines
are still in with the big-boyz, then keep it all together and let the
code jocks tune up the system as best they can on the early machines.
IFF the old machines are reaching a practical end of reasonable handling,
then I have no problem splitting out an appropriate VAX suite best suited
to each (e.g old/new) class machine.  There may be good reasons for
going with either approach.  But, we need to get something rolling.

The problems I mentioned above are all I have found so far.
But, it is good to do some comparisons, and that is why, over the
past several weeks I have been wrangling up everything from 4.3BSD
through 1.5 on the ol' MVII critter, so I could get some feeling
for the trend in conditions on it.  The 4.3BSD is quite nice, and
feels a bit like 1.0A nd 1.2, compared to the later NetBSD's, but
its tcpip stacks run only at 120k/s which is way too slow.
Interestingly, the tapebooting system is MUCH faster than the
NetBSD early edlabel/copy/boot system, or the later 1.4.x style
installation, but it is more cryptic.  Maybe there is something
that is saying about how our current netbooting situation is
going?

Anyway, it is not time to panic, but it is good time to discuss
issues relating to the old machines, and then seek good working
solutions.

Thanks

Bob