You should be able to pick up a Mac mini (with PowerPC) for under $20 on eBay. These machines are relatively quiet and small and even if you only have 256mb that is extremely capable on OpenBSD (only BSD I have tested).
I am currently running OpenBSD on a PPC Mac Mini and I don’t recommend it. There are no binary packages (edit: there are binary packages, what’s missing is binary patches for security errata like m-tier) so I need to recompile from source whenever there is a security patch. Given that the box is old, recompilation takes a long time, sometimes hours for large packages and dependencies.
Other than that, I’m happy with OpenBSD. This is not a criticism of the OS but rather a warning for a bad combination of OS + Machine.
There are binary packages. For example here are the 5.9 macppc packages on one mirror: http://mirrors.sonic.net/pub/OpenBSD/5.9/packages/powerpc/ (warning lots of files here, link may load slowly)
Maybe not of the package you want. A lot of people would complain about the lack of Chromium, and I would miss Mono.
Well that’s new for me. Thanks a lot for the link, I even asked in the official lists some months ago and nobody knew about this.
Edit: Do these packages get binary updates for security errata? I expressed myself incorrectly above (now fixed), the problem isn’t the lack of packages but rather lack of binary security updates
From the OpenBSD FAQ:
When serious bugs or security flaws are discovered in third party software, they are fixed in the -stable branch of the ports tree. Note that binary packages for -release and -stable are not updated. In contrast to the base system, the -stable ports tree only gets security backports for the latest release.
Basically, binary packages are not updated, even for i386/amd64.
Yes, though many people get them from m:tier. They don’t provide packages for ppc though, that’s my issue, since my machine is lowend and compilation takes some time. Thanks for the clarification.
Outside of m:tier, the easiest way to get binary package updates is to run -current/snapshots, albeit with the usual caveats of running a non-release version.
Depending on the goal of the testing, you could run your chosen BSD in a virtual machine and limit its CPU speed. That will get you an idea of how the code runs on something vaguely like a modern CPU but arbitrarily slowed down. If the goal is instead to test performance on specific real older machines (which can have quite different CPU architectures, cache layouts, memory latencies, etc.), then that wouldn’t be sufficient, but it wasn’t clear to me from this post if that was a goal or not.
In this case the workload is not really CPU but that’s a really handy tip I hadn’t thought about that as a test case. The reason I’m looking for systems that are slow is because testing with virtual machines showed little difference, VM just churned through the work without issue.
In this case a single vcpu allocated on a host with a 3.10GHz E3-1220 V2, nothing fancy.
The other thing I need to rule out is that the virtual machines are stored on a zpool & the workload is sequential, so is ZFS prefetching things which is why I’m not seeing any difference?
I would’ve suggested a low-end 64-bit SPARC system (something like an Ultra 1/1E - heck, I could probably give you one of them), but as you say, FreeBSD’s support may be going away at some point.
I suppose an old Soekris may be a modern-enough-but-slow-enough x86 system?
Funnily enough, I did have one of the early Soekris boards which I got rid of. With 64MB RAM it’s not possible to boot FreeBSD 11 however.
The slowest system I have here is a ThinkPad 701cs (yes, the butterfly!) with a 75 MHz 486 and 24 MB RAM. Unfortiunately, these systems are picky with the CMOS battery and fail memory tests without a working battery.
I’ve not checked but I believe you may only be able to run NetBSD with that much RAM (without X11)