Latency Calculator

The formula

The speed-of-light floor is not negotiable

Light in optical glass travels at about 200,000 km/s — two thirds of its vacuum speed — so a New York to London fibre path has a hard physical minimum near 55 ms one way, no matter how much you spend on equipment. This is why high-frequency trading firms build microwave relay chains across New Jersey and Chicago: radio in air travels roughly 50% faster than light in glass, shaving milliseconds off a route where a millisecond is worth money. For everyone else the practical lever is not speed but distance — moving the workload closer to the user beats any amount of network tuning.

See also: Ping Calculator

Latency compounds in chatty protocols

A single round trip is rarely the whole story. A TCP handshake costs one round trip; establishing TLS 1.2 costs two more before any application data moves, while TLS 1.3 collapses that to one. A page making fifty sequential requests across an ocean therefore pays fifty times the RTT, not once. This is why latency reduction produces such large gains in web performance: HTTP/2 multiplexing, TLS 1.3, connection reuse, CDNs and edge rendering all work by removing round trips rather than making the wire faster. At a 120 ms RTT, every round trip you eliminate saves 120 ms of wall-clock time regardless of bandwidth.

The bandwidth-delay product explains stalled transfers

To fill a pipe you need enough data in flight to cover the round trip: BDP = bandwidth × RTT. A 1 Gbps link with a 100 ms RTT has a BDP of 12.5 MB. If the TCP window cannot grow that large — because of buffer limits, middleboxes or an old window-scaling configuration — throughput caps far below the link rate no matter how much bandwidth you bought. This is the classic "long fat network" problem and it is why a 1 Gbps connection across a continent often delivers only a few hundred megabits per second on a single stream.

Frequently asked questions

Source & methodology

Propagation physics (refractive index of silica ≈ 1.47, giving 0.67c); latency and bandwidth-delay-product models per Tanenbaum, Computer Networks and RFC 6349.

Latency explained: formula, worked example and honest limits

You are here because you need a specific number, and you want to see how it was produced before you rely on it. Searchers land on a Latency page for three reasons — to plan, to compare options, and to check that somebody else’s arithmetic is honest. This tool serves all three, and everything after the calculator explains the model instead of hiding it.

There is a habit that separates people who get useful answers from Networks & Storage numbers: they decide what question the figure answers before they compute it. Latency answers “Round-trip time (RTT)?” — and nothing else, which is precisely why the result is trustworthy.

It helps to separate the mechanics from the interpretation. The mechanics are fixed: RTT = 2 × [ (distance × route factor) ÷ (c × velocity factor) + hops × per-hop processing + packet bits ÷ link rate ]. Anyone, anywhere, entering the same inputs will get the same 75.96 ms. The interpretation is where experience counts: whether 75.96 ms is good, normal or alarming depends on comparisons covered below, and that is the part most articles about Latency never explain.

Nothing below is stock text pasted around a number: the worked example computes round-trip time (RTT) = 75.96 ms from this tool’s own defaults, and the sensitivity section ranks the inputs that move the result — One-way straight-line distance first, at ≈8.8 % of the headline for a ten-percent error either way in that input. Work down the page and by the end you could re-derive the result in a spreadsheet from memory.

How Latency is computed, line by line

Here is the complete model this tool runs — RTT = 2 × [ (distance × route factor) ÷ (c × velocity factor) + hops × per-hop processing + packet bits ÷ link rate ] — with each input explained below. If a competitor’s page gives you a different answer from the same inputs, this is the text that settles which of you is right.

One-way straight-line distance (km) (example value 4,800) is a plain measured quantity — the unit shown in the label is the unit the formula expects. Small measurement errors grow here: a length that is squared or cubed in the model magnifies a one-percent slip into a three-percent answer.

Route length factor (example value 1) is a measured number in the unit named by the label; the formula does not convert for you. Measure twice and use the unit the label asks for — length terms often scale the result geometrically.

Medium (example value Optical fibre (0.67c)) is a selector, not a measurement: the engine follows a different route for each option. If you are unsure what belongs in this field, look at the printed steps: the substitution shows exactly how the engine uses it.

Intermediate hops (routers / switches) (example value 8) is a plain measured quantity — the unit shown in the label is the unit the formula expects. This input feeds the formula directly; a defensible figure here is worth more than false precision anywhere else.

Processing time per hop (ms) (example value 1) is a quantity rather than a category — precision here is cheap and worth having. Be precise about the boundary (exact date, start of month); time inputs decide the exponent in most formulas.

Packet / frame size (KB) (example value 64) is a measured number in the unit named by the label; the formula does not convert for you. Keep every length field in the same unit; the formula assumes a consistency it cannot check for you.

