Files
irtt-rs/crates/irtt-stats/README.md
T
Nils Andreas Svee b6043e4961
Rust CI / cargo fmt (push) Successful in 16s
Rust CI / cargo check (x86_64-unknown-linux-gnu) (push) Successful in 32s
Rust CI / cargo clippy (push) Successful in 34s
Rust CI / cargo check (x86_64-unknown-linux-musl) (push) Failing after 9s
Rust CI / cargo test (x86_64-unknown-linux-gnu) (push) Successful in 48s
Rust CI / cargo test (x86_64-unknown-linux-musl) (push) Failing after 9s
Rust CI / cargo doc (push) Successful in 21s
Fuzz Smoke / cargo fuzz smoke (push) Failing after 28s
Supply chain / cargo-deny advisories (push) Successful in 7s
Supply chain / cargo-deny bans licenses sources (push) Successful in 6s
Supply chain / actionlint (push) Successful in 2s
Netem Interop / netem interop (push) Successful in 1m2s
refactor(stats): use shared measurement statistics
2026-09-27 00:03:35 +07:00

2.4 KiB

irtt-stats

Statistics aggregation over irtt-client events: loss/duplicate/late accounting, RTT and one-way-delay timing, and inter-packet delay variation (IPDV), as cumulative and rolling snapshots.

Relationship to irtt-client

This crate does not open sessions or drive sockets. Feed it the ClientEvent stream produced by an irtt-client Client, AsyncClient, or managed session via StatsCollector::process, and read back a Snapshot.

Generic timing accumulation and count-window storage come from measurement-stats. TimeStats remains available from irtt_stats as a re-export. Event interpretation, IPDV pairing, loss, and snapshot reconstruction remain here.

A StatsCollector has one sequence/IPDV namespace and one packet count, both scoped to a single target. A managed session covering multiple targets needs one collector per target — as the irtt-rs CLI does — since a target's sequence numbers start over at zero and feeding two targets into one collector would pair up unrelated probes.

Retention modes

StatsConfig::finite() retains exact timing samples for its cumulative snapshot, so every metric with samples reports an exact median there — retention grows with the probe count. StatsConfig::continuous() keeps bounded running statistics instead (no exact median) plus a bounded 4096-entry adjacent-sequence IPDV store per target, for long-running or unbounded sessions. Rolling-window snapshots are always running-only and report no medians, whichever StatsConfig produced them.

An enabled time-based rolling window has no event-count cap, including in continuous mode. It expires only on new events, anchored at their timestamps; reading a snapshot does not advance time. Use count-based rolling storage for a hard bound on retained events. The memory estimate excludes time-window storage.

Exact snapshots sort a temporary copy of each metric's retained samples, adding O(n) scratch memory and O(n log n) computation for that metric. The retention estimate is not peak snapshot or allocator accounting.

See examples/ in the repository for a runnable comparison of both modes.

Documentation

Full API documentation is on docs.rs/irtt-stats.

Project

Part of irtt-rs, an independent Rust implementation of an IRTT-compatible protocol stack.