Jito Latency Benchmarks by Location
These are continuously-measured round-trip times from OrbitServers' Jito-connected locations to nearby Jito transaction-sender infrastructure. We publish the measured minimum, average, and maximum — so you can verify performance before you deploy, not after.
Not a marketing ping: continuously measured min/avg/max from inside each data center, with public raw data and an open-source tool to reproduce it.
Last measured: 2026-09-27 02:24 UTC
| Location | Jito target | Min RTT | Avg RTT | P50 | P95 | P99 | Max RTT | Status |
|---|---|---|---|---|---|---|---|---|
| FrankfurtGermany | Jito (Frankfurt) | 0.17 ms | 0.18 ms | 0.18 ms | 0.19 ms | 0.19 ms | 0.19 ms | excellent |
| LondonUK | Jito (London) | 0.11 ms | 0.20 ms | 0.18 ms | 0.31 ms | 0.31 ms | 0.31 ms | excellent |
| AmsterdamNetherlands | Jito (Amsterdam) | 0.16 ms | 0.17 ms | 0.17 ms | 0.17 ms | 0.17 ms | 0.17 ms | excellent |
| New YorkUSA | Jito (New York) | 0.07 ms | 0.08 ms | 0.08 ms | 0.08 ms | 0.08 ms | 0.08 ms | excellent |
| Salt Lake CityUSA | Jito (Salt Lake City) | 0.07 ms | 0.09 ms | 0.09 ms | 0.12 ms | 0.12 ms | 0.12 ms | excellent |
| TokyoJapan | Jito (Tokyo) | 0.23 ms | 0.24 ms | 0.24 ms | 0.24 ms | 0.24 ms | 0.24 ms | excellent |
A dash (—) means that metric is not currently reported by the live feed for that location. Machine-readable data: /data/jito-latency.json.
Methodology
Latency is measured by continuous network round-trip probing from each OrbitServers location to nearby Jito transaction-sender infrastructure. Results are aggregated over recent rolling windows, and we publish the minimum, average, and maximum round-trip times from those windows.
The public feed is cached for a few seconds and fails open: if our measurement platform is briefly unreachable, the most recent known-good values are shown rather than a blank table or a fabricated number.
Want to verify? Our benchmarking guide walks through it, or run our open-source jito-region-latency tool (npx jito-region-latency) to rank every Jito region by latency from your own server.
The infrastructure behind the numbers
Every measurement originates from single-tenant bare metal inside our own racks — the same hardware customers deploy on. Servers ship with up to 100Gbps networking (10Gbps unmetered ports in Frankfurt and Amsterdam), a dedicated IPv4, and full root with IPMI/KVM, so kernel-level tuning like XDP or busy-polling is yours to apply — nothing between the NIC and your process.
Why we show min, average, and max
A single “average latency” figure hides how a connection behaves under stress. For trading and MEV, the tail matters most — so we publish the maximum alongside the minimum and average, giving you the full spread of what we measure rather than a single best-case number.
Limitations
These values are provided for infrastructure evaluation only. Real trading performance also depends on bot code, RPC configuration, Solana network conditions, system and kernel tuning, transaction strategy, and external market conditions. Providers and routes change over time — verify current performance for your own workload.
Methodology FAQ
Benchmark questions, answered
Our network-monitoring platform continuously probes the round-trip time from each OrbitServers location to nearby Jito transaction-sender infrastructure, aggregating the results over recent rolling windows. The figures shown are the minimum, average, and maximum round-trip times from those windows.
Min is the best round-trip time we measure, max is the worst within the recent window, and average is the typical value. Together they show both typical performance and how much the connection varies under load — which matters more for trading than a single headline number. We publish exactly what we measure and never invent figures we cannot stand behind.
Jito operates low-latency transaction-submission infrastructure used by Solana traders, MEV searchers, and arbitrage bots. Lower, more consistent round-trip time to this infrastructure can help latency-sensitive systems submit and react to transactions faster.
The values reflect the latest measured round-trip times at the time the page was loaded. Our live feed updates roughly every few seconds. If the feed is briefly unreachable, the most recent known-good values are shown rather than a blank table.
No. These figures are for infrastructure evaluation only. Real trading performance also depends on your bot code, RPC configuration, Solana network conditions, system and kernel tuning, and market conditions. Network latency is one input among many.
Yes — and we built the tool for it. Run our open-source jito-region-latency probe (npx jito-region-latency) to measure every Jito region from your own host with the same approach we use, including jitter and packet loss from where your bot actually runs. The raw benchmark data is also published as JSON at /data/jito-latency.json. Don't trust our numbers: reproduce them.