Repository navigation
feat(network): Revise runahead from measured latency and frame pacing - #663
Open
tintinhamans wants to merge 11 commits into
Open
tintinhamans wants to merge 11 commits into
tintinhamans wants to merge 11 commits into
Conversation
tintinhamans
force-pushed
the
arctic/go/stack2/08-runahead-model-pacing
branch
4 times, most recently
from
October 26, 2026 15:39
8576101 to
6ce2e3c
Compare
…and forwarded traffic
tintinhamans
force-pushed
the
arctic/go/stack2/08-runahead-model-pacing
branch
from
October 28, 2026 01:47
6ce2e3c to
b963419
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge after #662.
The run ahead was set from a latency average over a number of 60 Hz samples, it could drop on a single quiet interval, the floor was a fixed number of frames whatever the send interval, and the FPS input reacted to brief dips. Frame pacing could only catch up from a fixed 2 frames late.
The decision now uses the in-band round trip averaged since the previous decision, taken as the average of the two highest round trips (LAN included). It goes up at once and falls only after
decrease_after_decisionsdecisions in a row asked for less, then to the highest of them. The floor is the send interval frames plus 3, so a minimum run ahead of 4 is possible at one frame per packet. The decision interval is at least twice the run ahead in ms, and while a connection repeats commands the formula adds one send interval for the repair. The FPS input is the median of the last samples. The run ahead a match starts with is seeded from the 75th percentile of each connection's lobby probe round trips (at least 10 samples), the highest of them, instead of the highest round trip the mesh history had seen, so one spike does not start a match at a huge run ahead.Service keys in
input_delay:min_frames(0 = send interval frames + 3, clamped 0 to 30),decision_interval_ms(1000, was 5000),fps_history_samples(30),catch_up_frames(1, retail catches up from 2). Ininput_delay.formula:latency_window_ms(0 = since the last decision) replaceslatency_history_samples,decrease_after_decisions(20, 0 follows at once like retail) andrepair_budget(true). The latency model key, theibra_*tweaks,connection.latency_history_msand the mesh latency histogram are removed. No wire change.The second commit is TheSuperHackers#3052: the cached insert position of
NetCommandListcompares sort numbers like the full scan does, so ACK commands stay ordered by the command they acknowledge.Tested: builds x86 Release
z_generals. The full stack had 0 CRC mismatches in 3 player rig runs. This formula was not measured separately.