sbc-bench: a headless CPU benchmark for single board computers

A benchmark for boards that throttle under sustained load

sbc-bench is a small set of CPU performance tests aimed at single board computers, with an initial focus on energy efficient server tasks. The project says plainly that it tries to produce insights instead of fancy graphs, and that its focus is headless operation only, with no GPU or display work and no floating point number crunching.

That last constraint is the point. The problem the project addresses is the thermal reality of modern SBCs. The documentation argues that the SoCs used in these boards are performant enough that heat dissipation under sustained full load becomes a problem, and that the strategies for dealing with it differ by platform and kernel. It describes seeing CPU cores shut down when overheating on boards running original vendor software, and platforms where throttling works well until you switch kernels and the same hardware is trashed. It also says plainly that sometimes vendors cheat and it takes real effort to find out what is happening.

The tool's answer to that is a controlled environment plus intensive monitoring running in the background, with the monitoring data added to the results output. The screen output is a brief performance overview, but the documentation is clear that the real information is in the detailed output, which is uploaded to an online pasteboard service, with a Rock 5B run kept in the repository as results/41BH.txt.

The audience is specific: people who run servers, containers or services on SBC hardware, reviewers taking a board apart to find its limits, and the participants of the SBC debug parties the review modes were designed for. The primary language of the repository is Shell, and the whole thing is a single script, sbc-bench.sh, with a companion sd-card-bench.sh.

Eight modes in one script, each answering a different question

The documentation lists eight entirely different usage modes, and the switches are what make the tool flexible. A single flag changes what the script does with your system.

The base mode, used with `-c`, generates a rough CPU performance assessment for a specific board under ideal conditions. The `-m` switch provides basic command line monitoring, and the monitoring output is described in the documentation as now also showing some hardware information when it starts.

The `-k` switch shows kernel version information, and the documentation describes the kind of question it answers as whether the kernel is still supported, and whether it is a board support package kernel or a mainline one. That is a different kind of fact from a score, and it changes how much a benchmark number means on a given board.

The `-g` switch produces thermal and consumption charts, with a separate document, Efficiency_Graphing.md, describing how to use it to measure the efficiency of settings or devices. The `-t` and `-T` switches exist to help software and hardware developers improve thermal performance, and the documentation links forum discussions where they are used.

The environment modes are the remaining piece. `sbc-bench -G` prepares a controlled environment with appropriate settings for another benchmark suite such as Geekbench, and `sbc-bench -P` does the same for Phoronix. Instead of trying to be a benchmark, in those modes the script configures the machine so that a different suite can produce a fairer number.

Finally, the review modes `-r` and `-R` are built for reviewers and debug party participants who need to identify tunables and bottlenecks quickly. They report many performance relevant settings, switch them to maximum performance, and then lurk in the background monitoring other benchmark executions. Comparing scores made with defaults against scores made with the review settings tells you directly which settings need adjusting.

Download, run as root, and do it on a machine you can disturb

The tool is distributed as a single script fetched over HTTPS, and the documentation gives the supported operating systems first: Debian Stretch, Buster, Bullseye and Bookworm, or Ubuntu Bionic, Focal, Jammy and Noble. Older variants are not supported, and the reason given is that the distro packages are too outdated.

The documented execution sequence is:

wget https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh
sudo /bin/bash ./sbc-bench.sh -c

The first command downloads the script into your working directory and the second runs it with root privileges. The review mode is invoked the same way with a different switch:

sudo /bin/bash ./sbc-bench.sh -r

The root requirement is not incidental. The documentation explains that root is needed to adjust the cpufreq governor and to collect the monitoring data, and it adds a warning in bold: do not run this on productive systems, or if you do not understand what the script is doing. The script changes the governor and leaves the machine in a different performance state, so a production host is the wrong place for it.

There is one more procedural detail in review mode. It is designed to provide a sane environment for benchmark testing executed in another shell, so it keeps running in the background while you start a different suite. Because of that, stopping the script with ctrl-c is necessary when you are done, otherwise it stays there monitoring.

The summary is on screen, the evidence is in the pasteboard output

The monitoring output is the part most people will see first, and the documentation shows what it looks like. Starting with `-m`, the tool prints hardware information and then a live table of load, temperature and the two clock frequencies of a big.LITTLE system:

    tk@odroidxu4:~$ sbc-bench -m
    Samsung Exynos EXYNOS5800 rev 1, Exynos 5422, Kernel: armv7l, Userland: armhf
    CPU sysfs topology (clusters, cpufreq members, clockspeeds)

Below that, the table carries a timestamp, the current big and little clock values, a load average, the breakdown across user, system, nice, io and irq time, and the temperature read from a thermal zone in sysfs. The temperature source path is printed too, so you know which sensor the numbers come from.

The important caveat is the one the documentation states directly: without checking the detailed output, the numbers are worthless, because you always need to check what really happened. The screen summary is a convenience. The detailed run output is uploaded to an online pasteboard service, and the project keeps a copy of a Rock 5B run in the repository at results/41BH.txt so you can see the format.

That upload detail has a practical consequence. The results of your run, including the monitoring trace and the configuration in force, are sent to a third party pasteboard. For a public benchmark that is a feature, because the output can be linked and compared. For anything that touches a machine you care about, it is worth knowing that the data leaves the host.

mhz and the other measurement tools, and why each was picked

