Re: Trying NetBSD 9.1 on KA650 and VAXstation 3100m38

[Boris Gjenero <boris.gjenero%gmail.com@localhost>]

The password algorithm is mostly to blame for how slow logins are when a 
password is set. Take a look at 
https://man.netbsd.org/NetBSD-9.1/vax/passwd.conf.5 . In the 9.1 
/etc/passwd.conf, it's set to sha1, and the default is 24680 rounds, 
which is slow. Changing it to old speeds up logins. But of course other 
things are still slow.

At least with MSCP disk access using an RQDX3, DMA is clearly used, and 
amount of CPU time doesn't seem excessive:
> # time dd if=/dev/rra0c of=/dev/null bs=128k count=100 skip=100
> 100+0 records in
> 100+0 records out
> 13107200 bytes transferred in 41.480 secs (315988 bytes/sec)
>        42.80 real         0.71 user         3.24 sys

BTW While doing similar tests with dd, I got this error once, which also 
shows DMA is used. I don't know why the error happened. It seems this 
would have to be a driver bug or hardware error, but certainly not a 
disk error.
> [ 320.9800080] ra1: drive 1 hard error datagram: memory addr 0x4f600: 
host buff)
> [ 320.9800080] ra1: host buffer access error (non-exist. memory) 
(code 9, subco)

Reading from NFS via a DEQNA seems extremely and excessively slow, but 
still not CPU bound according to what time says:
> anoat# time cat /netbsd > /dev/null
>        38.75 real         0.40 user         6.30 sys

Maybe that's responsible for how slow a lot of things are when netbooted?

I also got two of these at other times:
> [ 874.9400080] qe0: xmit logic died, resetting...

On 2020-11-15 6:19 p.m., Johnny Billquist wrote:
> Same here. I don't think you can blame the password algorithm for any of 
> it, though.
> Looking at running system, it spends a crazy amount of time in the 
> kernel. Commonly over 50%, and sometimes up to 80%, and that is even the 
> case with 128M of memory. So with only 8, I would expect it go totally 
> crazy also with paging, in addition to whatever else makes it spend so 
> much time in the kernel.
>
> Disk activity in general seems to cause a lot of kernel time. I don't 
> really understand that it should, but I have not really tried to figure 
> out what is going on...
>
>    Johnny
>
> On 2020-11-15 23:19, Boris Gjenero wrote:
> > My fastest VAXen are my VAXstation 3100 m38 with 8 MB RAM and a KA650 
> > based system in a BA123 with 16 MB RAM. I wanted to see what happens 
> > if I boot the latest NetBSD release, thinking about maybe doing some 
> > work on it and making some contributions.
> >
> > Trying to netboot 9.1 on the VAXstation 3100 m38, I get an immediate 
> > crash when boot from 9.1 starts running, with no output from boot. The 
> > firmware restarts from the beginning with "A42-B  V1.3", all the 
> > tests, and then "?21 CORRPTN". Older 8.x boots cause the same problem. 
> > Boot from NetBSD 7.2 works and can netboot the 9.1 kernel. The GENERIC 
> > kernel reports:
> > total memory = 8072 KB
> > avail memory = 3492 KB
> > That's not terrible for a GENERIC kernel, but I didn't even attempt a 
> > multi-user boot. In single user mode, even "cat /dev/null" is slow.
> >
> > The KA650 CPU is a bit slower, but the 16 MB of RAM should help. Boot 
> > from NetBSD 7.2 seemed to hang after the initial banner, but boot from 
> > 9.1 worked and could netboot NetBSD 9.1. The memory situation is better:
> > total memory = 16328 KB
> > avail memory = 11500 KB
> > I did a multi-user boot, which took over 10 minutes with some stuff 
> > disabled, starting only cron, inetd and syslogd. Memory does not seem 
> > to be a huge problem here, and the KA650 is faster in multi-user than 
> > the VS3100m38 in single user. I could even initiate outgoing ssh 
> > without it being ridiculously slow. Surprisingly, changing a password 
> > or logging in locally with a password was slow, probably because the 
> > hashing algorithm has been upgraded to better resist password cracking.
> >
> > So, you could say the KA650 system is usable, but it's so slow that 
> > it's not fun to use anymore. I don't suppose compiling a stripped down 
> > custom kernel could help much here. That would probably only free up 
> > some memory, and other factors are also making NetBSD 9.1 slow on this 
> > old hardware.
> >
> > In the past, I was using NetBSD 1.3_BETA, which seems much faster. 
> > That's where I got QDSS working in March 1998. I was quite excited 
> > about it: https://mail-index.netbsd.org/port-vax/1998/03/01/0011.html 
> > . I don't think I would similarly enjoy doing stuff with a much slower 
> > 9.1. It seems my VAXen are only useful for running historical 
> > operating systems now. I'm a little bit sad but not complaining. With 
> > these results NetBSD has done better than some other operating systems.
> >
> > Boris