Reading an RTT latency benchmark
2026-05-06 · ~6 minute read
Every trading platform with a serious infrastructure story publishes some version of a latency benchmark. Not all of them are honest, and even the honest ones can be misread. This is the practitioner's short guide to interpreting a round-trip-time benchmark before you draw conclusions from it.
What a single number is hiding
“Our latency is 18 ms” is a useless statement. Latency is a distribution, and the shape of the distribution determines the trading outcome. The same mean RTT can come from a tight distribution where every order is between 15 and 22 ms, or from a bimodal distribution where most orders are 10 ms and a few are 300 ms because the connection occasionally re-handshakes. The second case is much worse for execution quality, and the mean does not capture it.
The percentiles you actually care about
- p50 (median): The typical experience. Useful as a sanity check for routing region.
- p95: The worst 1-in-20 order. The first percentile that starts to matter for trading outcomes, because it is hit often enough to dominate the tail of your fill distribution.
- p99: The worst 1-in-100 order. The percentile where retransmits, garbage-collection pauses, and network blips start to show up. A p99 that is much worse than p95 means the tail is unusually thick.
- max: Almost useless on its own; one bad orbit can spike it. Useful only paired with a percentile that is robust to a single outlier.
What “good” looks like for retail-tier execution
Numbers below are illustrative reasonable expectations for a millisecond-tier retail platform deployed in the same region as the exchange:
# Illustrative — in-region RTT to a major crypto venue p50: ~ 18-30 ms p95: ~ 35-55 ms p99: ~ 60-90 ms max: can spike to 200+ ms during a venue queue burst
Numbers below this are possible but rare for non-co-located deployments. Numbers far above this on a platform claiming in-region deployment indicate either a wrong-region client or an undersized client process.
Watch for selection bias
If a benchmark says “our latency is X,” check four things:
- Is X the mean, the median, the best ever recorded, or the average of one good day? Only the median or higher percentiles over a continuous window are honest.
- From which region was X measured? Cross-region numbers dominate the metric in either direction depending on direction of travel.
- Is X a continuously updated number, or a screenshot? Latency benchmarks can rot the moment infrastructure changes.
- Does the benchmark include round-trip from the user's browser to the platform, or only from the platform to the exchange? The second is what matters for trading; the first is a vanity number.
Jitter is the hidden enemy
Jitter is the variability of latency between consecutive measurements. A path with mean 30 ms and jitter 2 ms is much healthier than a path with mean 25 ms and jitter 40 ms, even though the second has a lower headline number. High jitter means your aggressive fills sometimes arrive after the price has moved. The first sign of network or NIC trouble is jitter climbing while the mean stays flat.
What a buyer should ask for
One concrete request: a continuously updated table on a stable URL with p50, p95, p99 RTT per region per exchange, plus a small jitter statistic and an indication of which region is currently selected for live order flow. That is enough to tell whether the platform is measuring its own infrastructure or telling you a story.
Anything less is a slogan. We are happy to be measured against ours and we publish it on /proof. If the live data feed is still being warmed up when you arrive, the labels say so.