Subject: Re: timing numbers on 1.5
To: Chuck McManis <cmcmanis@mcmanis.com>
From: NetBSD Bob <nbsdbob@weedcon1.cropsci.ncsu.edu>
List: port-vax
Date: 12/27/2000 17:21:34
> Anyway, booting from a disk on the scsi chain I measured:
> 	Time to get to mounting root	< 1minute
> 	Time to get to secure level change	3:26
> 	Time to get to Updating motd		4:40
> 	Time to get to login: prompt		5:24
> 
> So basically a 5 and a half minute boot sequence. I don't start any local 
> daemons except for inetd and cron (no sendmail, no nfs, no xntp etc)

That is a little faster than what I was getting at 6 minutes or a tad
over.  But, it clearly demonstrates the 1.5 boot speed slowness.
Compare that to say NetBSD-1.2 which boots to login in about a minute
and a half.  I think I was getting a tad over 2 minutes on the current
1.4.3 boot.  I will have to check that when I get the scsi back up
instead of its current esdi suite.

> This has to be mostly fork/exec activity because the 3400 (KA640) isn't 
> that much faster (perhaps 30% faster?)

Well, what can we cut out of the chain, on the MVII class and slower
critters.  Is all that forking/execing really necessary on these
slow machines, especially since most won't really be set up as
high-end machines.  I would expect that whatever would be the simplest
bare-bones rc script would be the best, IMHO.  There ought to be
a way to let the top of the rc.d script suite test for the type of cpu,
and if it is an 11/7xx or KA630 class cpu, jump to the simplest
startup script possible, and let the end-sysadmin set it up more
than that if needed.  That would keep the boot recycling time
lost in forking/execing down to the minimum.  Alternatively,
one could manually have a mini-rc script that one could merely
link or use instead on the MVII class machines.  Sounds like
it is time to fiddle on the scripts some, tonight.....(:+}}..

> For those of you who are interested in configurations DEC never imagined, 
> you can run a MicroVAX II in the BA213 if you use the KA650 cab kit :-)

Well....., I got this here KA640 BA215 box....sitting... hmmm, if I
put the SQ706A scsi board and spare DEQNA into it, and cobble up some
cabling bits.....hmmm, that might work, until DSSI bits are finalized.
Are there any gotchas in using the DEQNA or SQ706A in the MV3300
KA640 class machine in that foot square BA215 minitower?
Now, my curiosity is getting the better of me..... maybe I can do
something with that oddball MV3300/KA640 VAX thingie, after all!
IFF I could adapt that into a spare build box, then that would free
up the main MVII BA123 for the old time 4.3BSD play, and be some
300% faster (0.9 vs 2.7 vups or something like that)..  Thanks for
the tidbits, Chuck.... you may have solved one of my too-few Qbus
machines up and running gotchas.....

(:+}}...

Bob

> --Chuck