On Thu, 26 Oct 2000, NetBSD Bob wrote:

> > 	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.
>
	You should be able to pull down the -rnetbsd-1-4 tree using
	anoncvs, alternatively, grab a copy of the -release source
	tarballs on ftp.netbsd.org.

> Permission on the 1.4.3 tree not permitted.....(:+}}.... pointer me
> towards the extant 1.4.3 suite?
>
	Its not quite released yet - its still being built on some
	architectures. You might want to start with 1.4.2 :)

> > 	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.
>
	That is where ttcp (test ttcp bandwidth between two machines)
	and bonnie (disk bandwidth) come in useful.

> 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.
>
	Try GENERIC, then try a minimal cutdown kernel with the same
	set of devices etc.

> > 	ttcp and bonnie from pkgsrc may prove useful.
>
> I will look them up.
>
> Any other things I should tabulate?
>
	pkgsrc/benchmarks/lmbench will probalby give you more numbers
	than you can usefully deal with :)

> > > 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.

	Ben Harris (bjh21@netbsd.org) has been working on shrinking down
	the kernel for 4MB arm26 machines (You think you have issues,
	try a RISC CPU with 32K pagesize if you want to feel how small
	4MB can really be :), and one result is 'options NFS_V2_ONLY'
	which excludes NFS3 support, with consummate code savings.

	Another win (from Jason Thorpe) working on something else
	altogether, is 'options VNODE_OP_NOINLINE', which avoids inlining
	vnode calls, again saving some space, and on some systems is
	faster.

	Both of these are in -current.

	It would be interesting to see if 'options VNODE_OP_NOINLINE'
	is actually faster on the VAX (as well as smaller) - maybe someone
	running -current could run some benchmarks?

	If you want to start saving code space a good place to start would
	be compile your kernel, then run 'size *.o | sort +4 |more' in
	the kernel directory. The .c files matching the .o files at the
	top are good candidates :)


                David/absolute
			       -- www.netbsd.org: A pmap for every occasion --