refactor(playback): make link budget an explicit constant (greg = 1 GbE) - #50
Merged
Conversation
Follow-up to #49. The direct-play bitrate cap divided a hidden magic number (link_mbps=800, a default param in reliability.py) across cells. greg→skyhawk is confirmed 1 GbE, whose ~940 Mbps TCP goodput held to ~85% headroom IS ~800 — so the number was right, but read as a guess. Promote it to constants.LINK_MBPS (env HYPERWALL_LINK_MBPS), documented as the 1 GbE usable ceiling with retune notes for 2.5/10 GbE, and feed it through effective_bitrate_budget_mbps so the whole budget tracks one knob. No behavior change at the default (800 → 33 Mbps/cell at 8 cells, same as #49); the aggregate stays well inside the link (8 × 33 ≈ 264 of 800 Mbps). Tests: link-speed sensitivity (800/2000/400 Mbps) + LINK_MBPS wiring. Suite green at v10.13.1. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
Follow-up to #49.
Why
The burst-aware direct-play bitrate cap divided a hidden magic number —
link_mbps=800, a default parameter buried inreliability.py— across cells, with no record of where 800 came from. The #49 description even flagged it as "an assumption, not a measurement."It's now confirmed: greg→skyhawk is 1 GbE. A 1 GbE link delivers ~940 Mbps TCP goodput at line rate; held to ~85% so concurrent readahead fill-bursts + control traffic (SSH) don't saturate it, that's ~800. So the number was already right for the hardware — it just read as a guess.
Change
constants.LINK_MBPS(envHYPERWALL_LINK_MBPS), documented as the 1 GbE usable ceiling with retune notes (2.5 GbE ≈ 2000, 10 GbE ≈ 8000).effective_bitrate_budget_mbps→scale_bitrate_budget_mbpsso the whole budget tracks a single knob.No behavior change at the default: 800 → 33 Mbps/cell at 8 cells, identical to #49. The aggregate stays well inside the link (8 × 33 ≈ 264 of 800 Mbps).
Tests
test_scale_bitrate_budget_tracks_link_speed— cap scales with the link (800 → 33, 2000 → 60/base, 400 → 16).test_link_mbps_constant_wired_into_effective_budget— the constant is actually fed through.Suite green at v10.13.1.
Verify
Same as #49 — rebuild (
build.ps1, pwsh 7) and confirm the logRuntime:banner reads v10.13.1 before A/B'ing.🤖 Generated with Claude Code