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.