Re: Performance degradation over time on VAX...

[Ken Wellsch <kcwellsch%outlook.com@localhost>]

A little late, but I took the challenge and I did some tests that I hope follow what you have done.

Here are the results, FWIW...

My simh 3.12-5 boot config I used with the ISOs.  All testing done using the same host system.

-----------------------------------------------------

set cpu 128m

set cpu SIMHALT
set cpu idle=NETBSD

attach nvr ./nvram.bin

set rq0 RAUSER=1024
att rq0 RA1G.0.dsk

set rq1 disabled

set rq2 cdrom
att rq2 /home/sim312/vax/iso/LEGACY/{vaxcd-*.iso or NetBSD-*.iso}

set rq3 disabled

set xq disabled

set dz lines=4
set dz 7b
attach -am dz 1144

set  tq disabled
set lpt disabled
set  rl disabled
set  ts disabled

boot cpu

-----------------------------------------------------
Run on each release ISO selecting a shell after booting

dd if=/dev/rra0c of=/dev/null bs=1024

-----------------------------------------------------

2.0.0.txt:1024458752 bytes transferred in 92.210 secs (11110061 bytes/sec)
2.0.2.txt:1024458752 bytes transferred in 92.630 secs (11059686 bytes/sec)
2.1.0.txt:1024458752 bytes transferred in 93.000 secs (11015685 bytes/sec)
3.1.1.txt:1024458752 bytes transferred in 97.490 secs (10508347 bytes/sec)
4.0.0.txt:1024458752 bytes transferred in 114.550 secs (8943332 bytes/sec)
4.0.1.txt:1024458752 bytes transferred in 114.230 secs (8968386 bytes/sec)
5.0.0.txt:1024458752 bytes transferred in 157.420 secs (6507805 bytes/sec)
5.0.2.txt:1024458752 bytes transferred in 160.880 secs (6367844 bytes/sec)
5.1.2.txt:1024458752 bytes transferred in 162.350 secs (6310186 bytes/sec)
5.1.5.txt:1024458752 bytes transferred in 161.820 secs (6330853 bytes/sec)
5.2.3.txt:1024458752 bytes transferred in 158.070 secs (6481044 bytes/sec)
6.0.6.txt:1024458752 bytes transferred in 179.890 secs (5694917 bytes/sec)
6.1.2.txt:1024458752 bytes transferred in 176.960 secs (5789210 bytes/sec)
6.1.3.txt:1024458752 bytes transferred in 178.940 secs (5725152 bytes/sec)
7.0.0.txt:1024458752 bytes transferred in 197.520 secs (5186607 bytes/sec)
7.1.2.txt:1024458752 bytes transferred in 197.030 secs (5199506 bytes/sec)
7.2.0.txt:1024458752 bytes transferred in 197.720 secs (5181361 bytes/sec)
8.0.0.txt:1024458752 bytes transferred in 204.430 secs (5011293 bytes/sec)
8.1.0.txt:1024458752 bytes transferred in 204.420 secs (5011538 bytes/sec)
8.2.0.txt:1024458752 bytes transferred in 211.010 secs (4855024 bytes/sec)
9.0.0.txt:1024458752 bytes transferred in 199.950 secs (5123574 bytes/sec)
9.1.0.txt:1024458752 bytes transferred in 201.240 secs (5090731 bytes/sec)
9.2.0.txt:1024458752 bytes transferred in 204.750 secs (5003461 bytes/sec)
9.3.0.txt:1024458752 bytes transferred in 201.380 secs (5087192 bytes/sec)
10.0..txt:1024458752 bytes transferred in 224.340 secs (4566545 bytes/sec)
10.1..txt:1024458752 bytes transferred in 223.530 secs (4583092 bytes/sec)
11rc5.txt:1024458752 bytes transferred in 226.920 secs (4514625 bytes/sec)

-----------------------------------------------------
Run on already installed images that had rebuilt themselves from source

dd if=/dev/rra0c of=/dev/null bs=1024 count=1000448

-----------------------------------------------------

1.2.1.txt:1024458752 bytes transferred in 64 secs (16007168 bytes/sec)
1.3.3.txt:1024458752 bytes transferred in 64 secs (16007168 bytes/sec)
1.4.3.txt:1024458752 bytes transferred in 63 secs (16261250 bytes/sec)
1.5.3.txt:1024458752 bytes transferred in 113 secs (9066006 bytes/sec)
1.6.2.txt:1024458752 bytes transferred in 125.800 secs (8143551 bytes/sec)


________________________________________
From: port-vax-owner%NetBSD.org@localhost <port-vax-owner%NetBSD.org@localhost> on behalf of Johnny Billquist <bqt%softjar.se@localhost>
Sent: Wednesday, April 29, 2026 10:42 AM
To: port-vax%netbsd.org@localhost
Subject: Performance degradation over time on VAX...

Had a bit of discussions about NetBSD on VAXen (on discord of all
places), and the perceived performance degradation over time. After a
bunch of poking I finally caved in and did some simple tests that show
that something at least seems not entirely right.

The setup and test done is as follows. Running on simh (a couple of
years old, but I can't see this really being relevant here).

Fetched iso images of several versions of NetBSD. Just the installation
iso, booted it, mounted a file system where I had a 1G file. Ran

dd if=x.y of=/dev/null bs=1024

and recorded the time for the execution.

To be more clear - this is just booting the installation, and quitting
from the installation system. So it's really single user, with the
install system memory file system. And every time with the exact same
simh setup on the same machine with the same load.

The emulated machine is a VAX 8650. 32MB of memory, with 4 MSCP disks.
Nothing else (well, there was ethernet configured in simh, but this is
never started or anything in NetBSD as I never went beyond just getting
a shell prompt).
One mount and one dd. The install iso is attached as rq0 (in simh) which
is ra0 in NetBSD. I had a second disk on ra1, which I just mounted under
/mnt, and that file system wasn't otherwise in any way interacted with,
apart from the reading of the file x.y

The time for doing this dd under different versions of NetBSD then:

2.1: 181s
4.0.1: 190s
5.0: 259s
6.0: 301s
7.0: 415s
10.99: 467s

10.99 was not done with the installation CD, I should mention. That's my
"current" system, but I just booted it to single user, and did the same
mount and dd.

Noticeable is that time only slightly increased from 2.1 to 4.0.1, but
after that it's constantly been getting worse. Current compared to 2.1
is between 2 and 3 times slower.

And this for a simple dd on a system not doing anything else. There is
no good reason why disk I/O would have slowed down this much in newer
versions that I can think of.

I think this shows a very limited picture of the performance, though. I
think that in a properly set up system, the impact is much worse, but in
this test, nothing else needed any CPU, so we can't tell if any aspects
beyond I/O was also hurting in this simple test.

Anyway - this is perhaps food for thought for someone who is interested
in digging into it more. If I have plenty of time, I might dig more, but
I'm sortof busy with other things as well. :)

   Johnny