Test Methodology

Geekbench6 is a general purpose benchmark suite that covers a range of test subjects. My single core scores are the result of pinning to the fastest CPU core, and then a separate run on all cores is done for the multi-core scores.

Geekbench 7 is the latest generation of the general purpose benchmark suite, covering a range of test subjects. My single core scores are the result of pinning to the fastest CPU core, and then a separate run on all cores is done for the multi-core scores.

High Performance Linpack has been included to offer GFLOPS, GFLOPS per Watt, and GFLOPS per $ values. I've tried to deconstruct the Ansible playbook that Jeff Geerling uses so that the numbers are somewhat comparable.

Single core 7-Zip tests are pinned to the fastest CPU core for single-core data, and then against all cores for the multi-core values. I use the same version (16.02) as sbc-bench for backwards compatibility, and comparison purposes.

UnixBench is a system performance benchmark that tests various aspects of Unix-like systems. It measures CPU performance, file I/O, process creation, and system call overhead to provide an overall system score.

PassMark PerformanceTest covers a range of CPU and RAM tests, giving an overall system score for both metrics, comparable against thousands of benchmark runs.

A 5 minute run of cpuminer-multi hits the CPU quite hard and leaves us with a single, and multi-core hashrate in KH/s. I don't think you'll be rich on the back of the numbers here but those that want to know, can. If you become rich off the back of some meme coin after finding the perfect SBC to mine on, do remember me.

For this power consumption test I utilise stress-ng. We take a baseline power reading after sitting idle for 60 seconds before throwing everything stress-ng has to offer at the system. Ollama and Linpack tests are also measured, and we show the peak power utilisation during both of those tests.

IMPORTANT NOTE: All power figures on this site are based on the test setup at the time of testing. If the results page has microSD, eMMC, and NVMe results, the power values are with all 3 of these connected. It should also be noted that all values are with the performance CPU governor set.

stress-ng --cpu 0 --matrix 0

iPerf3 offers a network throughput test over the available network interfaces. The iPerf3 endpoint for this is running on my LattePanda Mu connected at 10Gbit over SFP+ to my Ubiquiti Pro 48 PoE switch.

iperf3 -c $server_ip -t 60 -P 8 -O 10 --bind-dev $interface

4K, 64K, and 1MB block sizes are tested across sequential read, sequential write, random read, and random write tests using fio. I also grab the IOPS values, and test against as many storage mediums as possible. If a board has microSD, NVMe, and eMMC, all 3 will be tested and the data made available. Where possible, the Raspberry Pi 64GB microSD card will be used as the microSD card of choice, and the Crucial P5 Plus 1TB as the NVMe option. If a vendor has their own eMMC/UFS modules, the biggest size I have is used.

glmark2 is an OpenGL ES 2.0 GPU benchmark run via a headless Weston compositor on DRM. Each board is tested at both 1080p and 4K (3840x2160) resolutions in fullscreen mode. Software renderers (llvmpipe, softpipe, swrast) are detected and rejected: only hardware-accelerated results are recorded. GL vendor, renderer, and version strings are captured for each run.

glmark2-wayland --fullscreen

vkmark is a Vulkan GPU benchmark run via a headless Weston compositor on DRM. Like glmark2, each board is tested at both 1080p and 4K resolutions. The test first checks for a hardware Vulkan device using vulkaninfo and rejects software implementations (llvmpipe, lavapipe, swiftshader). Vulkan device name, driver version, and vendor/device IDs are captured.

vkmark --winsys wayland --fullscreen -p immediate

vkpeak measures the GPU as a compute device rather than a renderer: it runs Vulkan compute shaders (via the ncnn Vulkan backend) and reports the peak arithmetic rate for each data type — FP32/FP16/FP64 and INT32/INT16/INT64/INT8 in scalar, vec4 and, where the hardware has it, cooperative-matrix form — plus BF16/FP8/FP6/FP4 matrix rates and host↔device copy bandwidth. It runs headless with no compositor, so nothing but the shader cores and driver is being measured. The same hardware-Vulkan check as vkmark rejects software implementations. Every scenario is run by default; a result of 0 means the GPU or driver lacks that data type, not that the test failed. vkpeak is built from source on each board (cached per SoC), and the comparison charts show FP32, FP16 and INT8 — the rates that matter for general shader compute, GPU inference and quantised models respectively — with all 26 scenarios in the full table.

