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
53 lines
2.4 KiB
Markdown
53 lines
2.4 KiB
Markdown
# irtt-stats
|
|
|
|
Statistics aggregation over [`irtt-client`](https://crates.io/crates/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](https://docs.rs/irtt-stats).
|
|
|
|
## Project
|
|
|
|
Part of [irtt-rs](https://github.com/Lochnair/irtt-rs), an independent Rust
|
|
implementation of an IRTT-compatible protocol stack.
|