feat(server): add bandwidth-measure generation counter - #1963
Open
Greg Lamberson (glamberson) wants to merge 2 commits into
Open
feat(server): add bandwidth-measure generation counter#1963Greg Lamberson (glamberson) wants to merge 2 commits into
Greg Lamberson (glamberson) wants to merge 2 commits into
Conversation
bandwidth_kbps alone reads as noise on a damage-driven video source: a single 1.25s measurement window catches either near-idle traffic (a handful of cursor/autodetect PDUs, ~1.8KB) or a real EGFX frame landing in it (tens of KB), so the same unthrottled link reports anywhere from ~11kbps to ~600kbps depending on what the encoder happened to be doing in that specific window. Logging time_delta_ms/byte_count alongside the computed figure makes that bimodality visible instead of looking like a calculation bug -- the formula (byte_count*8/time_delta_ms) was already correct; the volatility is inherent to counting real traffic over a short window against a bursty source, not a defect.
The bandwidth figure alone repeats too often to tell a fresh measurement window apart from a stale one (a quiet link reads the same low figure for several consecutive windows). Expose a counter that increments on every completed Bandwidth Measure transaction, successful or not, so a consumer can gate its own filtering logic on "a new window just closed" instead of diffing the value itself.
Greg Lamberson (glamberson)
deployed
to
llm-providers
September 12, 2026 23:39 — with 
GitHub Actions
Active
GitHub Actions
Active
github-actions
Bot
added
kind/protocol
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.
Summary
autodetect_bandwidth_handle()(feat(server): expose measured bandwidth to the embedder #1734) exposes the latest BandwidthMeasure figure, but a consumer doing its own smoothing/filtering on
top of it (e.g. rejecting noisy low samples unless real demand
existed) needs to know when a new measurement window has closed,
not just what the figure currently reads. The figure itself is a bad
freshness signal: a quiet link reads the same low value for several
consecutive windows in a row, so diffing it cannot tell "fresh
window, same result" apart from "stale, no new window yet".
autodetect_bandwidth_generation, mirroringautodetect_bandwidth's exact shape: anArc<AtomicU32>field,autodetect_bandwidth_generation_handle()accessor, andwith_autodetect_bandwidth_generation_handle()builder method. Itincrements on every completed Bandwidth Measure transaction,
successful or not — a completed-but-unusable window still needs to
advance the generation so a consumer's own stale-demand bookkeeping
gets cleared instead of carrying over into the next window.
from just the computed
bandwidth_kbpsto also include thetransaction's raw
byte_count/time_delta_msinputs. Useful on itsown for anyone diagnosing why the figure looks noisy against a
bursty traffic source (as this crate's own damage-driven server
usage does): the raw inputs make it immediately visible whether a
low reading came from a genuinely idle window or a short one that
happened to close early.
Validation
cargo xtask check fmt/lints/typosall pass;cargo test -p ironrdp-server --features egfx,helpergreen (5 passed, 1 ignored,plus doctests).
Notes
No public API break: both changes are purely additive to
RdpServerBuilderandRdpServer.