fix(router): cap the adaptive active mux at adaptCap even under load - #4206
Merged
Merged
Conversation
The proactive-park was gated on !saturated, so it only trimmed the active set when the group was idle. During the uncap fill the pool establishes hundreds of legs — all born active — and the route-setup/keepalive traffic makes the group read as saturated, so the park stayed suppressed and the active set ballooned to dozens of legs (observed live: ACTIVE climbing 16->31 while standby froze), head-of-line-stalling the no-skip reorder buffer. Introduce a two-tier park floor: converge active down to the lean steady target (desiredActive) when idle, but ALWAYS cap it at adaptCap — the maximum the saturation-growth rule (4) would ever build — even under load. Legs born active beyond adaptCap are shed slowest-first regardless of saturation; a real bulk download already sits at adaptCap, so only born-active excess is parked, never the legs the download is using. bundle.wasm regenerated (TinyGo); parity_test green; new test asserts the cap holds under sustained saturation.
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
1 participant
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.
The proactive-park was gated on
!saturated, so it only trimmed the active set when idle. During the uncap fill the pool establishes hundreds of legs (all born active), and route-setup/keepalive traffic makes the group read as saturated — so the park stayed suppressed and the active set ballooned (observed live: ACTIVE 16→31 while standby froze), HoL-stalling the no-skip reorder buffer.Two-tier park floor: converge active to the lean steady target when idle, but always cap at
adaptCap(the max rule 4 would ever build) even under load — born-active excess is shed slowest-first regardless of saturation, while a real download (already at adaptCap) keeps its legs.bundle.wasmregenerated;parity_testgreen; new test covers the cap under sustained saturation.