Round Trip Time Calculator
Solve the classic round-trip relation RTT = 2 · (Ttrans + Tprop) for any of its three unknowns — round trip time, one-way transmission delay, or one-way propagation delay — with step-by-step math, a live packet-and-ACK schematic, and companion latency metrics.
Two delays, two different physics
Transmission delay is a bandwidth effect: it is the time to serialise the packet onto the wire, Ttrans = L/R. Propagation delay is a distance effect: it is the time for the signal to cross the link, Tprop = d/v. Buying more bandwidth shrinks Ttrans but does nothing at all to Tprop — you cannot buy your way to a lower speed of light. This is the single most important distinction in latency engineering.
Distance dominates on long paths
On a 4,000 km fibre path the propagation delay is about 20 ms, while a 1,500-byte packet at 1 Gbps has a transmission delay of only 12 µs — over a thousand times smaller. On long-haul routes the round trip is essentially a distance problem, and the only real levers are shortening the physical path or raising the signal velocity in the medium. This is why latency-sensitive trading firms pay for straight-line microwave routes instead of following fibre.
Bandwidth matters for small packets too
Transmission delay scales with packet size and inversely with link rate, so it becomes significant on slow links. A 1,500-byte packet takes 1.2 ms to serialise at 10 Mbps, which is comparable to the propagation delay of a 240 km fibre run. This is why satellite and rural links with modest bandwidth show round trip times noticeably above the pure speed-of-light floor, and why TCP throughput collapses when RTT rises.
The real RTT is always larger
The two-term formula is a lower bound. Real round trip times also include store-and-forward delays at every router, queueing behind other traffic, serialisation at each hop, processing in the network stack, and the time for the receiver to generate the acknowledgement. A path that crosses 15 routers adds tens to hundreds of microseconds per hop. When measured RTT far exceeds the formula's prediction, the excess is queueing and processing — the part that congestion control and bufferbloat mitigation exist to manage.
How to Use This Calculator
The round trip relation links three quantities: RTT, Ttrans, and Tprop. Pick which one you want the tool to solve, then fill in the other two.
1. Choose what to solve for
Pick RTT, Ttrans, or Tprop from the toggle. The calculator rearranges RTT = 2 · (Ttrans + Tprop) automatically for whichever you choose.
2. Use realistic presets
Presets cover typical values: RTT from 0.2 ms on a LAN to 600 ms via GEO satellite, transmission delay from 12 µs to 60 ms, and propagation delay from 0.05 ms to 120 ms.
3. Derive the components if needed
The component builder further down the page converts packet size and link rate into Ttrans, and distance and medium into Tprop, then hands both straight to the calculator.
4. Read the result and verdict
The result card shows the round trip time in milliseconds plus the equivalent in seconds, microseconds, and the one-way delay. A colour-coded verdict classifies the path from loopback through LAN, metro, continental, transoceanic, and satellite.
5. Check the schematic and charts
The schematic shows a data packet travelling to the server and the acknowledgement coming back. The chart plots RTT against propagation delay for three transmission-delay values.
6. Switch to Advanced for depth
Advanced mode adds an RTT-versus-distance chart for three media, a sensitivity check on a +1% input change, and companion metrics including one-way delay, propagation share, and implied fibre distance.
What This Tool Offers
Built around the classic round-trip relation RTT = 2 · (Ttrans + Tprop), the fundamental link between bandwidth, distance, and network latency.
Three-way solving
Solve for round trip time, transmission delay, or propagation delay. The calculator rearranges the formula for whichever variable you choose.
Live packet schematic
A client-to-server-to-client diagram with the data packet heading out and the acknowledgement returning, both scaled in thickness with the one-way delay.
Latency-class verdict
Each result is classified from loopback through LAN, campus, metro, continental, transoceanic, intercontinental, GEO satellite, up to severe, with a coloured badge.
Multi-unit hints
Each field shows the value in related units — seconds and microseconds for RTT, implied packet size for transmission delay, and implied distance for propagation delay.
Dual comparison charts
RTT versus propagation delay for three transmission-delay values, plus an advanced RTT versus distance chart for three propagation media.
Reference tables
Typical RTT by path, propagation velocity by medium, a round-trip distance lookup grid, and a full variable reference table.
Reference Tables & Conversions
A delay component builder, a latency lookup grid, and typical values by path and medium.
Delay component builder
Time unit converter
Round-Trip Propagation Delay Lookup
Computed from RTTprop = 2 · d / v, assuming zero transmission delay. Values in ms.
| One-way distance | Fibre 2.0×10⁸ | Copper 2.3×10⁸ | Coax 2.4×10⁸ | Radio 3.0×10⁸ |
|---|
Typical RTT by Path
Representative measured round trip times. Real values include queueing, routing, and processing overhead on top of the two-term formula.
| Path | Typical distance | RTT | Notes |
|---|---|---|---|
| Loopback / same host | 0 km | < 0.05 ms | No wire; purely software stack |
| LAN switch | < 1 km | 0.1 – 0.5 ms | Sub-millisecond is the norm |
| Campus / Wi-Fi | 1 – 5 km | 1 – 5 ms | Wi-Fi adds retries and contention |
| Metro fibre | 10 – 50 km | 1 – 10 ms | Propagation floor ≈ 0.1 ms per 10 km |
| National backbone | 500 – 2,000 km | 10 – 30 ms | Multiple router hops |
| Cross-continent | ≈ 4,000 km | 40 – 70 ms | Fibre routes are longer than great circle |
| Transatlantic fibre | ≈ 6,000 km | 60 – 90 ms | London–New York ≈ 70 ms |
| Transpacific fibre | ≈ 10,000 km | 120 – 180 ms | Los Angeles–Tokyo ≈ 150 ms |
| LEO satellite | 550 km altitude | 25 – 60 ms | Includes ground segment and handover |
| MEO satellite | ≈ 20,200 km | ≈ 250 ms | Navigation-constellation geometry |
| GEO satellite | 35,786 km | 480 – 600 ms | ≈ 240 ms of pure speed-of-light round trip |
Propagation Velocity by Medium
| Medium | Velocity (m/s) | Fraction of c | Typical use |
|---|---|---|---|
| Vacuum / free space | 2.998 × 10⁸ | 1.000 | Satellite, microwave, free-space optics |
| Air (radio) | 2.997 × 10⁸ | 0.9997 | Wi-Fi, cellular, terrestrial radio |
| Coaxial cable | 2.4 × 10⁸ | 0.80 | Legacy backhaul, cable TV, DSL |
| Copper twisted pair | 2.3 × 10⁸ | 0.77 | Ethernet, DSL access |
| Single-mode fibre | 2.0 × 10⁸ | 0.67 | All long-haul and metro networks |
| Multi-mode fibre | 2.0 × 10⁸ | 0.67 | Data-centre and campus runs |
Variable Reference
| Symbol | Meaning | Typical range | Units |
|---|---|---|---|
| RTT | Round trip time | 0.05 – 600 | ms |
| Ttrans | Transmission delay, L / R | 0.001 – 100 | ms |
| Tprop | Propagation delay, d / v | 0.001 – 250 | ms |
| L | Packet length | 64 – 9,000 | bytes |
| R | Link rate (bandwidth) | 0.1 – 100,000 | Mbps |
| d | One-way link distance | 0.001 – 40,000 | km |
| v | Signal propagation velocity | 2.0 – 3.0 | ×10⁸ m/s |
| c | Speed of light in vacuum | 2.998 | ×10⁸ m/s |
What Does RTT = 2 · (Ttrans + Tprop) Measure?
The round trip relation connects three quantities that anyone working on network performance deals with constantly: the total time for a message to go out and an acknowledgement to come back (RTT), the time spent pushing bits onto the wire (Ttrans), and the time spent crossing the physical distance (Tprop). Together they describe how long a network conversation takes at the transport layer, and hence how quickly TCP can grow its window, how responsive an application feels, and how much data can be in flight at once.
Round Trip Time Formula
The defining relationship is:
with the two one-way components defined as:
Tprop = d / v (distance ÷ signal velocity)
Rearranged to solve for the other two unknowns:
Tprop = RTT / 2 − Ttrans
The quantity in brackets is the one-way delay, sometimes written as the sum of all nodal delays. In a full treatment it also includes processing and queueing at each hop:
Round Trip Time Variables
| Symbol | Meaning | Notes |
|---|---|---|
| RTT | Round trip time | Out and back; the basis of TCP's retransmission timer |
| Ttrans | Transmission delay | L / R; a bandwidth effect, reduced by faster links |
| Tprop | Propagation delay | d / v; a distance effect, fixed by physics and geography |
| Tproc | Processing delay | Time to examine the header and route the packet at each hop |
| Tqueue | Queueing delay | Waiting behind other traffic; grows sharply under congestion |
| L | Packet length | In bits for the Ttrans calculation; bytes × 8 |
| R | Link rate | Bits per second, not bytes per second |
| d | Distance | One-way physical length of the path |
| v | Propagation velocity | Depends on the medium; ≈ 2×10⁸ m/s in fibre |
How Each Variable Affects Round Trip Time
Because the relation is linear in both delays, each contributes in direct proportion to its size. Doubling the propagation delay doubles the round trip time at the same transmission delay; doubling the packet size on a fixed link rate doubles the transmission delay and therefore adds a proportional amount to the round trip. In practice the two terms have very different magnitudes: on a long-haul fibre path the propagation term dominates by two or three orders of magnitude, while on a short, slow link the transmission term can be comparable or larger.
The most useful way to think about it is that the round trip time sets the pace of every feedback loop in the network. TCP's congestion window can only grow once per round trip, so a connection with a 100 ms RTT takes five times longer to reach a given window size than one with a 20 ms RTT — which is why the same server can feel dramatically faster to a nearby user than to a distant one. This is the bandwidth-delay product effect: to keep a fat pipe full over a long path, the sender must have enough unacknowledged data in flight, and that amount is exactly the bandwidth times the round trip time.
Round Trip Time Calculation Examples
RTT = 2 × (4.000 + 20.000) = 48.000 ms
Ttrans = 48.000 / 2 − 20.000 = 4.000 ms
Tprop = 48.000 / 2 − 4.000 = 20.000 ms
Tprop = 4.0×10⁶ / 2.0×10⁸ = 0.020 s = 20.000 ms one-way, RTT floor 40.000 ms
Ttrans = (1,500 × 8) / 1×10⁸ = 0.00012 s = 0.120 ms
Frequently Asked Questions
Transmission delay is the time to push the packet's bits onto the link, Ttrans = L/R. It depends on how big the packet is and how fast the link is, and it is zero for a link that has already finished sending. Propagation delay is the time for a single bit to physically cross the link, Tprop = d/v. It depends on distance and on the speed of the signal in the medium — about 2×10⁸ m/s in fibre, which is two thirds of the speed of light in vacuum. A useful analogy: transmission delay is how long it takes to load a convoy of trucks onto the motorway; propagation delay is how long the first truck takes to drive to the destination. More lanes (bandwidth) shorten the loading time but never the driving time.
In the simple symmetric model the return path has the same transmission delay and the same propagation delay as the outbound path, so the total is twice the one-way delay. Real paths are rarely perfectly symmetric: the return route may be physically different (a different cable, a different set of routers), the acknowledgement is usually a much smaller packet than the data, and the server may take time to generate the response. When you measure RTT with a tool like ping, you are measuring the true asymmetric round trip, which is why it can differ noticeably from twice the theoretical one-way delay.
Only the transmission component, and only by a limited amount. Upgrading a link from 100 Mbps to 1 Gbps cuts Ttrans by a factor of ten, but if Ttrans was 0.12 ms out of a 48 ms round trip, the saving is about 0.11 ms — a rounding error. Propagation delay is completely unaffected by bandwidth. The one place bandwidth genuinely helps latency is under congestion: a fatter link drains its queue faster, so the queueing component of RTT shrinks. That is why a congested 10 Mbps link can show hundreds of milliseconds of RTT while an idle one shows almost none.
Because the distance is enormous. A geostationary satellite sits 35,786 km above the equator, so a signal travelling up and back down covers about 71,572 km per hop, and a full round trip through the satellite covers roughly 143,000 km. Even at the speed of light in vacuum that is about 478 ms of pure propagation delay before any processing. A transatlantic fibre path is only around 6,000 km of cable, giving roughly 60 ms. Low-Earth-orbit constellations fly at 550 km or so, which is why their round trip times — typically 25 to 60 ms — are competitive with terrestrial long-haul routes.
Throughput is capped by the window size divided by the round trip time. A sender can only have so much unacknowledged data in flight; once that window is full it must wait for an acknowledgement, which arrives one RTT later. The maximum achievable rate is therefore window ÷ RTT. A 64 kB window over a 100 ms RTT caps throughput at roughly 5 Mbps no matter how fast the underlying link is. This is why window scaling, selective acknowledgement, and modern congestion controls such as CUBIC and BBR exist — they all work to keep enough data in flight to fill the pipe despite the round trip time.
The bandwidth-delay product is the link rate multiplied by the round trip time, and it equals the amount of data that can be "in the pipe" at any instant. On a 1 Gbps path with a 100 ms RTT, the product is 100 megabits, or about 12.5 megabytes — that much data must be in flight to keep the link fully utilised. If the sender's window is smaller than the bandwidth-delay product, the link sits idle part of the time and throughput falls. This single number explains most of the difficulty in making long-distance high-bandwidth transfers run at full speed.
One second is 1,000 milliseconds, one millisecond is 1,000 microseconds, and one microsecond is 1,000 nanoseconds. So to go from milliseconds to microseconds multiply by 1,000; from microseconds to milliseconds divide by 1,000; and from milliseconds to seconds divide by 1,000. Network engineers usually quote RTT in milliseconds because the interesting range runs from a fraction of a millisecond on a LAN to a few hundred milliseconds across the planet. The time unit converter card above performs all four conversions at once.
Variables
| Symbol | Quantity | Unit |
|---|---|---|
| RTT | Round-trip time | s |
| T_trans | Transmission time (one way) | s |
| T_prop | Propagation time (one way) | s |
What it means
Round‑trip time (RTT) is a fundamental network metric that measures the duration from the moment a packet is sent until its acknowledgment is received. It includes the sum of transmission times (serialization delays) and propagation delays on both the forward and reverse paths. Propagation delay depends on the physical distance and the speed of signal (typically near the speed of light), while transmission delay is determined by packet size and link speed. In practice, RTT also includes queuing and processing delays at routers. RTT is critical for TCP performance because it dictates the minimum time for the sender to react to congestion and determines the retransmission timeout. High RTT (e.g., satellite links) reduces throughput unless the window size is increased. RTT is measured using tools like ping. Understanding its components helps diagnose network bottlenecks and design applications that are resilient to latency. The formula illustrates that both transmission and propagation contribute, and optimizing either can improve overall performance.
Worked example
Round Trip Time – Two Examples
Real‑World| Parameter | Value |
|---|---|
| T_trans (each way) | 1 ms |
| T_prop (each way) | 10 ms |
| Parameter | Value |
|---|---|
| T_trans | 0.1 ms |
| T_prop | 0.5 ms |
Common mistakes
- Factor of 2: RTT is twice the one‑way time (transmission + propagation). Do not forget the factor 2.
- Propagation delay: This depends on distance and speed of light in the medium (e.g., fibre).
- Transmission delay: Packet size divided by bandwidth – separate from propagation.
- Queuing and processing: The formula does not include queuing or processing delays, which can add to RTT.
- Variable RTT: RTT can vary due to congestion; use measured RTT for accurate values.
Applications
Round trip time (RTT) is the total time for a packet to travel to a destination and back, including both transmission and propagation delays. It is a key metric in network performance, affecting TCP throughput, user experience, and application responsiveness. Engineers use RTT to tune timers, to design congestion control algorithms (e.g., TCP Reno, BBR), and to assess the performance of cloud services. In distributed systems, RTT influences consistency protocols and load balancing decisions. Understanding the components of RTT (transmission + propagation) helps in diagnosing network issues, selecting data centre locations, and optimising content delivery networks.
- TCP timer and retransmission tuning
- Performance analysis of web and cloud services
- Design of load balancers and CDN
- Geographic distribution of servers
- Real‑time application quality assessment
Related calculators · Networking
Recently updated formulas
Suggest an improvement
Found a mistake? Have a better example? Let us know.
You may send up to 3 suggestions per 24 hours.