Why "0.1 ms to Jito" Doesn't Tell You Enough

When you shop for a low-latency Solana server, latency is often stated by providers as a single-value indicator like "0.1 ms to Jito." However decisive such figures look, they are not capable of describing how a network path behaves when your trade races someone else's. This article aims at explaining what is hidden behind the single-ping assertion, how latency data should be analyzed, and how you can independently verify claims made by providers, including ours.

What a Single Ping Omits

A single ping is a single round trip at a certain point of time within a certain network path. Trading systems experience thousands of round trips, and the races are decided by the path performing worst under certain conditions.

• Jitter: A path offering 0.1 ms performance at 3 a.m. might have very different performance at peak market periods. The difference between the quickest and the slowest submissions determines whether transactions are processed on time or are delayed in case of increased volatility.

• The tail: In case every 100th submission lags 10 times as much, p99 latency is the determining factor, not the best possible ping. A single quick ping does not provide any insight regarding tails; our tail-latency guide covers why the worst cases dominate MEV outcomes.

• Temporal context: A single measurement without timestamp, sample size, and window is not helpful in understanding the performance of the path.

Therefore, faced with the claim that latency is 0.1 ms, we must ask some key questions: Is this the best number recorded, or it is an average? When was it measured, from where, and to which endpoint? How many samples were taken and what was the measurement window? What kind of methodology was used to get the number?

Reading Minimum, Average, and Maximum

Continual measurement provides three simultaneous data points: the minimum, the average, and the maximum. The minimum is the best theoretical performance of the path given physical and routing limits. The average corresponds to the typical user experience. The maximum reflects the performance in the window's worst moment. Providers can have the same minimums but one can have triple the maximum; for trading systems, that difference is the whole story.

This is the reasoning that lies behind our Jito latency benchmarks, presenting the whole range of latency by location, supplemented with live updates and raw data in JSON format. This is not because min/avg/max is the perfect metric set, but because it is what we actually measure: small and truthful datasets are better than large and fabricated ones.

Independent Verification Procedures

Replication is the most solid way to verify the information.

• From the observer's location: Using the open-source tool jito-region-latency (run npx jito-region-latency). This program ranks Jito Block Engine regions by their latency from the observer's location, taking into account jitter and packet loss, giving your real distribution from your real vantage point.

• From the provider's data centers: The live latency checker uses probes from each OrbitServers location to Jito, major transaction senders, or any other destination of interest. This technique measures the same path as our published benchmarks using the same methodology with client-defined configuration.

A provider that passes the test does not require any marketing framing. That is the standard we hold ourselves to: minimum, average, and maximum latency values taken from single-tenant bare-metal environment in Frankfurt, Amsterdam, and every other Jito-connected city we operate, with live publication and the tooling to check us.

Latency assertions with sub-millisecond latency are not informative on their own. The proper assessment requires knowledge of the whole latency distribution, clear definition of the measurement parameters, and independent verification.

Common Questions

Is lower latency always better?
Not necessarily. Comparability requires consistency. The best case ping from one provider cannot be compared to a continual average of another provider. The comparison should be apples-to-apples: the same statistics, the same methodology, the same measurement window, and the same sample sizes. Preferably, measurements should be replicated from the observer's own environment.

Can p50, p95, and p99 be inferred from min/avg/max?
No. Percentiles require the complete empirical distribution. The inference of percentiles from three summary statistics makes assumptions about the distribution shape, which is often invalid due to latency tails. Therefore, the estimates obtained are approximations, not measurements.

What five questions should be asked to a provider?

1. What statistic is being asserted (best case, average, or some percentile)?

2. What is the origin of the measurement?

3. What is the destination of the measurement?

4. What is the measurement window and sample size?

5. Is replication possible for the client?

A provider that presents methodology and raw data upfront answers these questions.

Does sub-millisecond latency matter for every Solana workload?
No. In case your application requires extreme precision, like MEV extraction, arbitrage, and sniping, tail behavior decides races and every fraction of a millisecond matters, while consistency and uptime matter in case of RPC nodes serving applications or validators voting on schedule, and the difference between 0.2 ms and 2 ms to a sender is rarely the bottleneck.