vkpeak 0 all

SuperTuxKart 1.5's built-in benchmark replays the exact same ghost race on the Black Forest track, making it a highly repeatable real-game GPU test rather than a synthetic one. The official Linux builds are run fullscreen via a headless Weston compositor (through Xwayland, as the official binaries are X11-only) at both 1080p and 4K, with identical pinned medium graphics settings, vsync disabled, and sound off on every board. Rather than a simple average FPS, SuperTuxKart's own stability-aware metrics are recorded: Typical FPS (the frame rate the game mostly renders at), Mostly Stable FPS, and Steady FPS (the floor held for ~99% of the run).

./run_game.sh --benchmark --fullscreen

MAME's built-in benchmark emulates 90 seconds of an arcade game with no video or sound output and no frame limiter, then reports the average emulation speed as a percentage of real time: 100% is exactly full speed. Each game is run three times and averaged; if the three passes differ by more than 5%, up to two more passes are run. Every pass starts from a clean configuration directory so that saved settings on the board can't change the workload, and the game files are checked with MAME's own ROM verification before the first pass. MAME is installed from each board's own Linux distribution, so the version is recorded alongside every result. Emulation leans heavily on one fast CPU core, so results follow single-core performance more closely than multi-core scores.

mame <game> -bench 90 -noreadconfig

How many people can watch at once from a board running Jellyfin, when every stream needs transcoding. We run jellyfin-ffmpeg, Jellyfin's own FFmpeg build, on four scenarios at a fixed bitrate (4 Mb/s for 720p, 8 Mb/s for 1080p), with no audio or subtitles: 1080p H.264 and 1080p HEVC to 720p, 1080p HEVC to 1080p, and 4K HEVC 10-bit to 1080p. Software transcodes use libx264 at the veryfast preset; hardware transcodes use the decode, scale and encode pipeline Jellyfin builds for that hardware. Streams run flat out and in parallel; after a few seconds to settle we measure each one over 25 seconds, and a level passes when the slowest stream still keeps up with real time. The result is the most streams that passed. The CPU is tested by adding one stream at a time. Where Jellyfin supports the board's video engine (Intel Quick Sync or VA-API, Rockchip MPP, V4L2 encoders), the hardware path is tested too, stepping to the stream count its measured throughput predicts; whether the hardware or the CPU around it ran out is recorded. Clips play from the board's boot drive, as a server's library would, and a memory check stops the ramp before the board runs out of RAM. Where the board's image lacked the drivers or firmware a hardware path needs, the test installed them from the image's own package repositories (Jellyfin's package for Intel), and those results are marked.

How fast a board decodes video in software, and how fast it converts it. Every board runs the same FFmpeg 9.0.2 build, compiled for its architecture (with x264, x265, dav1d and SVT-AV1, each library's CPU optimisations recorded), so the numbers compare processors directly. Clips are cut from the open film Tears of Steel (Blender Foundation, CC BY 3.0) and loaded into memory before timing, with output discarded, so storage plays no part. We decode H.264, HEVC, HEVC 10-bit, VP9 and AV1 at 1080p, HEVC and AV1 at 4K, and H.264 on a single thread, as frames per second (24 fps is real time); then convert H.264 to HEVC and AV1 with each encoder's default settings (x265 medium at CRF 28, SVT-AV1 preset 8 at CRF 35). Each is run three times, with up to two more passes if they disagree by more than 5%. Separately, we check which formats the board's hardware video engine decodes correctly, clip by clip against a software decode, and time its hardware decoding (Works* in the table means the frames decode but stay in video memory, so only their count is checked), using FFmpeg builds that support that hardware (FFmpeg with Quick Sync and VA-API for Intel, ffmpeg-rockchip for Rockchip vendor kernels, LibreELEC's V4L2 and Raspberry Pi patches elsewhere). Hardware results depend on the board's kernel and drivers as much as on the chip.

ffmpeg -benchmark -i <clip> -f null -

Finally (for now), I've yet again stolen from Jeff and after installing Ollama from Ollama directly, I pull Jeff's fork of the ollama-benchmark software so that numbers can, again, be compared between our test results. At the moment this will largely be CPU-only data, unless the system has a compatible device that Ollama detects. Later down the line I plan to utilise things such as RKNN-specific forks to test the NPUs in certain devices but for now, it's purely CPU, with DeepSeek R1 models tested based on the RAM available.