Skip to content
Iain Smith edited this page Aug 29, 2026 · 13 revisions

loadbearer

A command-line tool that benchmarks a machine's CPU, memory, disk and network stack — and its GPU where there is one — scores each measurement against a reference baseline, and grades every component and the machine as a whole on an S-to-F scale. Its reason for existing is the two-machine question: run it on laptop A, run it on laptop B, and get a defensible answer to which is better, by how much, and why.

This wiki is the deep dive into how each part works. For install instructions, the full CLI options tables, and a quick cheat-sheet, see the README instead — the wiki links back to it rather than repeating it.

What do you want to do?

Goal Command Page
Grade this machine loadbearer run Benchmark Methodology, Scoring & Grades
Decide between two (or more) machines loadbearer run --output a.json on each, then loadbearer compare a.json b.json Comparing Machines
Test the real network link between two machines loadbearer net-server on one, loadbearer run --net-target HOST:PORT on the other Benchmark Methodology
See if a laptop throttles under a long load loadbearer soak, or loadbearer run --soak Benchmark Methodology
Check a laptop's battery wear loadbearer info, or any loadbearer run Benchmark Methodology
Score for a specific workload, not "general" loadbearer run --profile dev-workstation Scoring & Grades
Re-grade an old result against a new baseline / profile / curve loadbearer score result.json --baseline our-fleet.toml The Baseline
Make results reproducible / scriptable --seed, --config, --plain, --json Configuration, Accuracy Notes
Trust the absolute scores, not just the deltas build a baseline from your own hardware The Baseline
Run it across a whole Windows estate loadbearer run --no-gpu --plain --target-dir ... --output ... via PDQ / Intune Fleet Deployment
See what's using RAM right now (ps_mem-style) loadbearer mem Memory by Program
Work out why a run behaved oddly read the diagnostic log Configuration
Understand a number in the report Scoring & Grades, Accuracy Notes

How a run flows

  1. Measure. Each benchmark runs its subtests one at a time. A subtest runs for a fixed wall-clock budget and counts the work it got through; that happens several times and the median is taken, with the run-to-run spread becoming a confidence flag. See Benchmark Methodology.
  2. Score. Every raw value is divided by the matching number in the baseline to get a ratio, which goes through a curve (score = 1000 · ratio^k). Component scores are the geometric mean of their subtests; the overall is a profile-weighted geometric mean of the CPU, memory and disk components (network is scored and shown but left out of the overall — it's an OS property more than a hardware one). See Scoring & Grades.
  3. Report. The scored result is printed (a TUI in a terminal, plain text or JSON otherwise) and, with --output, written as a versioned JSON file that compare and baseline can read. On a machine with a battery, the report also carries a BATTERY block — charge, health (full-charge vs design capacity), cycle count — shown but never graded, like network and gpu.

Pages

  • Benchmark Methodology — exactly what the CPU, memory, disk and network kernels do, how they're timed, and why; plus the GPU, battery and sustained-load reads.
  • Scoring & Grades — the ratio → curve → geometric-mean pipeline, the grade bands, confidence, and the four scoring profiles, all with worked numbers.
  • Comparing Machines — how compare builds a verdict from raw metrics, what its warnings mean, and reading the table for two or more machines.
  • The Baseline — what reference-v1 is, why it's provisional, the result-file schema, and rebuilding a baseline from your own result files.
  • Configuration — the --config TOML file: every key, the precedence rules, and example configs.
  • Accuracy Notes — what makes a result trustworthy or not: build flags, filesystem choice, thermals, queue depth, and what loadbearer deliberately does not measure.
  • Fleet Deployment — running it unattended across a managed Windows estate (PDQ / Intune / GPO): the command line, the scratch file, the unsigned binary, and collecting results.
  • Memory by Programloadbearer mem: a ps_mem-style per-program memory breakdown (true PSS on Linux, working set on Windows). A diagnostic, not a benchmark.

Design notes

loadbearer never touches the network, needs no elevated privileges, and runs with no configuration. A run writes a few GiB to --target-dir for the disk benchmark and deletes it afterwards; --only cpu,memory skips that entirely.

The scoring is intentionally boring and transparent: a documented curve over a documented baseline, geometric means throughout, no hidden weighting. If you disagree with a grade band or a profile weight, they are a few constants in src/scoring and the result files keep the raw metrics so anything can be re-scored later.

Clone this wiki locally