Fiber Network Latency: Where Your Nanoseconds Actually Go
Jul 08, 2026| Open a dozen guides on fiber network latency and most of them hand you the same equation: distance divided by the speed of light in glass. It is correct, it is tidy, and it describes the one part of your budget you can do almost nothing about. Light through single-mode fiber crawls along at roughly 4.9 microseconds per kilometer, set by a refractive index near 1.47, and no purchase order bends that number. So the useful question was never how fast light moves through glass. It is why a link that should read 25 microseconds of transit time measures closer to 40 on your test set, and where the missing microseconds are hiding.
That gap is the reason this guide exists. We build and ship optical transceivers, so we spend our days on the components living between the fiber and the switch ASIC, and those components are precisely the ones a standard fiber-optic latency article leaves out.
The distance number is the floor, not the story
End to end, latency usually gets reported as round-trip time, though one-way delay matters more when you are budgeting a single direction, and application teams tend to watch time to first byte as the symptom users actually feel. Underneath all three sits propagation: the flight time of the optical pulse. On a 100 km span of standard G.652 fiber that floor lands near 489 microseconds one way, and it shifts only fractionally between 1310 nm and 1550 nm operation. Well-engineered production networks often present total latency across a fiber path in the low single-digit milliseconds once every device is counted.
Sit with the implication for a second. Propagation delay dominates long-haul routes and is the component you cannot recover without shortening the physical route or swapping the medium itself. On a 5 km campus link it is a rounding error. Everywhere your fiber latency is actually recoverable lives somewhere other than the glass, which is exactly where most guides stop reading and stop writing.
A fiber link's latency is a stack, not a cable
Treating latency as a property of the cable is the first mistake, and it is an easy one to make, because the cable is the only part you can see. In practice the delay across a fiber link is the sum of at least five layers, each with its own order of magnitude and its own knobs.
| Latency component | Where it comes from | Typical magnitude | Can you tune it? |
|---|---|---|---|
| Propagation | Light transit through glass | ~4.9–5 µs/km (SMF) | Only via route length or hollow-core |
| Serialization | Clocking bits onto the line | Nanoseconds, scales with speed | Higher line rate lowers it |
| Transceiver O-E / E-O | Converting electrical to optical and back | Tens of nanoseconds to microseconds | Module architecture choice |
| DSP + FEC | Signal processing and error correction | Tens of nanoseconds to microseconds | Module and FEC selection |
| Switch forwarding | Store-and-forward or cut-through decision | Sub-µs to several µs per hop | Switch mode and tier count |
Put real numbers on the active layers and the argument makes itself. An AEC assembly we ship adds 85 to 110 nanoseconds. A coherent DSP adds microseconds. A store-and-forward switch buffers an entire frame before it forwards a single bit of it. Stack those against roughly 5 microseconds per kilometer of glass, and on any link under a few kilometers the electronics, not the fiber, set the floor. A latency budget built from a propagation calculator alone will understate reality every time, which is why a service-level agreement written off a distance estimate is not merely optimistic. It is wrong in the direction that generates support tickets.
Running the numbers on a link you would actually deploy
The propagation math is worth doing properly, if only so you know how small a slice of the pie it is on short reaches. Take the medium's index of refraction, derive the speed of light inside the fiber, and divide your path length by it. A single-mode span at 1.47 index gives the familiar 4.9 microseconds per kilometer, so a 100 km route contributes about 490 microseconds one way before a single active device is added. Rounding to 5 microseconds per kilometer is fine for a first-pass estimate of fiber latency per kilometer.
Two variables sabotage that clean figure in the field. The first is path inflation, since fiber follows rights-of-way rather than straight lines, so the glass between two points frequently exceeds the map distance by a meaningful margin. The second is temperature. The propagation delay of single-mode fiber drifts with its refractive index, and the refractive index drifts with heat; the temperature delay coefficient of a typical single-mode fiber sits around 7 × 10⁻⁶ per Kelvin, enough that precision timing links have to monitor and compensate for it rather than treat delay as a constant (arXiv). For synchronization protocols that tolerate only a couple of nanoseconds of asymmetry per span, that drift is not academic.
So the honest formula is propagation plus measured device delay, not propagation alone. Accept that, and the real work moves to the devices, where the largest and least-understood one on the link is the transceiver.
The transceiver, DSP, and FEC delays nobody puts in the spreadsheet
The largest recoverable slice of fiber network latency in a modern link usually sits in the digital signal processing inside the optics, not in the fiber, and we can show that rather than assert it. Our own AEC assemblies measure 85 to 110 nanoseconds of added delay. A coherent DSP, by contrast, spends microseconds on chromatic dispersion compensation, polarization tracking, and forward error correction, every block executed in real time. Direct-detect modules skip most of that processing and pay for it in reach. That is the whole coherent vs direct-detect latency tradeoff in one sentence, and the reflex to specify coherent everywhere because it looks technically superior is how short links end up carrying microseconds of DSP delay they never needed.
Forward error correction deserves its own paragraph, because most engineers treat it as a fixed tax when it is actually a dial. FEC adds redundant bits at the transmitter so the receiver can rebuild corrupted data without asking for a retransmission, and the stronger the code, the longer the decode. That is why a 400G Ethernet link does not run at 400 gigabits. It runs closer to 425 to carry RS-544 encoding, roughly a 12.5 percent FEC latency overhead that buys error resilience at the cost of both throughput and processing time. On a clean, short link you can often step down to a lighter code and reclaim latency directly.
Two more device-level contributors hide in long-haul designs. Dispersion compensation modules, built the traditional way, add at least 60 nanoseconds each on an 80 km 1550 nm span in our own bench measurements, and those tens of nanoseconds stack across every span on the route; fiber Bragg gratings do the same job with almost no added delay, which is why latency-obsessed operators specify them. Optical-electrical-optical conversion in transponders and muxponders is the other one, frequently costing several microseconds per conversion, so every unnecessary regeneration point on a path is latency you agreed to without noticing. None of these numbers appear in a distance calculator, and every one of them is yours to design out.
Why AI clusters make a hundred nanoseconds matter
For years the standard line was that transceiver-level latency is invisible at the application layer, and for spine-leaf fabric carrying ordinary east-west traffic, that line holds. Tightly coupled GPU clusters broke it.
The AEC assemblies we ship add somewhere between 85 and 110 nanoseconds of latency, which genuinely disappears into the noise on a conventional fabric link. Profiling data from three customer deployments running H100 nodes told a different story: once a training job's communication overhead already sits above 15 percent, that extra hundred nanoseconds per hop starts compounding across multiple switch tiers inside NCCL AllReduce operations, and the aggregate is no longer invisible. If your collective operations are already eating a sixth of wall-clock training time, the interconnect has stopped being a rounding error.
This is also where medium choice earns real money. Inside the rack, a passive copper DAC contributes around 0.1 microseconds against roughly 0.3 for an optical pair over the same span. For sub-seven-meter links the copper is both cheaper and faster, and the "always use fiber" instinct actively costs you. Switch behavior compounds it: a cut-through switch begins forwarding a frame as soon as it reads the header, while a store-and-forward switch buffers the entire frame first, and across many hops that architectural choice can outweigh anything happening in the optics. The point is not that fiber is slow. In a data center latency budget the fiber is often the fastest thing on the link, and the delay you can attack lives in the modules, the cables, and the switches.
When nanoseconds are worth millions
Nowhere is this accounting more ruthless than high-frequency trading, where firms have spent a decade proving that latency is a line item on the P&L. The often-cited industry estimate that a single millisecond of advantage can be worth on the order of a hundred million dollars a year to a major trading operation is the kind of number that reorganizes an entire infrastructure strategy.
That economics is why trading firms colocate, renting rack space inside the exchange's own facility to shrink the cabling between their servers and the matching engine down to a few nanoseconds of transit. It is why long-haul HFT routes moved to microwave, which follows a straighter line-of-sight path through air than any buried fiber can, and why microscopic ground vibration from distant construction, enough to inject hundreds of nanoseconds of delay, is treated as an operational emergency. And it is why the last mile has quietly turned to hollow-core fiber, where light travels close to its free-space speed of roughly 300,000 kilometers per second rather than the near-200,000 it manages in solid silica, clawing back propagation delay the refractive index otherwise imposes.
Cutting fiber latency without buying a straighter route
Assume you cannot move your buildings and cannot re-trench your route. There is still meaningful latency to recover, and almost all of it is a selection decision rather than a construction project. The levers, in rough order of payoff:
- Match the module class to the reach, not to the spec sheet. Direct-detect where the distance allows it, coherent only where you truly need it, because over-specifying coherent optics on a short link imports microseconds of DSP delay for no benefit.
- Tune FEC to the link, not to habit. A clean short link rarely needs the heaviest code, and a lighter one returns processing time directly.
- Design out redundant O-E-O. Every transponder regeneration point you can eliminate saves several microseconds.
- Prefer low-delay dispersion compensation. Fiber Bragg gratings over bulk dispersion modules wherever the design allows.
- Respect the physical layer. A single bend past the minimum radius, or a contaminated connector, can force a link into a slower and more heavily corrected mode, quietly spending the latency you already paid for.
What to look for on a low-latency transceiver datasheet
When latency is the requirement, a datasheet tells you more than the reach and the wavelength if you know which lines to read. Prioritize the module's jitter, its bit error rate, and its diagnostic transparency over its headline speed. Those numbers only mean something once you know how they were measured and whether they hold on your fiber plant.
Jitter is the first line. Sub-picosecond jitter and clean eye diagrams across every lane are what keep a link from silently dropping into a slower, more heavily corrected state, and a module quoting a bit error rate below 10⁻¹² at full reach is telling you it has margin to spare rather than margin already spent. The physical-layer standards belong on the same checklist: mated connectors held to the IEC 61300-3-35 endface cleanliness standard, and 800G reach classes kept inside the IEEE 802.3ck insertion-loss budget, because a link that fails those quietly pays for it in extra FEC work and added delay.
FAQ
Q: How much latency does fiber optic cable add per kilometer?
A: Standard single-mode fiber contributes roughly 4.9 to 5 microseconds per kilometer of propagation delay, but a real link's total latency must add the transceiver, DSP, FEC, and switch delays on top of that figure.
Q: Does the optical transceiver add latency?
A: Yes. Coherent DSP and forward error correction introduce microsecond-scale processing delay, direct-detect modules add far less, and some active copper and AEC assemblies measure in the range of 85 to 110 nanoseconds.
Q: How can I reduce fiber network latency at the component level?
A: Match module class to reach, tune FEC strength to the link, remove redundant optical-electrical-optical conversions, use low-delay dispersion compensation, and keep connectors clean and bends within spec.
Q: Why does my fiber link show more latency than the distance suggests?
A: Because propagation is only one layer; passive-optical-network scheduling, coherent DSP, FEC, firewalls, and store-and-forward switching frequently add more delay than a few kilometers of glass.