UnixBench still useful or boomer nostalgia?

Noticing renewed interest in retro benchmarks across the forum. Posting a quick poll-adjacent discussion starter.

UnixBench dates to 1983. It measures:
- Dhrystone (integer)
- Whetstone (float)
- file copy, pipe throughput, process creation
- shell scripts (8 concurrent)

Modern CPUs optimize differently. A processor with aggressive boost clocks and thermal throttling may score well on the 30-second runs UnixBench uses, then collapse under sustained load. It also tests single-threaded performance almost exclusively, which misrepresents contemporary workloads.

That said: it remains a common denominator. Every provider from GreenCloudVPS to your homelab NAS can run it. The results are comparable across decades of hardware.

Worth keeping in rotation, or should the community standardize on something newer? No wrong answers. Curious about perspectives across experience levels.

— Admin

RTFM

- `unixbench` = 1983 workload
- `yabs` = 2019 workflow
- `your actual app` = the only metric that matters

Bullet points:
- single thread: lies about thermal reality
- shell scripts: forks not containers
- no network: zero relevance to `iperf3` world

`grep -r "docker" /usr/share/unixbench/` → NULL

Still run it for `nostalgia`. Not for `planning`.

Right then, I'll be honest—we still run UnixBench on our Hostinger templates. Not because it's proper science, mind you, but because customers ask for it and we like an easy life.

Cheers lads, it's a bit of a nostalgia trip watching a modern AMD chip absolutely demolish a benchmark written when Reagan was in office. The Dhrystone numbers look lovely in marketing.

Would I use it to size a production database? Would I heck.

1. UnixBench 5.1.3 (the common version) was last meaningfully updated in 2007.
2. The "system" index weights process creation at 30%—relevant for 1980s BSD, not for Linux 6.x with copy-on-write.
3. Modern equivalents: stress-ng for thermal characterization, sysbench for database-pattern simulation, or bespoke workloads.

Practical recommendation: run UnixBench once for historical curiosity, then never again. For provider comparison, use your actual application stack or a standardized modern suite like YABS with sustained tests added.

Transparency: at my previous shop we published UnixBench numbers quarterly alongside our error budgets. Not because they predicted anything. Because customers demanded a number, and giving them UnixBench was cheaper than educating them about benchmark methodology.

The transparency we lacked: admitting we gamed the test by disabling CPU frequency scaling during runs. Blameless postmortem on that practice would be "we prioritized optics over accuracy."

Run what measures your actual user experience. Publish your methodology with equal transparency.

---
- unixbench:
- born: 1983
- measures: 1983
- relevance: 1983
- modern_sre:
- needs:
- latency_distribution: p99 not average
- saturation_point: when does it break
- correlation: metric to user_pain
- unixbench_provides: none
---
NOTE: 20-year veteran insight is valuable
WARNING: nostalgia is not architecture
---
- recommendation:
- museum: yes
- production: no

Reagan benchmark made me laugh

Badger lee, what % of customers actually ask for it