Link speed (Mbps) (example value 1,000) is a quantity rather than a category — precision here is cheap and worth having. Replace the example with the figure from your own records — the tool recomputes instantly and the printed steps follow your numbers.

What each “Medium” choice actually does: Optical fibre (0.67c) → 75.96 ms · Copper / coax (0.64c) → 79.10 ms · Wireless line of sight (0.99c) → 54.33 ms — each value above is the model’s own output for that option, so the choice can be made on evidence rather than on what a category feels like it means.

See also: Jitter Calculator

A fully worked Latency example

Abstract formulas are hard to trust, so here is the complete substitution using the default inputs, written the way an examiner would want it. Starting figures: One-way straight-line distance (km), Route length factor, Medium, Intermediate hops (routers / switches). The computed round-trip time (RTT) comes out at 75.96 ms, which the interpretation band labels “37.98 ms one way across 6,720 km of fibre”.

1. Cable length = straight-line × route factor = 4,800 × 1.4 = 6,720 km.
2. Signal speed in fiber = c × 0.67 = 201 km per ms.
3. Propagation delay = 6,720 km ÷ 200.861 km/ms = 33.456 ms.
4. Hop processing = 8 × 0.5 ms = 4.000 ms.
5. Serialisation = 64.0 KB × 8 × 1024 bits ÷ (1,000 × 10⁶) = 0.5243 ms.
6. One way = 33.456 + 4.000 + 0.5243 = 37.980 ms; RTT = 75.96 ms.

One-way latency — 37.98 ms. Compare it against the main result of 75.96 ms before drawing conclusions.

Propagation component — 33.46 ms. This is the number experienced users quote when the headline alone would mislead.

Hop processing component — 4.00 ms. Read next to the headline, this is the figure that shows the shape of the trade-off.

Serialisation component — 0.524 ms. If your inputs change, this is usually the first companion figure to move.

Speed-of-light floor (vacuum) — 44.83 ms. This is the number experienced users quote when the headline alone would mislead.

Keep this worked example open while you enter your own figures: matching the shape of the substitution is the fastest way to spot a unit or convention mistake.

The Latency corridor: your result across a realistic band

The honest version of any estimate is a corridor, and this one is cheap to produce: Latency was recomputed at 5 points along the dominant input, with every other field left untouched.

That spread — 62.58 ms at the low end, 89.34 ms at the high — is what a careful read of Latency looks like: a band you can state out loud, with the reason for each edge. Reproduce it in the form above by editing One-way straight-line distance alone; the substitution steps will follow your figures exactly.

The levers behind Latency, ranked by effect

Generic advice says “it depends on your inputs”; this section says exactly how much. Each field was perturbed by ±10 % in isolation and the round-trip time (RTT) recomputed, so the ranking below is measured rather than asserted. Read it as a map of where Latency is fragile — drawn for the example inputs, which is the map you want when deciding what to measure carefully.

• One-way straight-line distance +10 % → Latency = 82.65 ms · −10 % → 69.27 ms (the round-trip time (RTT) shifts ≈8.8 %)
• Route length factor +10 % → Latency = 82.65 ms · −10 % → 69.27 ms (the round-trip time (RTT) shifts ≈8.8 %)
• Intermediate hops (routers / switches): ten percent up gives 76.76 ms, ten percent down gives 75.16 ms — ≈1.1 % of the round-trip time (RTT) either way
• Processing time per hop +10 % → Latency = 76.76 ms · −10 % → 75.16 ms (the round-trip time (RTT) shifts ≈1.1 %)
• Nudge Link speed by ±10 % and Latency lands between 75.87 ms and 76.08 ms (sensitivity ≈0.2 %)
• Packet / frame size +10 % → Latency = 76.07 ms · −10 % → 75.86 ms (the round-trip time (RTT) shifts ≈0.1 %)

One-way straight-line distance is the dominant lever here: ten percent either way moves the result by about 8.8 %, from 69.27 ms to 82.65 ms. Spend your verification effort there first, and Route length factor is effectively tied with it (≈8.8 % for the same nudge), so verify the pair together. The remaining fields can sit at safe defaults without materially changing the answer — knowing which is which is what separates a careful calculation from an anxious one.

Reading the result: bands, zones and thresholds

Nobody acts on a bare figure — they act on a figure with a comparison attached. The verdict attached to the default calculation — “37.98 ms one way across 6,720 km of fibre” — is one band on a ladder your own figure may sit somewhere else on. Before treating the band as fact, note its width: ten percent either way on One-way straight-line distance already spans 69.27 ms to 82.65 ms. The practical reading rules: read the band as a starting hypothesis, then test it: change the two dominant inputs by ten percent and see whether the verdict survives. Verdicts that survive stress are the ones worth acting on.

