Skip to content

Raspberry Pi Benchmark Methodology: Power, Temperature, Storage, Network, and AI

Useful benchmarks answer a narrow question and give another person enough information to repeat the test. A single “maximum FPS” or “NVMe speed” number is not reproducible without hardware, software, thermal, and measurement context.

This guide defines the measurement protocol used across this site. It deliberately provides commands and result tables rather than invented results; observed values must come from a named physical test system.

Record the Test System First

Capture this block with every result:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
mkdir -p benchmark-results
{
  date --iso-8601=seconds
  cat /proc/device-tree/model
  cat /etc/os-release
  uname -a
  vcgencmd get_config int
  vcgencmd get_throttled
  lscpu
  free -h
  lsblk -o NAME,MODEL,SERIAL,SIZE,ROTA,TRAN,FSTYPE,MOUNTPOINTS
  ip -brief link
} | tee benchmark-results/system.txt

Also record information Linux cannot discover reliably:

  • Raspberry Pi RAM capacity and board revision
  • power supply and measured cable
  • cooling, fan policy, case, and ambient temperature
  • storage firmware, carrier/HAT, and PCIe cable
  • external power-meter model, resolution, and sampling interval
  • camera, accelerator, model file checksum, and input data checksum
  • Git commit or script version

Do not include Wi-Fi passwords, serial numbers you consider private, API keys, or public IP addresses in published logs.

Control the Environment

Before each run:

  1. Reboot into the same OS and service configuration.
  2. Wait a fixed idle period.
  3. Confirm vcgencmd get_throttled and temperature.
  4. Close unrelated workloads or record them explicitly.
  5. Use the same governor, fan policy, display state, and network path.
  6. Run a warm-up that is excluded from results.
  7. Run at least five measured repetitions.

Report median plus minimum/maximum or percentiles. Do not select only the fastest run.

Power and Temperature

Raspberry Pi computers do not expose accurate whole-board input power through a universal software sensor. Use an inline USB power meter or a calibrated bench supply, and measure at the same point for every device.

Log thermal and frequency state in parallel with the external power reading:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
interval=1
duration=600
output=benchmark-results/thermal.csv

printf 'timestamp,temp_c,arm_hz,throttled\n' > "$output"
for _ in $(seq 1 "$duration"); do
  timestamp=$(date +%s)
  temp=$(awk '{print $1/1000}' /sys/class/thermal/thermal_zone0/temp)
  arm_hz=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
  throttled=$(vcgencmd get_throttled | cut -d= -f2)
  printf '%s,%s,%s,%s\n' "$timestamp" "$temp" "$arm_hz" "$throttled" >> "$output"
  sleep "$interval"
done

Use stress-ng for a repeatable sustained CPU load:

1
2
sudo apt install stress-ng
stress-ng --cpu 0 --cpu-method matrixprod --timeout 10m --metrics-brief

Report idle power after a fixed settling period, peak power, steady-state median power, energy over the test, maximum temperature, clock distribution, and any current or historical throttling bits.

Boot Time

Distinguish firmware, kernel, userspace, network-ready, and application-ready time:

1
2
3
systemd-analyze
systemd-analyze critical-chain
systemd-analyze blame | head -30

For an appliance, add an external observer that requests a health endpoint once per second from power-on. systemd-analyze cannot measure power application, DHCP availability from another computer, display readiness, or the first correct application response.

Run cold boots by removing power for a consistent interval. Reboot timing is a different metric and should be labelled separately.

Storage

Do not run destructive tests on a raw production device

Test a disposable file on the mounted filesystem. Direct writes to /dev/mmcblk0, /dev/nvme0n1, or another raw device can destroy partitions and data.

Install fio, create a test directory with enough free space, and save the exact job:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
sudo apt install fio
test_dir=/path/to/test-filesystem

fio --name=seq-read-write \
  --filename="$test_dir/fio-test.bin" \
  --size=4G \
  --direct=1 \
  --rw=readwrite \
  --bs=1M \
  --iodepth=16 \
  --runtime=120 \
  --time_based \
  --group_reporting \
  --output-format=json \
  --output=benchmark-results/storage.json

rm "$test_dir/fio-test.bin"

Use a dataset larger than available RAM when measuring storage rather than cache. Report filesystem, mount options, free capacity, test-file size, queue depth, block size, read/write mix, runtime, drive temperature, and whether TRIM or garbage collection had time to run.

Network

Use a wired iperf3 server on the same switch for an Ethernet baseline:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
sudo apt install iperf3

# Server
iperf3 --server

# Raspberry Pi client
iperf3 --client <server-address> --time 60 --omit 5 --json \
  > benchmark-results/network-upload.json
iperf3 --client <server-address> --reverse --time 60 --omit 5 --json \
  > benchmark-results/network-download.json
ping -c 200 <server-address> > benchmark-results/ping.txt

For Wi-Fi, also record band, channel width, access-point model/firmware, distance, obstacles, RSSI, channel utilisation, and nearby interference. A speed-test website mixes LAN, ISP, server, and browser effects and should not replace a controlled LAN test.

AI Inference

Hash the model and input so every accelerator receives equivalent work:

1
sha256sum model.* input.* | tee benchmark-results/ai-inputs.sha256

For vision workloads, report:

  • model family, precision, input dimensions, confidence and NMS thresholds
  • capture, decode, resize, inference, post-processing, and render time separately
  • warm-up count and measured frame count
  • model-only throughput and end-to-end FPS
  • latency p50, p95, and p99
  • dropped frames, CPU usage, power, temperature, and throttling

For LLM/VLM workloads, report prompt and output token counts, time to first token, output tokens per second, context size, model package, quantisation, and whether prompt processing is included. TOPS values at different numeric precisions are not direct application-performance measurements.

Result Table Template

Field Value
Test objective
Pi model / RAM
OS / kernel
Firmware / EEPROM
Power supply / meter
Cooling / ambient
Storage / network / accelerator
Workload and checksum
Warm-up / repetitions
Median result
p95 or min/max
Idle / load power
Maximum temperature
Throttling state
Raw data URL

Publish the raw CSV or JSON with units and a short README. Charts should be generated from those files, not manually transcribed.

Common Benchmark Mistakes

  • Comparing different models, resolutions, or accuracy targets
  • Reporting cached storage reads as drive speed
  • Mixing Wi-Fi and Ethernet paths
  • Measuring power at different locations or with different cable losses
  • Ignoring warm-up, thermal saturation, or throttling
  • Comparing a vendor kernel with a stock kernel without disclosure
  • Treating QEMU performance as Raspberry Pi performance
  • Publishing expected or estimated numbers as measurements
  • Omitting failed runs and dropped frames

FAQ

How many repetitions are enough?

Five is a practical minimum for stable tests. Noisy latency, network, storage, and radio tests need more samples and percentiles.

Can vcgencmd measure_volts replace a USB power meter?

No. It does not provide a complete calibrated measurement of whole-board input current and energy.

Should benchmarks disable every service?

Only if the objective is maximum isolated performance. For deployment guidance, test the realistic application stack and document its background services.