Re: MicroVAX 3100/20 is apocalyptically slow even with 32MB of RAM

On Mon, 27 Apr 2026 at 18:30, Daniel Seagraves <[email protected]> w=
rote:
>
> > On Apr 21, 2026, at 3:51 AM, David Brownlee <[email protected]> wrote:
> >
> > One aspect which has changed massively has been gcc, and in particular
> > the memory typically used to build anything. Something which would
> > have (relatively) zipped through on earlier versions of gcc on vax now
> > page a system to death.
>
> It=E2=80=99s not just GCC has that was having issues though, even just lo=
gging in and running normal commands was slow.
>
> > If you run "vmstat 5" during the build does it show any significant
> > numbers in the "po" column?
>
> I=E2=80=99ll let you know when I get back there, but...
>
> > It would be interesting to see benchmarks to see how the performance
> > has changed (if you have a spare disk onto which you could install
> > NetBSD-4 or 5), though you would probably also want to benchmark
> > something which does not use gcc - maybe a complex awk script
> > processing a reasonably sized file?
>
> While looking through past notes to see if there was anything of use ther=
e I ran across the output of Unixbench 4.1 being run on this machine back w=
hen it was running Ultrix, so I=E2=80=99ve spent the last few days going ba=
ck to the first version I had installed on here (which turned out to be 1.3=
) and working my way forward, benchmarking the versions I could get to actu=
ally install. I think I=E2=80=99ve isolated the issue to disk IO in general=
, starting with some version after 4.0.1 but at or before 9.1. On 9.1, if I=
 just run a dd from SCSI disk (physical spinning rust, not SSD or emulated)=
 to /dev/null I start spending ~50% of processor time in system and the clo=
ck starts losing time at a rate of several seconds per hour. I haven=E2=80=
=99t yet checked to see if going through the filesystem layer makes it wors=
e. It smells like it=E2=80=99s spending a bunch of time at a high interrupt=
 priority level or with interrupts turned off. I need to do some more pokin=
g around to see if I can get more specific information.

"Interesting"... Its possible that there was a refactor sometime
between NetBSD 4 and 9 that moved NetBSD/vax to some MI driver which
does not play well with the something.

Are you setup to netboot the system? It might be interesting to
compare the performance with the disk controller eliminated from the
path...

David