Skip to content
Calixo

Fiber Optic Latency Calculator

Estimate the one-way propagation delay of a fiber optic link from its distance — the hard physical floor on latency that no network optimization can beat.

Inputs

Paste this into any page — the widget stays live and updates automatically as this calculator improves. Using WordPress or Notion? See the embed guide.

Saved Scenarios

— select 2+ to compare
Inputs updated · Results recalculated · Just now

One-Way Delay (ms)

5.000

Round-Trip Delay (ms)

10.000

Spark says

How it's calculated
Closeup of rows of tiny round white electrical connectors and long thin blue wires in data center
Photo by Brett Sayles on Pexels
Detailed image of a server rack with glowing lights in a modern data center.
Photo by panumas nikhomkhai on Pexels

Formula

Delayms=Distancekm200,000×1000Delay_{ms} = \dfrac{Distance_{km}}{200{,}000} \times 1000
200{,}000
— Approximate speed of light in fiber, in km/s (about 2/3 of light speed in vacuum)

What is the Fiber Optic Latency Calculator?

Light travels slower through fiber optic glass than through a vacuum — about 200,000 km/s due to the fiber's refractive index — setting a hard physical floor on latency that no amount of bandwidth or hardware can beat.

Use this when estimating the minimum possible latency to a distant server or data center before committing to an architecture decision, explaining to a stakeholder why a request to a far-away region will always have a latency floor, or sanity-checking whether a measured latency figure is close to or far from the physical minimum.

How to use it

  1. 1 Enter the physical distance the fiber link covers.

Understanding Fiber Optic Latency Calculator

Light travels at its maximum, universally famous speed only in a vacuum — roughly 300,000 kilometers per second. Inside fiber optic glass, light travels meaningfully slower, at roughly two-thirds that speed (around 200,000 km/s), because of a fundamental optical property of the glass called its refractive index, which describes how much a material slows down and bends light passing through it. This isn't a limitation of current fiber technology that better engineering could someday fix — it's a fundamental physical property of how light interacts with the glass medium itself, meaning this speed reduction represents a genuine, permanent physical constant for fiber optic communication, not an engineering target to be optimized away.

This physical constant creates something genuinely useful to understand in network architecture and performance discussions: an absolute floor on latency for any connection covering a given physical distance, below which no amount of bandwidth improvement, better hardware, or software optimization can push the connection, no matter how much money or engineering effort is applied. A request from New York to Tokyo, for instance, has to travel a physical distance that takes light in fiber a certain minimum number of milliseconds to cross — faster processors, better routing algorithms, and higher bandwidth links can reduce every other source of delay in that journey, but none of them can make light travel faster than the fiber's refractive index allows. This is precisely why latency-sensitive applications with a global user base — real-time gaming, video conferencing, financial trading systems — treat physical server placement (having infrastructure genuinely close to users, not just well-engineered infrastructure far away) as an irreducible requirement rather than an optimization nice-to-have; no software fix substitutes for physical proximity when propagation delay is the binding constraint.

It's important to understand this calculator's result as a floor, not a full prediction of real-world latency, because propagation delay is only one component of the total latency a real network connection experiences. Every router or switch a signal passes through along its route adds its own processing and queuing delay — examining the packet, deciding where to forward it, potentially waiting in a queue if the device is busy — and on a long-haul internet route involving many intermediate hops across different networks and providers, this cumulative switching delay frequently exceeds the pure propagation delay from the fiber itself, especially over shorter distances where the propagation component is already small. Real fiber routes also rarely follow the geographically shortest straight-line path between two points — undersea cables, terrestrial fiber runs, and metro connections all follow existing infrastructure corridors (coastlines, highway rights-of-way, existing conduit) that are practical and economical to build along, rather than a theoretically optimal straight line, which adds real additional distance (and therefore real additional propagation delay) beyond the straight-line calculation this tool performs.

Despite these real-world additions, the pure propagation-delay floor remains a genuinely useful reference point precisely because it's the one component of latency that's fixed and non-negotiable — every other source of delay (routing efficiency, hardware processing time, network congestion) is at least theoretically improvable through better engineering, while propagation delay for a fixed distance is not. Comparing a measured real-world latency figure against this theoretical floor gives a useful sense of how much 'engineering overhead' versus unavoidable physics is actually contributing to an observed connection's total latency.

Worked examples

Advantages

  • Grounds latency expectations in real physics rather than vague assumptions about network speed.
  • Useful for architecture decisions involving geographically distributed systems.
  • Simple single-input calculation based on a well-established physical constant.
  • Helps distinguish unavoidable propagation delay from optimizable routing and processing delay.

Limitations

  • This is propagation delay only — real-world latency also includes switching/routing delay at each hop, which typically adds more than the fiber itself over long-haul routes with many hops.
  • Assumes a straight-line fiber path, when real fiber routes typically follow existing infrastructure corridors (highways, coastlines, existing conduit) rather than the geographically shortest path between two points.

Common mistakes

  • ⚠️ Treating this calculator's result as the actual expected latency for a real network connection, when actual latency is always higher due to routing overhead, switching delay, and the fact that real fiber routes aren't perfectly straight lines.
  • ⚠️ Assuming latency can be reduced indefinitely through better hardware or software optimization, when propagation delay represents a genuine physical floor that no amount of engineering can overcome for a fixed distance.
  • ⚠️ Comparing measured real-world latency directly against this theoretical minimum without accounting for the number of network hops involved, which typically contributes more delay than the fiber itself on a long-haul route.

Tips

  • 💡 Use this calculator's result as a floor, not a prediction — real-world latency to a given distance will always be at least this much, typically several times more once routing and switching delay are included.
  • 💡 For architecture decisions involving geographically distributed users or servers, remember that no amount of bandwidth or hardware improvement can reduce latency below this physical propagation floor for a fixed distance.
  • 💡 When comparing cloud regions or CDN edge locations, use straight-line distance to this calculator as a rough first estimate of the latency floor, understanding actual measured latency will be higher.
  • 💡 For applications sensitive to latency (real-time gaming, video calls, high-frequency trading), physical proximity to users remains the only way to reduce this specific latency component, since it can't be engineered away.

Real-life uses

  • Estimating the minimum possible latency to a distant server or data center
  • Explaining why a request to a geographically distant region has an inherent latency floor
  • Sanity-checking whether measured latency is close to or far from the physical minimum
  • Informing architecture decisions about server or CDN placement for latency-sensitive applications

Frequently asked questions

Why is latency to a distant server always at least this much?

This is the physical speed-of-light floor for that distance — no network optimization can go faster, only closer to this theoretical minimum by adding fewer hops and more direct routes.

Why does light travel slower in fiber than in a vacuum?

Fiber optic glass has a refractive index that physically slows and bends light passing through it — this is a fundamental optical property of the glass medium, not an engineering limitation that can be improved away.

Can better hardware or more bandwidth reduce propagation delay?

No — propagation delay is set purely by physical distance and the speed of light in fiber, both fixed quantities for a given route; bandwidth and hardware improvements can reduce other latency sources but not this specific one.

Why is real-world latency usually higher than this calculator's result?

Real connections add processing and queuing delay at every router or switch hop along the route, and real fiber paths follow practical infrastructure corridors rather than a perfectly straight geographic line — both add delay beyond pure propagation.

Why do latency-sensitive applications need servers physically close to users?

Because propagation delay is the one latency component that can't be engineered away — for applications like real-time gaming or trading where every millisecond matters, physical proximity is the only way to reduce this specific, unavoidable source of delay.