Re: Performance degradation over time on VAX...

[Daniel Seagraves <dseagrav%lunar-tokyo.net@localhost>]

> On Jun 29, 2026, at 2:08 PM, Ken Wellsch <kcwellsch%outlook.com@localhost> wrote:
> 
> ... I also wanted to try testing on some real hardware.
> 
> In this case, a vaxstation 4000/60 and a zuluscsi card.
> 
> 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’t 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=/dev/zero of=/dev/null bs=4096 count=1128792
dd if=/dev/rsd0c of=/dev/null bs=4096 count=1128792
dd if=/dev/zero of=/dev/rsd0c bs=4096 count=1128792
dd if=/dev/zero of=/TEST.FILE bs=4096 count=1128792
dd if=/TEST.FILE of=/dev/null bs=4096 count=1128792
dd if=/TEST.FILE of=/dev/rsd0c bs=4096 count=1128792
dd if=/dev/rsd0c of=/TEST.FILE bs=4096 count=1128792

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’t want to convert this email to “rich text”)

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.