-
Notifications
You must be signed in to change notification settings - Fork 0
Home
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.
| 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 |
- 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.
-
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. -
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 thatcompareandbaselinecan read. On a machine with a battery, the report also carries aBATTERYblock — charge, health (full-charge vs design capacity), cycle count — shown but never graded, likenetworkandgpu.
- 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
comparebuilds a verdict from raw metrics, what its warnings mean, and reading the table for two or more machines. -
The Baseline — what
reference-v1is, why it's provisional, the result-file schema, and rebuilding a baseline from your own result files. -
Configuration — the
--configTOML 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 Program —
loadbearer mem: aps_mem-style per-program memory breakdown (true PSS on Linux, working set on Windows). A diagnostic, not a benchmark.
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.
Pages
- Benchmark Methodology
- Scoring & Grades
- Comparing Machines
- The Baseline
- Configuration
- Accuracy Notes
- Fleet Deployment
- Memory by Program
Commands
-
run— benchmark & grade -
compare— head-to-head verdict -
score— re-grade a result file -
soak— sustained-load / throttle test -
baseline— build a baseline -
net-server— real link test -
mem— per-program memory (ps_mem-style) -
info·list— inventory & catalogue
Not in the grade
-
network · gpu · battery health ·
--net-targetlink ·--soak