Adaptive SQM: rate-proportional HTB burst (~1 ms of line time) instead of the 5 KB clamp#1009
Open
Optic00 wants to merge 1 commit into
Open
Adaptive SQM: rate-proportional HTB burst (~1 ms of line time) instead of the 5 KB clamp#1009Optic00 wants to merge 1 commit into
Optic00 wants to merge 1 commit into
Conversation
calc_burst() now scales burst/cburst with ~1 ms of line time (rate_mbps * 125 bytes, clamped to [1500, 131072]) instead of clamping at 5000 bytes. On ingress IFB paths without GRO the 5 KB clamp keeps HTB timer-bound: measured on UCG Fiber at a 900 Mbit cap, throughput rises from ~630 to ~820-830 Mbit with flat RTTs.
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.
Fixes #1006.
calc_burst()now scales burst/cburst with the shaped rate -rate_mbps * 125bytes (~1 ms of line time), clamped to [1500, 131072] - instead of clamping at 5000 bytes. The function is shared between directions, so egress gets the same fix.Why: with a burst of 1-3 packets, HTB can only release a few packets per timer/softirq wakeup; on ingress IFB paths without GRO (observed
maxpacket 1492on UCG Fiber) throughput then degenerates into a function of scheduling latency instead of the configured rate. The full measurement matrix, the latency validation across rate tiers, and the end-to-end validation with exactly this formula are in #1006 - short version: 533/452 -> 832/521 Mbit at a 900/550 config on a UCG Fiber, flat p99 RTTs, 0% loss.Changes:
ScriptGenerator.cs: newcalc_burstformula; the comment now documents the measured reasoning and explicitly does not claim to contradict your earlier 5KB/8KB queue-variance findings from other hardware (they were not re-measured here).ScriptGeneratorTests.cs: a test asserting the formula and both clamps in every generated script, including that every embedded copy ofcalc_burst(boot + speedtest + ping scripts) carries the new formula, not just one of them.Behavior at low rates is effectively unchanged: below ~40 Mbit the formula stays within the previous 1500-5000b range (the 1500b floor applies below 12 Mbit; 100 Mbit yields 12.5k, i.e. still ~1 ms).
As offered in #1006: if you'd rather have the ceiling per-platform or as an advanced-config value instead of a constant, happy to rework in that direction. And if you can re-run your queue-depth-variance test with the rate-proportional burst on the hardware the 5 KB result came from, that would settle whether the higher clamp is safe everywhere.
Tests:
NetworkOptimizer.Sqm.Tests257/257 green on the rebased branch; the full suite was green on the pre-rebase commit.