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

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

> On Apr 21, 2026, at 3:51 AM, David Brownlee <abs%netbsd.org@localhost> 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’s 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’ll 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’ve 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’ve 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’t yet checked to see if going through the filesystem layer makes it worse. It smells like it’s 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.