Where Latency sits next to similar measures: this tool answers “how much is the Latency”, while the related calculators answer “what do I do about it”. Reading the result alone tends to over-weight a single snapshot; pairing it with the companion tools above turns the number into a decision.

See also: Packet Loss Impact Calculator

Common mistakes with Latency (and the fix)

To fill a pipe you need enough data in flight to cover the round trip: BDP = bandwidth × RTT. A 1 Gbps link with a 100 ms RTT has a BDP of 12.5 MB. If the TCP window cannot grow that large — because of buffer limits, middleboxes or an old window-scaling configuration — throughput caps far below the link rate no matter how much bandwidth you bought. This is the classic "long fat network" problem and it is why a 1 Gbps connection across a continent often delivers only a few hundred megabits per second on a single stream.

Reading Latency as a promise rather than a conditional. Every number here is of the form “if these inputs, then this result”; when an input moves, the honest response is to recompute rather than to defend the old figure.

This model has its own particular trap: One-way straight-line distance carries ≈8.8 % of the response per ten percent of error, so effort spent elsewhere is largely decorative.

The subtlest error is answering the wrong question precisely. Confirm that round-trip time (RTT) is actually the quantity your decision needs — the arithmetic is flawless either way, which is what makes the mistake invisible.

A quick check for any Latency figure

• Compare the result with one independent method or published benchmark.
• State, in one sentence, which convention each rate, unit or period in the form is using.
• Put One-way straight-line distance under a magnifier; the sensitivity table above is the reason why.
• Re-run the calculation with a ±10 % stress on the two most sensitive inputs.
• Record the date and the inputs alongside the number so future-you knows what was assumed.
• Run the ±10 % stress on the top two levers and check that your conclusion survives both.

Step by step: getting a trustworthy Latency out of this tool

Using a calculator well sounds trivial, but the difference between a decision-grade figure and a throwaway one lives entirely in the routine. The routine for Latency takes a minute to learn and applies to every input above.

Step 1 — one document, one pass. Open the statement, label or record that holds one-way straight-line distance (km), route length factor, medium, intermediate hops (routers / switches), processing time per hop (ms), packet / frame size (kb) and the remaining fields listed above and transcribe straight into the form. Transcription from a single source removes the mismatch errors that appear when figures are assembled from three different places. Repeating a calculation with the same numbers proves only that the arithmetic is reliable — which is worth knowing.

Step 2 — baseline before exploration. Get one defensible Round-trip time (RTT) on screen before you start nudging numbers. Without a baseline, every variation looks interesting and none of them means anything. Numbers are cheap to produce and expensive to retract; the extra minute is the cheapest insurance available.

Step 3 — change one input at a time. Nudge a single field by ten percent, watch the headline and its companions move, then undo it. Two or three fields will dominate — the sensitivity table above already ranks them for this engine. The test of a good estimate is not that it feels right but that it changes what you do.

Step 4 — ask what would have to be true. Take the result you want and work backwards through the inputs until you find the assumption that produces it; then decide honestly whether that assumption is defensible. The point of transparency is that a reader can disagree with a specific line rather than with you.

Step 5 — schedule the next run. In Technology & Computing the inputs drift quietly. Put a reminder a quarter out, re-enter the same fields, and read the change rather than the level. If a result feels obviously right, that is the moment to check the inputs hardest.

See also: Throughput Calculator

The real-world conversations Latency settles

Most Networks & Storage disagreements are arithmetic disagreements in disguise. When Round-trip time (RTT) of 75.96 ms sits on the table with its working shown, the conversation stops being about who sounds more confident and starts being about which input is wrong. A result worth acting on survives having its two shakiest inputs halved.

Used properly this is a five-minute filter that saves weeks. Compute Latency, reject what fails, and only then bring in the expensive analysis for the survivors. Say the answer out loud before you save it; if it sounds wrong, the model did not change, your understanding did.

Treat Latency like a smoke alarm rather than a painting — its value is in being tested periodically, not in being admired once. A result worth acting on survives having its two shakiest inputs halved.

Quick answers: what searchers ask about Latency

What affects Latency the most?

Latency is driven above all by One-way straight-line distance. Perturbing only that field by ten percent either way produced 82.65 ms against the 75.96 ms baseline — a ≈8.8 % response, while Route length factor manages ≈8.8 %.

Do route length factor and one-way straight-line distance matter equally?

On these inputs, yes: the two measured within a rounding error of each other — ≈8.8 % and ≈8.8 % of the round-trip time (RTT) per ten-percent change. Treat them as one pair to verify together rather than ranking them.

How much does the “Medium” choice change the answer?

