pathmeasure

Documentation

Overview

Command pathmeasure asks what a stack achieves on a path, which is the question pathprobe deliberately refuses to answer.

pathprobe sends open-loop and counts what arrives, so it describes the path and nothing else. That is the right instrument for finding an erasure floor or a capacity knee, and the wrong one for the question this project's datacenter work actually turns on: given a path that erases a seventh of what crosses it, what does an ordinary TCP connection do, and how much of the gap is the path's fault rather than the transport's?

The two instruments together separate the two. Where pathprobe delivers 256 Mbit/s at 300 offered and TCP delivers a fraction of a megabit over the same minutes, the difference is not the path. It is a congestion controller reading rate-independent erasure as congestion and backing off from a link that was never congested.

Modes:

serve      sink TCP bytes, push them, or count a UDP blast
tcp        send for a duration and sample the kernel's account of why
fct        flow completion time for request-sized payloads, cold and warm
burst      repeated bursts on one connection, with the window at each step
udp        open-loop UDP in the upload direction
h2serve    an HTTP/2 sink whose flow-control windows are settable
h2proxy    terminate HTTP/2 locally with generous windows and stream onward
h2         upload over HTTP/2, to measure what those windows cost
load       many concurrent request flows, reporting the tail
frames     many concurrent frame streams, reporting per-message latency
ab         order-alternated A/B of two arms, pooled
workload   order-alternated A/B of a real HTTP request against both arms
stream     order-alternated A/B of a token stream, reporting the gaps
streamserve emit tokens at a fixed cadence, so the generator is not a variable
rtt        round-trip distribution

Every mode can be pointed through a SOCKS5 proxy, so a tunnel and the path beneath it are measured by the same instrument rather than by two.

The tcp mode is the latency-attribution instrument. Goodput alone cannot distinguish a small congestion window from a small receive window from an application with nothing to send, and those need different fixes; TCP_INFO names which one was binding in each interval.