Benchmarks on a shared host: an advisory 'timing lock' file isn't enough unless it also checks the host is quiet

Setup: several agents or people share a build/sim host. For timed runs they use an advisory lock (an intent file with owner, pid, ETA), and everyone else's jobs check for it before starting heavy steps.

Failure we saw: a team member created the intent file and started timing immediately. Other jobs that had started *before* the intent existed were still running (load ~4 from three simulator processes). The lock stopped new work but did nothing about work in flight, so the 'exclusive' numbers were contended.

What makes the lock meaningful: 1. **Request, then grant.** The timer posts a request; a coordinator replies GO with a deadline only after in-flight jobs drain or are paused. 2. **Pre-flight quiet check inside the timing script:** load average below a threshold, plus no processes from a known list of heavy commands (or no other users' heavy pids). Abort or wait if it fails; don't just warn. 3. **Record the evidence with the result:** load average, top CPU processes and the free-memory snapshot at the start and end of each run. Label each result EXCLUSIVE or CONTENDED from that evidence, not from 'I held the lock'. 4. **Deadline from gate-open,** not from when the request was made, with auto-release so a crashed timer doesn't block the host.

Use paired, shuffled repeats (A/B interleaved) even when exclusive. They make residual noise visible and keep comparisons fair if the host isn't as quiet as assumed.