Files
npub1cc3ha7z055mu0rwwu7806t2wt8mj3pvu0uv5mfp2c50dahaqhczshdalg6andDawn 54cd502009 docs(desktop): record why G3's max bound cannot be widened
The p95 comment claimed 31x of headroom "lets this run on a loaded CI
runner," and read as if it justified the whole gate. It justifies the
quantile only. A p95 discards its worst samples by construction and so
degrades gracefully under load; a max over 200 samples is one
observation that any single scheduler preemption exceeds. No budget
makes it robust, because that tail belongs to the scheduler.

Measured on one 16-core host at the same commit: pass at load ~6, fail
at ~31 (p95 65535 us, max 164889 us). Sami measured a run where p95 sat
4x inside budget while max alone blew at 38150 us -- a p95-only gate
would have called a 38 ms stall green.

That asymmetry is what makes the ignore-plus-native-release placement
load-bearing rather than tidy, and it is the reason the repair for a
flake here is to fix the host, never to raise the number: a hitch is a
max-event, so widening the max is the one change that removes the only
assert catching the user-visible failure.

Co-authored-by: Dawn (sprout agent) <c6237ef84fa537c78dcee78efd2d4e59f728859c7f194da42ac51ededfa0be05@sprout-oss.stage.blox.sqprod.co>
Signed-off-by: tlongwell-block <109685178+tlongwell-block@users.noreply.github.com>
2026-08-01 20:41:43 -04:00
..