agentsclimarketplace

Sosp reproducibility

Skill brycewang-stanford/Awesome-Journal-Skills/SOSP-Skills/skills/sosp-reproducibility

Use when hardening the reproducibility of a SOSP paper's results before submission — pinning the OS-level environment, recording hardware and topology, making every figure regenerable from logged runs, separating measurement noise from effect size, and preparing the ground for post-acceptance artifact evaluation.From its SKILL.md

Install
npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill sosp-reproducibility

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

5.1 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

SOSP Reproducibility

Use this while experiments are being designed and run — months before the SOSP deadline, not during artifact evaluation. At SOSP the artifact process happens after acceptance (see sosp-artifact-evaluation), which means reproducibility discipline has a different job pre-submission: it protects you. Reviewers probe numbers during a three-month review cycle and a response phase in which new experiments are forbidden; the only defensible paper is one whose every number can be traced to a logged, re-runnable measurement of a pinned system.

The OS-research twist: your system changes the platform

An operating-systems artifact often is the environment — a modified kernel, a new scheduler, an interposed I/O path. That collapses the usual app/platform separation and creates specific hazards:

  • A rebased kernel patch series can silently change baseline behavior; record the exact base commit and the full patch stack for every run, including baseline runs.
  • Firmware, microcode, and mitigations (for example, speculative-execution mitigations) can dominate syscall-heavy microbenchmarks; log them and hold them constant across system and baseline.
  • Frequency scaling, turbo states, and NUMA placement move tail latencies by tens of percent; fix the policy, and record it rather than assuming defaults.

Capture the environment mechanically

Hand-written "Experimental Setup" sections drift from reality. Generate the facts:

#!/usr/bin/env bash
# capture-env.sh — run on every experiment node, archive with the run's results
{
  uname -a; cat /etc/os-release | head -2
  cat /proc/cmdline                          # mitigations, isolcpus, hugepages
  lscpu | grep -E 'Model name|Socket|NUMA|MHz'
  free -h | head -2; lsblk -d -o NAME,MODEL,ROTA,SIZE
  ip -br link; ethtool eth0 2>/dev/null | grep -E 'Speed|Duplex'
  git -C "$REPO" rev-parse HEAD; git -C "$REPO" status --porcelain
} > "env-$(hostname)-$(date +%Y%m%dT%H%M%S).txt"

Archive one such file per node per experiment batch, next to the raw results. When a reviewer asks eleven weeks later whether the baseline ran with the same mitigations, the answer is a file, not a memory.

One command per figure

The standard that survives review pressure: every figure and table in the paper is produced by a script that reads only archived raw logs. No spreadsheet steps, no hand-transcribed numbers. This is also what makes the response phase survivable — you can re-check any reviewer-doubted number against raw data without re-running anything, which is the only kind of "checking" the response rules allow.

DisciplinePre-submission payoffPost-acceptance payoff
Raw logs archived per run, immutableResponse-phase answers under the no-new-data ruleAE claims map writes itself
Figure scripts read logs onlyNo PDF/data divergence between draftsEvaluators regenerate your plots
Environment capture per node per batchDetects config drift between system and baseline runshardware/ directory is done
Run manifest (who, when, which commit, which config)Attribution when a number looks offProvenance for the archival artifact

Variance is a first-class result

Systems effects live in distributions. Reproducibility at SOSP includes making the noise floor explicit:

  • Report repetitions and the spread (percentiles or CIs), especially for tail-latency claims — a p99 from one run of one trial is folklore, not a measurement.
  • Distinguish sources: run-to-run jitter, node-to-node hardware variation, and time-of-day effects on shared testbeds. If experiments ran on a shared cluster, say so and quantify what that cost in variance.
  • Decide the warm-up policy (discard first N iterations? cold-start included?) once, document it, and apply it uniformly; asymmetric warm-up between system and baseline is a classic self-inflicted review wound.

Traces and workloads you cannot publish

Production traces make SOSP evaluations compelling and reproductions hard. The honest pattern: characterize the private trace in the paper (size, arrival statistics, skew, whatever drives the result), release a synthetic generator matched to those statistics, and show at least one headline experiment where synthetic and real traces agree in trend. Flag in the paper which results are re-runnable and which are documented-only — the same tiering the artifact evaluation will ask for later.

Output format

[Repro posture] traceable / partially / folklore
[Environment] capture automated? mitigations+kernel pinned for baseline too?
[Figure pipeline] all one-command? exceptions: <list>
[Variance] repetitions, spread reported, warm-up policy uniform?
[Private data] trace characterization + generator plan
[Gap list] <ordered fixes before the freeze>

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.