How is propagation delay calculated?

Propagation delay is effective path distance divided by signal speed. The calculator uses the speed of light in vacuum multiplied by the selected media velocity factor.

What is serialization delay?

Serialization delay is the time needed to place packet bits onto a link. It equals packet bytes multiplied by 8, divided by link bits per second.

Is jitter the same as latency?

No. Latency is delay. Jitter, more precisely packet delay variation, is how much delay varies across packets in the same flow.

Why does RTT matter for application SLA planning?

Many applications require multiple request-response turns. A small RTT increase can multiply across authentication, TLS, database, API, and chatty application exchanges.

Network Latency Budget Calculator

Estimate one-way link delay, RTT, jitter allowance, bandwidth-delay product, and multi-turn application latency from distance, media speed, packet serialization, hop processing, queueing, and SLA assumptions.

All calculations run locally in your browser. Use the result for planning, then validate production links with real path measurements and application telemetry.

Inputs

Endpoint distance or route length (km) Use the actual cable, radio, or routed path length when known.

Path stretch over direct distance (%) Adds slack for conduit routes, metro rings, carrier paths, and non-geodesic routing.

Transmission medium

Velocity factor (fraction of c)

Bottleneck link rate (Mbps) Used for packet serialization and bandwidth-delay product.

Packet size on bottleneck link (bytes)

Serialization points Count links where a packet is transmitted at the entered bottleneck rate.

Network hops or forwarding stages

Processing per hop (ms)

Queueing and policy allowance (ms) Include QoS, shaping, firewall, encryption, and congestion allowance here.

Jitter / delay variation p95 (ms)

Jitter SLA or tolerance (ms)

Safety margin (%) Applied to the latency subtotal before comparing with the SLA.

SLA metric to compare

SLA target (ms)

Application network round trips Use 1 for a simple request-response, higher for chatty protocols.

Server/client processing budget (ms)

Optional measured RTT for comparison (ms)

Common scenarios

SLA targets

Results

SLA status-

One-way p95-

RTT p95-

SLA margin-

Latency components

Effective path distance:-

Signal speed in medium:-

One-way propagation delay:-

Packet serialization delay:-

Hop processing delay:-

Queueing and policy allowance:-

Latency before jitter and margin:-

Safety margin added:-

Application and jitter budget

Jitter / delay variation p95:-

Jitter tolerance remaining:-

Application network turns:-

Application transaction estimate:-

Bandwidth-delay product:-

Measured RTT variance:-

Planning insight

Dominant delay component:-

Theoretical one-way floor:-

Advertisement

How to use this latency budget calculator

Model the path: enter the link or route distance, then add path stretch for real carrier routing, slack loops, and non-direct paths.
Choose the medium: fiber is often modeled near 0.67c, while microwave and satellite paths are closer to free-space speed but may travel farther.
Account for packet transmission: enter packet size, bottleneck rate, and serialization points where that rate applies.
Add operational delay: include forwarding, encryption, firewall, shaping, queueing, and measured jitter allowances.
Compare to the right SLA: choose one-way, RTT, or a multi-turn application transaction depending on what the application promise measures.

Formula and assumptions

Effective path distance: distance km * (1 + path stretch % / 100)

Propagation delay: effective distance / (299,792.458 km/s * velocity factor)

Serialization delay: packet bytes * 8 / (link Mbps * 1,000,000) * serialization points

Base one-way delay: propagation + serialization + hop processing + queueing allowance

One-way p95 estimate: (base one-way + jitter p95) * (1 + safety margin % / 100)

RTT p95 estimate: one-way p95 * 2 for a symmetric path assumption.

Application transaction estimate: RTT p95 * application round trips + app processing budget

The model assumes a symmetric forward and return path for RTT. Use separate budgets for each direction when paths, QoS, access circuits, or cloud regions differ.

Typical latency planning ranges

Scenario	Main constraint	Planning note	Common SLA metric
Campus or data center interconnect	Switching and queueing	Propagation is tiny; oversubscription and buffering often dominate.	One-way or RTT p95
Metro fiber	Route length and packet treatment	Carrier ring distance can exceed map distance by a meaningful amount.	RTT p95
Cross-country WAN	Propagation floor	No tuning can beat distance; reduce application round trips where possible.	RTT p95 or transaction time
Voice or video	Delay variation	Jitter buffers smooth variation but add delay; check both latency and jitter tolerances.	One-way latency and jitter
Satellite path	Propagation distance	Orbit geometry sets a large floor even before queueing and gateway processing.	RTT p95

Latency, jitter, RTT, and application turns

Network latency is not a single source of delay. Propagation delay comes from distance and signal speed. Serialization delay comes from packet size and link rate. Processing and queueing delay come from equipment, policy, congestion, encryption, and buffering. The calculator keeps those pieces separate so the limiting component is visible.

Packet delay variation is often called jitter. It matters most for real-time media, control loops, market data, remote desktops, and any protocol that uses tight timing assumptions. A jitter buffer can mask variation, but it also increases end-to-end delay.

RTT matters because many applications are conversational. Authentication, TLS setup, database queries, file metadata lookups, and legacy client-server protocols may need several network turns. When a transaction needs five turns, every additional 20 ms of RTT can add about 100 ms before server processing is considered.

Reference notes

One-way delay terminology follows the IP Performance Metrics definition in RFC 2679 and its successor RFC 7679.
Packet delay variation follows the IPPM definition in RFC 3393, where variation is derived from differences between one-way delays.
The propagation model uses the defined speed of light in vacuum, 299,792,458 m/s, multiplied by the selected medium velocity factor.
Fiber velocity factors, forwarding delays, queueing delays, and jitter are planning assumptions. Use measured values or provider commitments when available.

Methodology

The calculator first converts the entered distance and path stretch into an effective one-way route length. It divides that length by media signal speed for the propagation floor, then adds packet serialization time, hop-level processing, queueing/policy allowance, measured or planned jitter, and a safety margin. The selected SLA metric is compared against one-way p95, symmetric RTT p95, or a multi-turn application transaction estimate.

Last reviewed: June 2026. Calculations are deterministic planning estimates and run locally in your browser.

FAQs

Can this predict real internet latency exactly?

No. It is a budget model. Real latency changes with routing, congestion, peering, cloud region placement, packet treatment, hardware queues, and asymmetric return paths.

Why is my measured RTT higher than the propagation estimate?

The propagation estimate is only the physical floor. RTT also includes return-path distance, serialization, forwarding, security inspection, queueing, radio scheduling, and endpoint processing.

Should jitter be added to one-way latency?

For p95 or worst-case planning, yes, add a measured or agreed delay-variation allowance. For minimum latency planning, look at the propagation and serialization floor separately.

What velocity factor should I use for fiber?

A common planning estimate is about 0.67 times the speed of light in vacuum. Use the cable or carrier value if it is known.

Is this calculator private?

Yes. Inputs are processed locally and are not submitted to a backend.

Disclaimer

This tool is an infrastructure planning aid, not a carrier SLA certification or application performance guarantee. Validate production designs with provider contracts, device telemetry, packet captures, active probes, and application-level measurements.