Skip to content

History

Jump to bottom
Mason Rowe edited this page Oct 31, 2026 · 1 revision

History of YABS

In short

YABS began in late September 2019 as a private script Mason Rowe wrote to automate the iperf3 tests he kept running on new servers. Within a week it had grown Geekbench and dd disk tests, landed on GitHub (2 October 2019), and was announced to the LowEndTalk and HostBalls hosting communities on 7 October 2019. The communities' feedback shaped nearly every major decision that followed: the move from dd to fio, the shape of the disk test, the refusal to grade results as "good" or "bad", the static binaries, the yabs.sh one-liner, JSON output, and the result-database ecosystem that grew around it. By 2026 the script was being run roughly 90,000 times a month.

This page tells that story chronologically, with links to the original discussions where possible.

Table of contents

Before YABS: the bench-script landscape

Low-end hosting communities (LowEndTalk, LowEndSpirit, HostBalls, and their predecessors) have always had a ritual: when you get a new VPS or dedicated server, you run a benchmark script and paste the output in the forum thread. For most of the 2010s that script was one of:

  • bench.sh (teddysun) — system info, a dd write test, and single-connection wget downloads from a handful of mirrors.
  • nench.sh (n-st) — ioping and dd disk tests plus wget downloads, with careful attention to shell portability.
  • ServerBench, vpsbench, busytest, and others — variations on the same theme.
  • ServerScope — a web service that ran a richer suite (including fio) and stored results, later defunct.

The weaknesses were well known in the community: dd measures only sequential throughput and is heavily affected by caching, single-connection downloads rarely saturate a 1 Gbps port, and none of them measured CPU performance in a way people could compare across machines. Meanwhile, many community members had settled on their own ad-hoc trio — iperf3 for the network, fio for the disk, Geekbench for the CPU — but running each by hand meant looking up download links every time.

The name is a nod to this crowded field. The original README opened with the xkcd "Standards" comic ("Situation: there are 14 competing standards...") and the line: "This script isn't an attempt to be a golden standard. It's just yet another bench script to add to your arsenal." Years later a LowEndBox article noted the double joke, since "Yet Another" also echoes UNIX's yacc (Yet Another Compiler Compiler).

Week one (September–October 2019)

Mason described the origin plainly in the January 2020 LowEndSpirit thread:

"Yet Another Benchmark Script (YABS) was created a few months back initially as an automated iperf script that I would use myself, then it evolved to include geekbench and dd tests as well. I then decided to tidy it up a bit and add it to GitHub."

The git history shows exactly how fast that evolution happened:

Date (2019) Commit What changed
2 Oct 72e3b48 First script: ~25 lines. Downloads an iperf3 3.1.3 binary (and libiperf.so.0) from iperf.fr into /tmp, runs iperf3 -c bouygues.iperf.fr -P 8 in both directions, prints the [SUM] ... receiver lines. Banner already reads v2019-10-02.
2–3 Oct several Fault-tolerant iperf retries, multiple servers, basic system info, wget replaced by curl.
4 Oct a50d191, 66354ad dd disk tests, disk-size calculation, a "read speed disclaimer" (reads are cache-affected).
5 Oct f2d04cd Geekbench 4 added.
6 Oct d4cc9a2, 9499aac IPv6 iperf tests; -d/-i/-g skip flags; arithmetic moved to awk; CentOS dd fix.
7 Oct 8ed8e68 Correct VT-x/AMD-V detection. Public announcement.

The first version of the "Basic System Information" block already had the layout that survives today: Processor, CPU cores @ MHz, AES-NI, VM-x/AMD-V, RAM, Swap, Disk.

The announcement and the first feedback (7–10 October 2019)

On 7 October 2019 Mason posted the same announcement to LowEndTalk (as MasonR, in General) and to HostBalls (as Mason, 03:56 UTC):

"Over the past few days I started working on a benchmarking script. The goal of the script was to make something slightly different than what's already out there, which incorporates benchmark tests that we find ourselves conducting quite often, namely dd, iperf, and Geekbench."

The run command was the raw GitHub URL (curl -s https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh | bash), and the script had been tested on CentOS 7, Debian 9 and 10, Fedora 30, and Ubuntu 16.04 and 18.04.

