Network path quality
How the connection itself is behaving, beyond raw speed: how much TCP had to retry, how far a transfer ramped up, and how steady the packet timing was. These come from deliberate tests rather than passive listening, so they appear only while a test runs.
In the app’s tile picker they sit under Testing, alongside the iPerf3 results they come from.
| Metric | What it means | Unit | How to read | Source | Learn more |
|---|---|---|---|---|---|
Jitternetwork.jitter | Variation between recent probe round-trips. Reserved for active probing, which is not switched on in the app today, so this is absent from recordings. | ms | Lower is better | YANL | — |
Latencynetwork.latency | Round-trip time to the test server. Reserved for active probing, which is not switched on in the app today, so this is absent from recordings. | ms | Lower is better | YANL | — |
Packet Lossnetwork.packet_loss | Share of probes that got no answer. Reserved for active probing, which is not switched on in the app today, so this is absent from recordings. | % | Lower is better | YANL | — |
TCP Congestion Windownetwork.tcp_cwnd | The sender's congestion window during an iPerf3 test: roughly how much data TCP is willing to have in flight at once. Watching it grow shows how quickly a transfer ramps up. | KB | — | iPerf3 | — |
TCP Retransmitsnetwork.tcp_retrans | TCP segments the sender had to send again during an iPerf3 test. Retransmissions point to loss or congestion somewhere on the path. | — | Lower is better | iPerf3 | — |
UDP Datagram Lossnetwork.udp_loss | Share of datagrams that never arrived during an iPerf3 UDP test. | % | Lower is better | iPerf3 | — |
UDP Jitternetwork.udp_jitter | Variation in packet arrival timing measured by an iPerf3 UDP test. Steady timing matters more than raw speed for calls and video. | ms | Lower is better | iPerf3 | — |
Where each one comes from
During an iPerf3 test. network.tcp_retrans and network.tcp_cwnd are read from the
TCP test output, and network.udp_jitter and network.udp_loss from UDP tests. Nothing is
recorded for them outside a test: a gap in the log means no test was running, not a
measurement of zero.
Not collected yet. network.latency, network.jitter and network.packet_loss are
reserved for continuous active probing. The app does not probe on its own today, so these
are absent from recordings. They are listed here because the log format reserves the names,
and because probing is on the roadmap.
Why the app does not probe by default
Sending a small packet every second to measure latency would hold the modem’s radio in its connected state for the whole recording. That changes handover behaviour and the performance every other app on the phone sees, which would mean the tool quietly altering the thing it is supposed to be measuring. When continuous probing arrives it will be something you switch on deliberately for a test, not a background default.