DrumsBench

Methodology

How a number gets onto this site, and what stops a bad one.

Workloads, baselines, correctness gates, cost accounting, statistics and the exact steps to reproduce a run.

Workload selection

Baseline fairness

Correctness gates

flowchart LR
A[Restore fidelity] --> B[Reset correctness]
B --> C[Isolation with positive control]
C --> D[Throughput at confirmed N]
D --> E[Cost per valid rollout]
E --> F[RL with only the environment changed]
Gate order. A later gate is not run, and its numbers are not reported, until the earlier one passes. The custom Linux runtime is at the first gate; the macOS arm is at the third.
  1. Restore fidelity before any performance comparison. The state hash after a restore must equal the hash after the snapshot. On Linux the pre-resume lock census must equal CRIU's dump record, the network namespace must be byte-identical before and after, and the mount contract must hold. The custom runtime currently fails the lock half (EXP-009).
  2. Reset correctness. After every reset the work tree must match the golden manifest, the clipboard must be empty, and no application process may be left over. A reset that cannot kill its applications fails rather than proceeding. Reset correctness is a requirement at 100%, not a target.
  3. Isolation with a canary and a positive control. A never-touched environment is watched continuously; the eleven isolation tests run per window; a zero is printed only next to a positive control that fired. See verifiers and contamination.
  4. Validity gates per attempt. Pre-check, generation check, timeout, verifier availability, isolation. Checker exit 0 is success, 1 is a task failure (still valid), anything else is invalid. A verifier that is unavailable makes the attempt invalid, never a failure.
The per-attempt gates. Each one can turn an attempt invalid; invalid attempts are kept in the cost and removed from the valid count and from training.

Cost accounting

usd_per_valid_rollout = host_usd_per_hour / valid_rollouts_per_host_hour

Statistical uncertainty

Model configurations

Evidence rules

from a run to a number on a pagerun on namedhardwareraw logs kept(never deleted)result folder+ meta.jsondata/results/*.json (schemacheck at build)pagegeneratedbuild fails on a row with no number, an unknown experiment id or a bad file name.a result file names its source paths; pages quote the file, never a typed number.status gates (never promoted; when in doubt, the lower one)verifiedmeasurement file on named hardware, run recordedpreliminaryreal; needs more runs, a positive control or an independent checkfailedran; missed a correctness, isolation, reset or pre-registered barplannedsource or protocol exists; nothing ran; no numbersrule: a contamination count of zero prints only next to a positive control that fired.
From a run to a table: raw logs in the results folder, a result JSON validated by schema at build, the experiment record naming hardware, commit and evidence paths, then the generated table. Author-claimed numbers stop at the record.

Reproduction

macOS arm

Prerequisites on the Mac: Xcode Command Line Tools with Swift 6, Homebrew, uv. Every host-changing target refuses to run without DRUMS_HOST_OK=1. Set RUN=results/<date>-<host>-mac once and keep it.

StepTargetWhat happens
0git clone; uv sync; make test; make build-envdboth test suites; envd release build
1DRUMS_HOST_OK=1 make setup-hostHomebrew casks (LibreOffice, Chrome, UTM), power settings, multiple sessions on, the install prefix, the signing identity, FileVault check
2DRUMS_HOST_OK=1 make create-usersenv00 to env32, hidden standard users
3DRUMS_HOST_OK=1 make install-launchagentthe envd launch agent per account
4make goldenbuild the golden work tree with an empty note
5DRUMS_HOST_OK=1 make seed-env-homesclone the golden tree into every env user's home
Gate 0make gate0FileVault, user count, CGSession, console session state, env00 home mode
6make meta, then make baseline-samplemachine metadata; 60 s of host samples with no env logged in
7make verify-serverin a second terminal, same RUN; leave running
8DRUMS_HOST_OK=1 make probesprobes A, B, C, P in order; stops at the first fail; needs a terminal with Accessibility and sudo
9by handlog in env00 and env09 to env32, grant Accessibility, first capture per session, count clicks and minutes per login
Gates 1, 2make health, make gate1; after step 10 make gate2 COORDS=...every envd healthy; round trips; screenshot p95; 20 writer and 20 browser rollouts; reset p95; 20 stale-generation trials
10by handmeasure the six task coordinates in env01's session; pass as COORDS= from here on
11DRUMS_HOST_OK=1 make park-consoleconsole to the login window (by hand on builds without CGSession, which includes 15.7.5)
12make health, stat -f %Su /dev/consoleevery envd trusted with a non-black screenshot; console user is root
13make sweep COORDS=...two 15-minute windows per N; isolation tests per window; stops at the first unconfirmed N
14make soak N=<N_max> COORDS=...60 minutes, then 100 stale-generation trials and a pasteboard check
15make positive-control COORDS=..., make isolation-extra N=<N_max> COORDS=...the positive control; tests 8, 9, 11
16make report EUR_USD=<rate> STUDIO_USD=<invoice>the table and cost.json; make power-sample as root during 13 and 14 for watts
17make baseline-linuxprints the Linux steps; run inside the Ubuntu guest with OS=linux PY=python3
18make results RUNS="results/<mac run> results/<linux run>"the results document and the README block; commit

A second machine runs make reproduce (metadata, then a sweep at N of 1 and 4 with two confirming runs each, then the report) and prints the four Gate 10 numbers.

Linux arms

The Linux harness runs one user-supplied workload against arms through an adapter contract. Sketch, from the harness README (nothing here has been run against a real VM yet; see EXP-015):

python -m osworld_smoke.make_workload --image /path/to/Ubuntu.qcow2 --out workload.json
python -m drumsbench baseline-hash --workload workload.json --baseline-config baseline.json
python -m drumsbench plan --workload workload.json --arm baseline --baseline-config baseline.json
python -m drumsbench run  --workload workload.json --arm baseline --baseline-config baseline.json \
    --money money.json --out-dir runs/baseline-1 --execute
python -m drumsbench run  --workload workload.json --arm drums --arm-config arm.json \
    --money money.json --out-dir runs/drums-1 --execute
python -m drumsbench verify-receipts runs/baseline-1/receipts.jsonl
python -m drumsbench reconcile runs/baseline-1/summary.json baseline-billing.json --out runs/baseline-1/reconciled.json
python -m drumsbench reconcile runs/drums-1/summary.json drums-billing.json --out runs/drums-1/reconciled.json
python -m drumsbench compare runs/baseline-1/reconciled.json runs/drums-1/reconciled.json

The baseline config hash must be pre-registered before the run; run refuses without --execute and without a money file; compare accepts only measured and reconciled summaries and always emits claim: null. The OCI reference arm and the custom rootfs candidate are driven per slot by their own modules and must pass the sameness gate (same image hash, task, checker and limits) before any number is recorded.

How this site is built

Each experiment is one MDX file with structured frontmatter (id, dates, status, arms, hardware, OS, branch, commit, evidence paths, one limitation line). Each measurement set is one JSON file under data/results/ that names its experiment, arm, host, workload, method and sources, and holds rows with a number, a distribution summary or a pass count. Every content file and every result file is validated against the same schemas before the build; a result file that points at an unknown experiment, or a row without a number, fails the build with the file name. Pages are generated from these files; the benchmark tables are never typed by hand. The site is a static export with no tracking.