The same day Mason set expectations:

"The script in its current state should be viewed as a 'beta test' of sorts. I only started working on it last week after all, so I'm sure there will be a few iterations of it moving forward as more feedback/bug reports come in."

Feedback arrived within hours, and much of it maps directly onto features that exist today:

Day-one feedback Who What it became
dd read speeds are skewed by cache; a 1.3 GB/s "HDD" was posted as proof Mr_Tom, Friendly (HostBalls), eva2000 (LET) The 15-month search for a better disk test (see below)
"Permission denied" running the downloaded binaries vovler, MissFortune Binaries moved from /tmp (often mounted noexec) to the current directory; a write-permission check was added (8 Oct)
IPv6 tests ran on hosts without IPv6 sanvit, emre IPv4/IPv6 detection rewritten (8 Oct)
"Would be awesome if it also shows ping results" sanvit Latency column (added November 2022)
Need more US and APAC iperf servers; Hurricane Electric is always busy qps and others A continuous theme; sponsorship offers began the same week
Decimal commas in European locales broke the parsing emre and others LC_ALL=C override (January 2020)
CentOS 8 ships without tar, so Geekbench fails Mason's own testing A tar check finally landed in October 2026 (#99)
Firewalls blocking iperf's non-standard ports make every location fail alilet FAQ material ever since

Two answers Mason gave that week became founding principles. On why the script downloads binaries instead of requiring installed packages (10 October, LET):

"I decided against local binaries, because I wanted the script to not require any external dependencies to be installed prior to running the script. While not a high barrier of entry, it's obvious that much of bench.sh/nench.sh's success is that you can simply run the one-liner and not have to worry about anything being installed prior. Once you start adding in pre-reqs, more than half of the potential users of the script have already been turned off."

And on why iperf3 rather than a speedtest.net-style test:

"Speedtest is a single threaded connection (which almost never is capable of breaching > 1gbps). While on the other hand, with iperf, you'll have many parallel connections providing a better representation of how your server will handle many high-bandwidth connections simultaneously."

He also clarified the direction semantics that still confuse newcomers: Send Speed is your server to the remote, Recv Speed is the remote to your server.

The disk-test problem: dd, ioping, and the road to fio (October 2019 – February 2020)

The disk test was the sore point from the first hour. Mason's position on 7 October was pragmatic: dd "does a decent job estimating performance" and, crucially, it was the only option that needed no installation and no root. He had already tried fio:

"I did try to get fio working with this, however it'll either require elevated privileges (to install fio) or the user to install prerequisites (building fio from source), both of which I'm trying to avoid for this script." — issue #1, December 2019

The sequence of attempts:

  1. 8 October 2019 — ioping adopted for reads (as nench did), because it seemed "less tainted by cache"; dd kept for writes. A static ioping binary was served from the repo.
  2. Same week — a European user's results showed ioping reads "off the roof"; Mason concluded "I guess ioping is more prone to caching than I had originally thought."
  3. 24 December 2019 — Daniel15 opened issue #1, "Replace dd with fio?", citing BinaryLane's fio guide and ServerScope, and suggested a statically linked fio downloaded by the script.
  4. 8 January 2020 — ioping removed: "Seemed ioping was just as affected by cache as dd, so to keep things simple, I reverted back to just using dd... Both are inferior to fio, but I'm having issues compiling fio statically." The table was renamed "dd Sequential Disk Speed Tests" to be honest about what it measured.
  5. January 2020 — the static-build breakthrough (next sections).
  6. 4 February 2020 — fio replaced dd (commit 2c74b1a). dd survives only as a fallback when fio cannot run.

Designing the fio test in public (January 2020)

The LowEndSpirit thread from January 2020 is effectively the design document for the disk test YABS still runs. The exchange is worth recounting because people regularly ask "why 50/50?", "why no sequential test?", and "why doesn't YABS tell me if my result is good?"

Starting point. Mason planned to use BinaryLane's recommended command (--ioengine=libaio --direct=1 --gtod_reduce=1 --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75) with a 1 GB file and a timeout. His first preview showed a two-column table, Sequential vs Random, for read and write.

