Probe throughput on the Linux gating VM is ~7-70x Windows, and concurrent dev sessions make the UI gate unreliable nf-r45 ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/620 by tools/beads/import_github.py's reconcile pass.

Measured while working #572 on the Linux gating VM. Filing rather than fixing: every remedy is an infrastructure or scheduling decision, not a code change.

The numbers

Frame pacing, measured through the harness (a wait step's wall clock), same tree, same box:

| Box state | 1-min loadavg | ms per rendered frame | |---|---|---| | idle-ish (other sessions stopped) | ~0.9-5 | ~107-169 ms | | loaded (5 dev sessions) | 10-30 | ~850-1150 ms | | loaded, at nice -20 | 15 | ~850 ms |

For scale, on the same tree: dotnet build took 24 s idle and 4-6 min loaded. Design 003 §2.2 measured the full 34-probe sweep at 5m18s on a 4-core Linux box vs 3m28s on Windows; on this box under load it was running at ~4.5 min per probe, i.e. a projected ~2.5 hours.

Even idle, ~107-169 ms/frame is roughly 7-10x a 60fps host. Under load it is 50-70x.

Why it matters

⚠️ It silently converts correct UI into reported regressions. butterbar-gate asserts that the gesture butterbar is still empty a couple of frames after a press — a claim that under PianoRoll's 300 ms hold gate has elapsed. At 850-1150 ms/frame that window is blown by 5-10x, so a *correctly* shown bar reads as a UI regression. It reproduced 3 runs for 3 under load and passed 3 runs for 3 once the box went quiet, from the same commit.

⚠️ Determinism did not mean 'not contention'. This box is *always* loaded, so a load-induced failure reproduces perfectly and looks like a solid platform difference. That reading is recorded in more than one place already and it is wrong; it is the trap #572 was set up to avoid and nearly fell into.

The margin is thin even when quiet. #615 added budget_ms to name this failure mode; on the idle box the measured window runs 313-410 ms against a 300 ms budget. So this host sits right at the edge of being able to evaluate that class of assertion at all — with no headroom for a second session.

The consequence for the direction of travel

#566 and design 003 (#547) point at Linux gating every merge. merge_pr.py runs probe_gate.py, i.e. ~24 Godot launches, inside the merge. On this box that is minutes-to-hours depending on who else is working, and the result is only trustworthy if nobody else is. Five dev sessions currently share 2 cores.

Directions, not a decision

• More cores on the gating host. llvmpipe is CPU-bound and 2 cores is the binding constraint; this is the direct fix and the only one that also fixes wall-clock.
• A dedicated gating box that runs no dev sessions — the sweep is the one workload whose result depends on being alone.
• Serialise probe runs across sessions (a lock), so two sweeps never overlap. Cheap, does not fix the idle-box margin.
• Run the sweep post-merge and asynchronously rather than inside merge_pr.py, so merge latency stops tracking box load.
• Accept it and lean on budget_ms — the diagnostic is now in place, so a slow-host failure at least says so. Weakest option; it does not make the gate trustworthy, only legible.

Worth noting design 003 S8's --fixed-fps does not help here: it re-couples delta, not the clock, and the gate is on Time.GetTicksMsec() (see #617).

Related: #572, #615, #617, #619 (same box, missing import cache), #566, #580, design 003 (#547) S8/S9.

Unclaimed.