The mid-stream clock re-sync starved on high-bitrate LAN sessions (2026-07
PyroWave-sawtooth field report, RX 9070 XT -> 780M @ 550 Mb/s): every batch
was judged against the CONNECT-TIME RTT, measured before the video data
plane existed, with a 2 ms floor — mid-stream control RTTs on a loaded GbE
link sit above that almost permanently, so batches were rejected for
minutes while the wall clocks drifted apart and the OSD e2e figure ramped
19->150 ms before snapping back on a lucky batch.
Three changes:
- Rounds are spaced 7 ms apart (stamped at send time, so the spacing never
lands in the RTT). An 8-round batch used to complete inside ONE ~6 ms
video burst — all rounds sampled the same congestion state; spacing walks
them across the frame cycle so the min-RTT round finds a quiet gap.
- ResyncGuard replaces the static baseline: the guard band follows the best
RTT the session has evidenced (connect RTT, then min over every completed
batch — rejected ones included).
- Rejection streaks are bounded: after 3 consecutive rejections the best
(min-RTT) batch of the streak is applied anyway. Its queueing bias is at
most ~half its RTT; unbounded wall-clock drift costs more per minute.
Rejections now log at warn with the streak and floor — the starvation
signature is grep-able in exactly the logs users send.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
enricobuehlerandClaude Fable 5
53640b8754