Dropping sequential. After discussion with Falzo, poisson and Anthony Smith of InceptionHosting (who asked how "a 1GB or 4GB or 60 second test captures anything you are ever likely to use a VPS for in the real world"), Mason removed the sequential tests entirely:

"I scrapped the sequential speed tests. People might be used to seeing them, but they're essentially useless as they aren't testing real-world conditions, so I guess it's best not to continue the facade that anything of value can be interpreted from these results."

In the same change the file grew from 1 GB to 2 GB and the per-test duration shrank from 60 s to 30 s.

Mixed read/write only, four block sizes. An intermediate design had six tests (read-only, write-only and mixed at 4k and 64k). poisson argued that mixed performance is what you actually experience and suggested covering 4k, 64k, 512k and 1M instead; Falzo said the same privately. Mason: "I think I may be overestimating the importance of including read/write-only tests." The final design, four mixed tests at those four block sizes, appeared in the thread on 20-something January and shipped on 4 February.

Why 50/50. poisson argued for rwmixread=50 because "it is better to read and write the same amounts of data" and because a 75/25 mix produces artificially low write numbers that make people "mistakenly conclude the writing sucks". Daniel15 pushed back that real workloads are usually read-heavy. Mason closed the debate with the line that could be the project's motto:

"We'll probably all have to agree to disagree. The past few comments really showcase something that I've been struggling with — creating a 'one-size-fits-all' test is HARD."

No grades. poisson and cybertech both suggested the script label results (Bad / Mediocre / Good / Excellent / NVMe). Mason declined, and the decision has held for six years:

"I personally don't like the idea of adding in (bad/good/great) indicators of performance from these tests for several reasons. The cutoffs between them can be arbitrary and essentially our opinion of what 'good' means. In addition, what's considered good today might be considered poor 2 months from now as hardware and expectations change."

