RTT

What RTT actually measures

Imagine sending a tennis ball to a friend across the room: RTT is the time from your throw until you catch their return. For network packets, RTT is the time from when your device sends a packet until it receives an acknowledgment. The acknowledgment may be an ICMP Echo Reply (ping), a TCP ACK (for TCP traffic), or an application-layer response.

RTT is end-to-end. It includes:

• Time on your local network (router, WiFi, Ethernet).
• Time on your ISP's network (last-mile and core).
• Time across transit and peering networks.
• Time on the destination's network.
• Time on the destination server (rare — most ping responses are instantaneous).
• The same in reverse for the response.

RTT components

Typical RTT by connection type

Cross-continent RTT has a physics floor: New York to London is about 5500 km in fiber path, so minimum RTT is 5500 × 2 / 200,000 = 55 ms. Add a few ms for routers and switches; sub-70 ms NYC-London RTT is achievable.

Why RTT matters for applications

Gaming

Each player input (key press, mouse click) must reach the server and the result (you hit or missed) must reach back. RTT directly determines responsiveness. Competitive FPS players require under 30 ms; below 15 ms is pro-level. See Ping for more.

Voice and video calls

One-way audio delay over 150 ms causes the talk-over-each-other problem. RTT under 200 ms keeps interactive conversation smooth. Above 400 ms RTT, conversations feel like radio broadcasts.

HTTP and web

Each HTTP transaction (request + response) is one RTT. TCP setup adds another RTT. TLS adds 1-2 more RTTs depending on version. A single web page load involving many resources can require 20+ RTTs end to end — even on a fast connection, high RTT to the server makes page loads feel slow.

This is why CDNs exist: by placing copies of content close to the user, they reduce RTT from "across the world" to "across the city," collapsing the multiple-RTT cost of page loads.

Database and API calls

Each query is one RTT minimum. Applications that make many sequential database queries become RTT-limited rather than CPU-limited. Putting the application and database in the same region is a standard pattern specifically to minimize RTT between them.

RTT and TCP throughput

TCP throughput is bounded by RTT in a way that surprises people. The Bandwidth-Delay Product (BDP) formula:

max throughput ≈ TCP window size / RTT

For a 64KB window (common default) and 100 ms RTT, the maximum is 640 KB/sec = ~5 Mbps regardless of how much bandwidth the link has. To use a 1 Gbps link with 100 ms RTT, you need a TCP window of about 12.5 MB — much larger than the default. Modern TCP stacks support window scaling up to 1 GB, but operating system tuning is required to actually use it.

This is the "long fat networks" problem: high-bandwidth, high-latency links require careful TCP tuning to saturate. CDNs and edge computing reduce RTT and sidestep the issue.

Measuring RTT

• ping — the standard tool. Sends ICMP Echo Request; measures time to receive Echo Reply. ICMP may be deprioritized; treat as approximate.
• TCP ping (tcpping, hping, paping) — measures TCP handshake RTT. Better correlates with what real TCP traffic experiences.
• curl --time — measures HTTP request RTT including DNS, TCP, TLS, and the HTTP exchange itself.
• tcpdump / Wireshark — captures actual packet traces; RTT extracted from timestamps.
• Application metrics — most production applications track database RTT, cache RTT, etc. as core SRE metrics.

Frequently Asked Questions

Is RTT the same as latency?

Closely related but not identical. Latency strictly means one-way delay (the time for a packet to reach its destination), while RTT is the round-trip — there and back. In practice, people use "latency" and "RTT" interchangeably because measuring true one-way latency requires synchronized clocks at both ends, which is rarely available. Ping measures RTT and reports it as "latency." Halving RTT gives a rough estimate of one-way latency for symmetric paths.

What is a good RTT for gaming?

Under 30 ms is excellent for competitive games. Under 50 ms is acceptable for most online play. Above 100 ms, fast-paced shooters and fighting games become difficult. RTT is the dominant factor in "feel" for online games — even a 50 ms RTT means your input arrives at the server 25 ms after you press the button, and you see the result 50 ms total later. Fiber internet delivers 5-15 ms RTT to nearby servers; cable 15-30 ms; satellite 30-50 ms LEO or 600+ ms geostationary.

What contributes to RTT?

Four components: propagation delay (signal travels at ~200,000 km/sec in fiber — physical distance matters), serialization delay (time to transmit bits onto the wire), queuing delay (waiting in router buffers — the source of bufferbloat), and processing delay (each router examining headers). For long distances, propagation dominates. For congested networks, queuing dominates. For very high-speed links, serialization is tiny.

Why is satellite internet RTT so high?

Geostationary satellites orbit at 35,786 km altitude — a round trip is 143,000+ km, which at the speed of light takes about 480 ms before any other delays. Real RTT is typically 600-700 ms. LEO satellites (Starlink) orbit at 500-1200 km, reducing the propagation delay to 20-40 ms. The physics is unavoidable — RTT scales linearly with distance traveled.