The spread is not cosmetic: this choice alone takes Latency from 54.33 ms to 79.10 ms with every other input frozen, which is more influence than most of the numeric fields on this page can claim.

What is a typical Latency?

With the example inputs on this page the result is 75.96 ms, labelled “37.98 ms one way across 6,720 km of fibre”. “Typical” varies with situation, which is why every result here ships with its verdict band and its sensitivity list: they turn one figure into a range you can locate yourself inside.

How do I calculate Latency by hand?

RTT = 2 × [ (distance × route factor) ÷ (c × velocity factor) + hops × per-hop processing + packet bits ÷ link rate ] is the entire method. Work the inputs in that order — Cable length = straight-line × route factor = 4,800 × 1.4 = 6,720 km. — and you will reach 75.96 ms on the default figures, the same number this tool prints.

What happens to Latency if one-way straight-line distance changes by 10 %?

On these inputs a ±10 % change in one-way straight-line distance takes Latency to 82.65 ms against the 75.96 ms example — around 8.8 % of the headline. The same test on every other field is in the sensitivity section.

Is the Latency result of 75.96 ms good or bad?

Good and bad are comparisons, so the honest test is three questions: where does your own Latency sit against the 75.96 ms reference above, how far would a plausible input error move it (≈8.8 % per ten percent on One-way straight-line distance), and what does the alternative option compute to?

How often should I check Latency?

Whenever an input changes by more than a few percent, and otherwise on the rhythm of your decisions — before a purchase, a review, a renewal. Latency is a snapshot, not a subscription; stale snapshots are the most common silent error in Technology & Computing planning.

Which model does Latency use?

The stated formula: RTT = 2 × [ (distance × route factor) ÷ (c × velocity factor) + hops × per-hop processing + packet bits ÷ link rate ]. It is the same arithmetic the vendor calculators and standards documents implement; differences appear only where vendors tune hidden coefficients, which the pitfall section above flags.

What is a good latency for online gaming?

Under 30 ms feels instant, 30–60 ms is fine for most games, and above 100 ms becomes noticeable in fast-paced shooters. Regional servers exist precisely because geography, not connection quality, sets the floor.

Why is my ping higher than the distance suggests?

Traffic rarely follows the shortest path. Peering agreements, transit providers and congestion route packets through exchange points that can add thousands of kilometres — two cities 300 km apart can see a 1,500 km path.

Does this Latency tool store my numbers?

No. The entire calculation runs in your browser session; nothing entered above is transmitted or saved, which is the correct behaviour for sensitive Technology & Computing figures and the reason you can re-run this page as often as you like.

What the labels on this page mean

One-way latency

37.98 ms for the Latency worked case; it sits next to the main result because it carries context the headline leaves out.

Propagation component

33.46 ms in the default Latency calculation — one of the secondary figures an experienced reader checks before trusting the primary number.

Hop processing component

4.00 ms for the Latency worked case; it sits next to the main result because it carries context the headline leaves out.

Round-trip time (RTT)

The primary output of this tool: 75.96 ms for the default inputs, computed exactly from RTT = 2 × [ (distance × route factor) ÷ (c × velocity factor) + hops × per-hop processing + packet bits ÷ link rate ].

Worked example

The step-by-step substitution printed above, so the arithmetic can be re-derived by hand or in a spreadsheet.

Verdict band

A named zone on the range of plausible results; the example inputs land in “37.98 ms one way across 6,720 km of fibre”, and your inputs may not.

Sensitivity (±10 %)

How far the Latency moves when a single input is nudged ten percent either way; the ranked list on this page is computed live from this engine.

Methodology, sources and limits

Everything above runs on one stated formula, applied without hidden coefficients: RTT = 2 × [ (distance × route factor) ÷ (c × velocity factor) + hops × per-hop processing + packet bits ÷ link rate ]. Source of record: Propagation physics (refractive index of silica ≈ 1.47, giving 0.67c); latency and bandwidth-delay-product models per Tanenbaum, Computer Networks and RFC 6349. Any other implementation of this model should return the same figure for the same inputs. If one does not, the difference is in its assumptions — which this page prints and that one probably does not.

Nothing here replaces a qualified professional, and nothing here is approximate either — the arithmetic is exact, and the honesty is in the inputs you supply. The promise to the reader is narrow and testable: same inputs, same output, no silent rounding, and no figure presented without the formula that produced it.

What to do with your Latency next

Re-run the calculation with your own figures, stress the two most sensitive inputs by ±10 %, and only then act on the result.

This page was written for people who need one trustworthy number before their next decision, and the promise is that nothing above required trust. Bookmark the tool, re-run it whenever an input moves by more than a few percent, and keep the date with the number.

See also: Network Utilization Calculator