(WSS's reply — "Please don't." — captured the community mood.) This wiki's Interpreting Results page exists precisely because the script itself refuses to do this.

The header. beagle suggested the table title say (Mixed R/W 50/50) so nobody could mistake the numbers for pure read or write results. It still does.

Static binaries and the "one-liner" principle

The thing that blocked fio for three months was portability. Mason's first static builds ran on some machines and not others:

"Compiled on a 4.15 kernel and it won't work on a 2.6 kernel machine. Compiled on a 2.6 kernel and it won't work on the 4.15 machine... Issues seem to be coming from the libaio and libc6 libraries."

WSS, on LowEndSpirit, gave the advice that unblocked it: build statically on the oldest practical distribution (Debian 7). "Deb 7 did the trick... working on every vps+dedi I've tested so far (even an ancient cociu VM)." Mason then moved the builds into phusion's Holy Build Box, a container environment designed for producing portable Linux binaries, and committed fio_x64, fio_x86, iperf3_x64 and iperf3_x86 to the repository's bin/ directory on 13 January 2020 with a README explaining the trust model in characteristically direct terms:

"Naturally, there is a security risk to your machine and its contents by running this script since, after all, this is just a script on the internet. You'll simply have to have confidence that I don't have malicious intent and am semi-competent at writing a bash script."

Two early bugs refined the recipe: issue #3 (March 2020) found the fio binary used AVX instructions that QEMU's default CPU lacked, so builds switched to --disable-native; issue #11 (September 2020) found fio 3.23 triggered the OOM killer on sub-1 GB CentOS machines, so the binary was temporarily rolled back to 3.17. Later milestones: ARM binaries (June 2021), SHA-256 checksums and VirusTotal links (November 2023), GitHub Actions builds (September 2025), binaries moved out of the repo into GitHub Releases with musl cross-toolchains (September 2026), and RISC-V (October 2026). The full story is on Precompiled Binaries.

A compromise also dates from this period: since v2020-02-10 the script prefers an already-installed fio/iperf3 over the downloaded binary, which both calmed security-minded users and sidestepped incompatibilities; -b (November 2021) forces the repo binaries for anyone who wants identical tooling everywhere.

yabs.sh (February 2020)

On 5 February 2020 CamoYoshi noticed on LowEndSpirit that the yabs.sh domain was available. Mason replied: "I was eyeballing that domain a couple weeks ago. Screw it... let's do it. Just registered it." The next day:

"Domain is set up now with appropriate redirects. curl -sL yabs.sh | bash — How's that for short?"

The implementation (shared in issue #39) is a few lines of nginx: requests whose User-Agent contains curl or Wget are redirected to the raw script on GitHub; everything else goes to the repository page. Mason deliberately kept the script itself only on GitHub "for openness sake and so I don't have to worry about syncing the files." The one-liner became the project's identity and is how almost everyone has run it since.

Growing up: 2020–2021

  • 10 February 2020 — Geekbench 5 became the default (-4 for Geekbench 4), local packages preferred, dd fallback, -r reduced-bandwidth mode (then Online.net FR, WorldStream NL, Hurricane Electric US), and -h as a dry run.
  • June 2020 — Ctrl+C handler that cleans up, refactor allowing arbitrary block-size arrays, -9 to run GB4 and GB5 ("4+5=9"). Mason noted the first 200+ day: "We had 234 script runs yesterday."
  • August–September 2020 — Geekbench license-file support so Pro users could unlock results; iperf location shake-ups as public servers came and went.
  • October–December 2020 — webdock.io's two issues produced lasting features: a free-space check before the disk test (#12) and the ZFS spa_asize_inflation warning (#13), after they showed fio results collapsing by up to 10× on ZFS datasets with too little free space. webdock also opened #9 ("Ability to autobench + upload results?"), the seed of JSON output; Mason's condition was that uploading must be strictly opt-in.
  • February 2021 — the logo, designed by Dian Pratama. Retries per iperf direction dropped from 10 to 5 (and to 3 in June 2022).
  • June 2021 — ARM support (#21), making Oracle's free ARM instances and Raspberry Pis first-class citizens.
  • November 2021 — a warning when the C locale is missing (#24), reorganised binaries, and the -b flag (#27).

JSON, result databases, and network information: 2022–2023

  • February 2022 — the special IPv6-only run command was removed once GitHub's raw CDN supported IPv6.
  • May 2022 — extra system information lines (Uptime, Distro, Kernel) credited to "emperor on LES"; wget accepted everywhere curl was.
  • August 2022 — -j, -w and -s: JSON to screen, file, or POSTed to a URL. This turned YABS from a paste-into-a-forum tool into a data source. VPSBenchmarks and later YABSdb, serverlist.dev, ServerVerify (LowEndBox's database, which passed 10,000 submissions) and VPS Host Review all accept the JSON. The schema became a de-facto public API, which is why changes to it are additive only.
  • November–December 2022 — the ping/latency column (#43, three years after sanvit asked), standardised location naming (#48), and the "YABS completed in X min Y sec" footer (#51).
  • February 2023 — "Network Information" (ISP, ASN, host, location via ip-api) and the "VM Type" line (#56); two days later Geekbench 6 became the default on the day it was released.
  • March–July 2023 — portability work driven by Alpine users (grep -P removed, #59; ping permission errors, #61), reuse of a locally installed Geekbench (#68).

Hardening: 2023–2025

  • November 2023 — SHA-256 sums and VirusTotal links for every binary; a ShellCheck CI workflow (#77); the fio header started naming the tested partition; bc dependency removed (#79).
  • 2024 — CentOS 7 users got a clear explanation of why Geekbench 6 cannot run there (glibc 2.17 vs. required 2.27, #71); Alpine's missing lscpu handled (#84); curl examples moved to HTTPS (#94); a December sweep made the script ShellCheck-clean.
  • 2025 — exFAT counted in disk totals (#104); the ZFS check rewritten (#107); custom iperf servers via -p (#113, September), letting providers and users point the test at their own servers; the first GitHub Actions build workflows for fio/iperf3 (September); ipinfo.io was evaluated as a geolocation replacement and declined because its free tier lacks fields downstream consumers depend on (#108).

Automation, Geekbench 7, and RISC-V: 2026

  • May–July — correctness fixes with user-visible effects: null Geekbench scores no longer corrupt JSON (#127), ZFS disk size (#118), uptime parsing (#92), latency now respects IPv4/IPv6 (#126), and the long-standing KiB vs KB mix-up (#120): fio reports KiB/s, YABS had labelled it KB/s, so every displayed disk speed had been ~2.4 % low since 2020.
  • 4 July — stats.yabs.sh launched: a static dashboard of run counts built from Cloudflare analytics.
  • 29 July — Geekbench 7 support (-7), six days after Primate Labs released it; Geekbench 6 stays the default.
  • September — the binary pipeline was rebuilt: musl cross-toolchains mirrored on a toolchains release (musl.cc blocks GitHub Actions' IP ranges), VirusTotal scans polled to completion, and the binaries removed from the repository in favour of fio-X.Y / iperf3-X.Y GitHub Releases that the script discovers at runtime.
  • October — a tar check (#99), a fix for btrfs subvolumes and bind mounts being double-counted in the disk total (#130), and experimental RISC-V support (#97, requested in October 2024), including riscv64 static binaries and Geekbench's RISC-V preview builds.

YABS by the numbers

Metric Value Source
First commit 2 October 2019 git history
First public announcement 7 October 2019 (LowEndTalk, HostBalls) forum threads
First 200+ run day June 2020 (234 runs) Mason, LowEndSpirit
Runs since 4 July 2025 2,705,514 (as of 31 Oct 2026) stats.yabs.sh
Runs in the last 30 days ~90,000 stats.yabs.sh
GitHub stars / forks ~6,500 / ~560 GitHub (Oct 2026)
Lines in yabs.sh 1,221 v2026-10-31
Supported architectures x64, x86, aarch64, arm, riscv64 yabs.sh
Public iperf3 servers 7 (both IPv4 and IPv6) yabs.sh
Geekbench versions 4, 5, 6 (default), 7 yabs.sh

People

  • Mason Rowe (masonr / MasonR / "yabs daddy") — author and sole maintainer; roughly 150 of ~200 commits.
  • Community reviewers of the fio design — Falzo, poisson, cybertech, beagle, WSS, Daniel15 (Daniel), Anthony Smith (InceptionHosting).
  • WSS — the "build it on Debian 7" advice that made static fio possible.
  • Daniel15 — issue #1 that pushed for fio.
  • webdock.io — issues #9, #12, #13 (JSON uploads, free-space check, ZFS warning) and the first result-database wireframes.
  • Dian Pratama — the logo (2021).
  • cybertech — started and curated LowEndSpirit's "Post some YABS bench here" thread (February 2020), the canonical results-sharing thread.
  • Contributors with merged PRs include hohl, su-haris, BKPepe, antonstech, dirk150, alfajorcito, webdock-io-admin, dqos, Debcharon, Cryptominer937 and others (see the GitHub contributors graph).
  • Result-database operators — VPSBenchmarks, YABSdb, serverlist.dev, ServerVerify (LowEndBox), VPS Host Review.

Timeline at a glance

timeline
    title YABS milestones
    2019 : Oct 2 first commit (iperf only)
         : Oct 5 Geekbench 4
         : Oct 7 announced on LET and HostBalls
         : Oct 8 ioping for reads, binaries run from CWD
    2020 : Jan 8 ioping removed, LC_ALL=C
         : Jan 13 static fio/iperf3 via Holy Build Box
         : Feb 4 fio replaces dd, 32-bit, IPv6-only
         : Feb 6 yabs.sh domain and one-liner
         : Feb 10 Geekbench 5 default, -r, -h, local packages preferred
         : Jun 20 Ctrl+C cleanup, -9
         : Dec free-space and ZFS checks
    2021 : Feb logo
         : Jun ARM support
         : Nov -b flag, locale warning
    2022 : Aug JSON output and upload (-j -w -s)
         : Nov latency column
    2023 : Feb Network Information, VM Type, Geekbench 6 default
         : Nov SHA-256 + VirusTotal, ShellCheck CI
    2025 : Sep custom iperf servers (-p), build workflows
    2026 : Jul KiB/KB fix, stats.yabs.sh, Geekbench 7
         : Sep binaries move to GitHub Releases, musl cross builds
         : Oct RISC-V (experimental)
Loading

Sources

Primary sources used for this page:

Third-party articles about YABS were consulted as additional data points only; where they conflicted with the code or primary discussions, the code wins.

See also

Repository · Issues · Binary releases · Usage stats · curl -sL yabs.sh | bash · Licensed under the WTFPL

Home

Using YABS

The tests

Internals

Help and project

Background

Clone this wiki locally