Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Trying NetBSD 9.1 on KA650 and VAXstation 3100m38
On 2020-11-16 03:54, Boris Gjenero wrote:
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.
The slowness I observe is absurd, and is clearly not at all related to
any passwords.
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
Of course it uses DMA. There are no alternatives. (There is no polled
I/O on these systems.)
However, that test isn't really exposing/reflecting what I seem to observe.
Doing something like a cvs update, the disk is pretty much 100% busy for
many, many hours, and the whole time, the system is also mainly ticking
up system time. I am not sure that time is accounted into the cvs
process, though.
But about 300K/sec. My PDP-11 pushes that much. The VAX should be able
to do better, I think. But even more interesting is, could the machine
then do something else at the same time, or is it bogged down here?
But try your test again, but this time run "system vmstat" at the same
time, and check how the system as a whole is reporting. You would expect
that it sits mostly idle, but I suspect it don't...
I need to boot my physical machine to do a similar test. I'll get back
with observations...
Johnny
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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Home |
Main Index |
Thread Index |
Old Index