Packetman saysThis page explains the heart of DataStun: how we measure a network without abusing it. The big idea is dispersion. Instead of flooding your link with hundreds of megabytes like a conventional speed test, we send a short train of about ten packets back to back and measure how far apart they arrive at the other end. That spacing is set by the slowest link in the path, so a few packets reveal the bottleneck without ever loading the link. Then we add a trust layer, because kernels and Wi-Fi can bunch packets up and fake a high speed — we detect that and label it instead of reporting a fantasy number. We use TCP, UDP, ICMP and QUIC as different lenses, each answering a different question, and we never silently substitute one for another. Read on for the diagrams.Every other speed test floods your link to guess its capacity. DataStun sends about ten packets and reads the physics of how they arrive. Here’s how, and why a tiny test is the more honest one.
Send two packets back-to-back into a path. They enter touching. By the time they pop out the far end, the slowest link between them — the bottleneck — has pushed them apart. Measure that gap and you have the bottleneck’s capacity. No flood required. We send a short train of about ten packets rather than a single pair, which averages out noise and lets us see loss and reordering at the same time.
Because we measure the gap between arrivals, not absolute clock times, the two ends don’t need synchronized clocks. We measure deltas, which cancels any offset. This is the same principle behind classic research tools like pathrate and bprobe — we’ve productized it for continuous, fleet-wide use.
TCP starts slow on purpose. A fresh connection ramps its sending rate up over several round-trips (“slow-start”) until it finds the path’s capacity. If you measure during that ramp, you measure the ramp — not the link. The naive fix is to blast a big burst to “get past” slow-start, but that is the flood we refuse to send.
Instead we pre-warm: a small priming stream runs until the connection’s congestion window stops growing, and only then do we take the measurement. On Windows we read the real congestion window straight from the kernel (SIO_TCP_INFO); on Linux from TCP_INFO. Pre-warm bytes are overhead, not part of the measurement budget.
This is why we say TCP is our loss-evidence lens, not our throughput number. For throughput we use dispersion; for loss and retransmission detail we read TCP’s own bookkeeping.
Here’s the dirty secret of timing-based measurement: the operating system lies to you. Modern kernels batch incoming packets (NAPI/GRO coalescing) and Wi-Fi radios bunch frames and release them in clumps. When several of our packets arrive in one clump, their gaps collapse toward zero — and a naive calculation reads that as impossibly fast, like a gigabit on a connection that can’t do a tenth of that.
So every dispersion result ships with a trustworthiness verdict, not just a number. We count what fraction of the inter-packet gaps are suspiciously tiny (a path-aware clustering statistic), and we compute the rate with robust estimators (lower-envelope and Theil-Sen median-slope) that resist a few collapsed gaps. When the data looks buffer-driven rather than physical, the result is badged, not silently reported.
TCP is half-duplex in spirit: the path from A to B can behave nothing like the path from B to A. Different queues, different shaping, different congestion. So we measure and report every metric independently in each direction — throughput, latency, jitter, loss, reordering. A pair that looks healthy one way and ugly the other is telling you exactly where to look. We’ve measured real sub-millisecond asymmetries between two virtual machines on the same host, caused purely by scheduler quirks — the kind of thing a single round-trip number hides completely.
The single most powerful health signal in this set is TCP retransmission rate: retransmitted segments over total segments sent. It’s the cleanest evidence of real loss and congestion, and it’s measured per direction too.
TCP, UDP, ICMP and QUIC are not interchangeable transports we pick at random — each answers a different question, and we never silently substitute one for another. A result is always labelled with the lens that produced it.
| Lens | Best at | Blind to |
|---|---|---|
| UDP burst | Throughput (dispersion), latency, jitter, loss count, reordering | No stream semantics — no retransmit detail |
| ICMP burst | Same as UDP where firewalls block UDP; reaches across many paths | Often deprioritized by routers; IPv6 support is rolling out |
| TCP | Loss evidence — retransmission rate, duplicate ACKs, SACK holes, slow-start curve | Short runs corrupt throughput (slow-start) |
| QUIC | Throughput + availability over a modern encrypted transport | TLS 1.3 hides transport headers — opaque to loss inspection |
The operator picks the lens for the question. We run the right one and tell you which it was.
For the hard cases you can opt in, per test, to a real packet capture. The crucial design choice: the agent captures with a facility it already has (the same kernel packet path it uses for ordinary observation), strictly filtered to the one peer and port under test, bounded and auto-stopped. The capture is ephemeral — uploaded to the platform and immediately deleted. No analyzer, no Wireshark, no deep storage ever lands on your endpoint.
All the heavy lifting — the expert TCP analysis, the IO graph, the retransmit/dup-ACK/SACK breakdown — happens centrally, on the platform, where a full decode stack lives. The endpoint stays light; the forensics stay rich.
Next: how the agent mesh works → Or: how the fabric stays secure →