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

> On Apr 21, 2026, at 3:51 AM, David Brownlee <[email protected]> wrote:
>=20
> 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 =
logging 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 =
there I ran across the output of Unixbench 4.1 being run on this machine =
back when it was running Ultrix, so I=E2=80=99ve spent the last few days =
going back 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 actually 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 clock 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 worse. 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 poking around to see if I =
can get more specific information.