Re: Performance degradation over time on VAX...

Daniel Seagraves <[email protected]> Tue, 30 Jun 2026 07:27:25 -0500
Newsgroups gmane.os.netbsd.ports.vax
Message-ID <[email protected]>
> On Jun 29, 2026, at 2:08 PM, Ken Wellsch <[email protected]> =
wrote:
>=20
> ... I also wanted to try testing on some real hardware.
>=20
> In this case, a vaxstation 4000/60 and a zuluscsi card.
>=20
> The simH testing I did was MSCP disk path, while this hardware is SCSI =
based.

I was also trying to identify *where* the degradation was, using real =
hardware. In my case, I was NFS-booting the machine and doing a set of =
dd commands followed by an ntpdate command to identify how much wall =
clock time had been lost during the transfer. My expectation was that if =
the kernel was spending time in a kernel-mode loop with timer interrupts =
deferred, the values reported by dd would be skewed low.

My machine is a MicroVAX 3100 model 20 with spinning rust SCSI disks, no =
emulated anything, and it started on the internal coax ethernet but =
switched to twisted pair on an AUI transceiver later because I suspected =
the coax might be influencing things. (It didn=E2=80=99t seem to make a =
difference but I need to run tests again to eliminate it as a variable)

This is incomplete because I need to make some changes to how I am doing =
things, but these are the results I have so far:

By the end, the commands being run are as follows, with an ntpdate =
command before and after. The unusual count was to match the size of one =
of the spinning rust disks I had, I need to make it something smaller =
and more manageable when I redo this.

dd if=3D/dev/zero of=3D/dev/null bs=3D4096 count=3D1128792
dd if=3D/dev/rsd0c of=3D/dev/null bs=3D4096 count=3D1128792
dd if=3D/dev/zero of=3D/dev/rsd0c bs=3D4096 count=3D1128792
dd if=3D/dev/zero of=3D/TEST.FILE bs=3D4096 count=3D1128792
dd if=3D/TEST.FILE of=3D/dev/null bs=3D4096 count=3D1128792
dd if=3D/TEST.FILE of=3D/dev/rsd0c bs=3D4096 count=3D1128792
dd if=3D/dev/rsd0c of=3D/TEST.FILE bs=3D4096 count=3D1128792

Here are some tables. The XFER TIME is as reported by dd, the LOSSAGE is =
the amount reported by ntpdate.
(These may need to be changed to a fixed-pitch font on your end; I =
don=E2=80=99t want to convert this email to =E2=80=9Crich text=E2=80=9D)

NetBSD 5.2_STABLE
DD FROM         TO              XFER TIME       LOSSAGE
/dev/zero       /dev/null       3997.080        -0.081683
/dev/zero       /dev/rsd1c      20421.851       -0.099940
/dev/zero       NFS ROOT        87156.577       -0.811799
NFS ROOT        /dev/null       28420.820       14.376447
NFS ROOT        /dev/rsd1c      41970.670       0.795055
/dev/rsd1c      /dev/null       15204.930       -0.146239
/dev/rsd1c      NFS ROOT        109214.108      -0.972797

NetBSD 6.0
DD FROM         TO              XFER TIME       LOSSAGE
/dev/zero       /dev/null       3173.160        -0.292628
/dev/zero       /dev/rsd0c      20265.390       0.371887
/dev/zero       NFS ROOT        73201.258       -3.938027
NFS ROOT        /dev/null       22489.557       -0.370215
NFS ROOT        /dev/rsd0c      36841.177       20.235107
/dev/rsd0c      /dev/null       12504.615       -0.656605
/dev/rsd0c      NFS ROOT        88519.700       1.369448

NetBSD 6.0.6
DD FROM         TO              XFER TIME       LOSSAGE
/dev/zero       /dev/null       3163.950        -0.368108
/dev/zero       /dev/rsd0c      20277.260       0.186219
/dev/zero       NFS ROOT        74403.268       -3.795467
NFS ROOT        /dev/null       22600.240       -0.731469
NFS ROOT        /dev/rsd0c      36987.640       19.717948
/dev/rsd0c      /dev/null       12503.010       -1.073806
/dev/rsd0c      NFS ROOT        89527.640       2.871099

I plan to run this tests in shorter iterations against more kernel =
versions and report the results as soon as I am able. This should help =
establish clear trends.