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