Re: booting NetBSD/vax on real hardware

[David Brownlee <abs%netbsd.org@localhost>]

So if the speed change was between 4.x and 5.x.

From a quick eyeball scan of the differences in sys/arch/vax/boot
- RELOC=0x2f0000 -> 0x3f0000
- Setting nexaddr = bootrpb.adpphy if the latter is 0x20087800 in devopen.c
- caddr -> (char *)
- bcopy -> memcpy
- some small shuffling in start.S
- some licence updates

Of course the change could be outside there - libz and/or libsa spring
to mind. I wonder if the default compiler changes between 4 & 5.

It could even be a code change for which the new code is cache sensitive...

A brute force way to try to track this down would be to checkout and
build the bootblocks on a version midway between netbsd-4 and netbsd-5
and then bisect until the offending change is isolated...



On 26 May 2014 08:07, Anders Magnusson <ragge%ludd.ltu.se@localhost> wrote:
> Dave McGuire skrev 2014-05-26 01:06:
>
>> On 05/25/2014 06:06 PM, Charles Dickman wrote:
>>>
>>> After listen to Holm's travails trying to get NetBSD running on his
>>> vax stations I did a little experimenting.
>>>
>>> test vax: VAXstation 4000 Model 60 with 104MB RAM
>>> boot server: Pentium Celeron PC running NetBSD 6.1.3, 100baseTX ethernet
>>>
>>> booting NetBSD-6.1.4 uncompressed kernel (netbsd) from local root disk:
>>> 25s
>>> booting NetBSD-6.1.4 compressed kernel (netbsd.gz) from local root disk:
>>> 17m 30s
>>>
>>> $ time gzip -d netbsd.gz
>>>        11.65 real 6.83 user 1.49 sys
>>>
>>> netbooting NetBSD-6.1.4 Install System compressed
>>>
>>> boot.6.1.4: 21m 30s
>>> boot.4.0.1: fails
>>> boot.matt: 2m 3s
>>>
>>> netbooting NetBSD-6.1.4 Install System uncompressed
>>>
>>> boot.6.1.4: 54s
>>> boot.5.1.2: 58s
>>> boot.4.0.1: fails
>>> boot.matt: 60s
>>>
>>> netbooting NetBSD-1.5.3 Install System compressed
>>>
>>> boot.mop.1.5.3: 1m 34s
>>> boot.6.1.4: 3m 23s
>>> boot.5.1.2: 3m 27s
>>> boot.4.0.1: 1m 27s
>>> boot.3.1.1: fails
>>> boot.2.1: fails
>>> boot.matt: fails
>>>
>>> It is interesting how poor the decompression speed is in boot for the
>>> later releases.
>>>
>>> The boot that I have been using for netbooting for the last 5 years or
>>> so is boot.matt which I believe was supplied by Matt Thomas when the
>>> boot included in release was broken. It looks like this was about the
>>> same time that the decompress code in standalone boot transitioned
>>> from lib/libz to net/zlib. It is clearly 10 times faster than in
>>> 6.1.4.
>>>
>>> ftp://ftp.netbsd.org/pub/NetBSD/misc/matt/boot
>>
>>    Is it possible that the caches are not enabled during the
>> decompresssion?  That might be tough due to per-implementation
>> differences, but if there's room in the boot code for that stuff, that'd
>> make a HUGE difference.
>>
> The caches are not enabled during the boot process.  The (somewhat giant)
> slowliness must be depending on something else.
>
> -- Ragge