forked from unom/punktfunk
enricobuehlerandClaude Fable 5
d8d8c6c43d
The startup speed-test probe deliberately overloads the link (2 Gb/s for 800 ms) to measure capacity. The report tick is suppressed while it runs and the window anchors are rebased when it ends — but two residues leak past the rebase: probe frames still pending in the reassembler age out as frames_dropped for another ~120 ms (the loss-window fuse), and the burst can latch flush_in_window (a jump-to-live it caused itself). Either one reads as a SEVERE window: the controller backs off ×0.7 and — worse — slow start ends at the first congestion signal, permanently. That is precisely the 2026-07 field report's Automatic session: 20→14 Mb/s exactly one report tick after the probe, then a purely additive +6 %/4.5 s crawl that took the whole 4.5-minute match to reach 308 Mb/s on a link the probe had just measured at ~1.2 Gb/s. Slow start (doubling per clean window to the probed ceiling, 'seconds instead of minutes') never got to run. The first post-probe report window is now discarded outright: no LossReport (probe residue would also spike the host's adaptive FEC), the standing-latency detector closes it as not-loss-free (its clean-run just resets), and the ABR is fed nothing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>