The tool leans on a set of established benchmark programs, and the documentation explains the reasoning for each choice. The list is mhz, tinymembench, ramlat, cpuminer, stockfish, 7-zip, cpufetch and the AES benchmarks from OpenSSL.

mhz is the interesting one because it is not a benchmark at all. It measures real CPU clockspeeds, which matters on platforms where cpufreq support is missing or where the clockspeed values the kernel reports cannot be trusted. The documentation names vendors who cap or misreport clocks, and boards where the real frequency is set by jumpers while the kernel derives its values from device tree entries. The example given is a Clearfog Pro routerboard where the device tree defines 666 and 1332 MHz while the hardware was configured to 800 and 1600 MHz by jumper, producing a 20 percent discrepancy:

    Cpufreq OPP: 1332    Measured: 1599 (1598.621/1598.759/1598.324) (+20%)
    Cpufreq OPP:  666    Measured:  799    (799.502/798.295/799.115) (+20%)

The tool calls mhz twice, once at the start of the benchmark with a cold and idle system, walking through all cpufreq operating points, and again directly after the most demanding phase. Comparing those two measurements is how a throttling event becomes visible rather than a matter of opinion.

The other tools cover the standard ground. tinymembench and ramlat measure memory behaviour, cpuminer provides the integer hashing work that is sensitive to core configuration, stockfish exercises a demanding integer workload, 7-zip tests compression throughput, cpufetch reports processor identification, and the OpenSSL AES benchmarks cover a cryptographic workload that uses the instruction set extensions a board's CPU actually has.

Review mode, benchmark parties and the file layout

The review modes deserve their own look, because they change what the tool is for. Rather than producing a score, they prepare the machine: they report many performance relevant settings, switch them to maximum performance, and then stay in the background while you run something else. The documentation frames them as designed for reviewers and participants of SBC debug parties who want to quickly identify tunables and bottlenecks that need further attention.

The comparison it enables is the interesting part. By running a suite once with the default settings and once with the review settings applied, you can attribute a difference in score to specific settings rather than to the hardware. That is a genuinely different workflow from running a benchmark, and it is why the mode exists.

The repository is organised around that workflow. `sbc-bench.sh` is the main script, `sd-card-bench.sh` is a separate companion for storage rather than CPU, and there are directories for `pics/` and `results/`. The documentation side includes `Results.md` and `Sorted-Results.md` for collected results and `Efficiency_Graphing.md` for the graphing mode, alongside `Benchmarking_some_benchmarks.md`.

The `results/` directory is the part that makes this a comparative tool rather than a one-off script. Every published run, including its detailed monitoring output, is a data point that can be compared against another board or another kernel. That is the long term value of the project: a shared body of comparable measurements for hardware that has almost none of its own.

The licence is BSD-3-Clause, which permits use, modification and redistribution with the usual conditions of retaining the notice and the disclaimer. The repository is not archived and the last push was on 2026-10-12, so the script is being revised, but there are no GitHub releases, so there is no versioned history to pin and no changelog to read before you run it.

Where sbc-bench is the wrong tool

The clearest limitation is the one the documentation puts in bold: this is not a tool for productive systems. Root access is required to change the cpufreq governor and to collect monitoring data, so the script mutates the performance state of the machine it runs on. On a host you care about, that is a policy decision as much as a technical one.

The second limitation is the scope. The tests are CPU focused and headless by design, with no GPU or display work and no floating point workloads. A board whose real limit is memory bandwidth, storage throughput, USB negotiation or network will look good on these numbers and still disappoint in practice. The review modes do surface some of the non CPU problems, and the documentation mentions counterfeit SD cards and USB negotiation problems as things the mode exposes, but the measured scores are still CPU scores.

The third limitation is platform coverage. The supported systems are current Debian and Ubuntu releases, and the documentation is explicit that older distributions are excluded because their packages are too outdated. A board running something else, or an unusual minimal distribution, is outside the tested set. The script also depends on sysfs interfaces for thermal zones and cpufreq, which vary between kernels and vendors, and the documentation is candid that vendor behaviour ranges from well behaved throttling to cores being shut down entirely.

The fourth is that this is a shell script you fetch over the network and run with root. There is no signed release, no versioned artifact and no package to pin. You are trusting the contents of the file you just downloaded, and the project offers no checksum to verify it against. For a benchmark whose entire purpose is to produce numbers other people will trust, that is worth thinking about before you paste a run into a review.

The alternative to weigh is the general purpose benchmark suite. Tools like Geekbench or Phoronix, which sbc-bench explicitly supports preparing environments for with `-G` and `-P`, are broader, better documented and give you comparable figures against a large existing body of results. The difference in approach is that those suites measure a device in a fixed state and produce a score, while sbc-bench measures a device while it changes state, and produces the evidence for why the score moved. If you need a number to quote, use the general suite. If you need to know why your board is slow, use this script.

Editorial conclusion

sbc-bench is the right tool for anyone comparing single board computers under sustained CPU load, or for a reviewer who needs to know which cpufreq and thermal settings are throttling a board, because the monitoring runs in the background and the detailed output is published for inspection. It is the wrong tool on a production machine, since it needs root to change the governor, and on boards where the interesting limit is memory bandwidth, storage or I/O rather than the CPU. Before running it, confirm the board runs a supported Debian or Ubuntu release, read the script, and plan to capture the pasteboard output rather than the short summary it prints on screen.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. ThomasKaiser/sbc-bench on GitHub