Timing & Sync — how long does it take, and how do clocks stay together?
A dark-fiber link is not instantaneous. Light takes real, predictable time to cross it, and for some customers that delay is the whole product. Other customers do not care about raw delay but need every device on their network to agree on frequency and time. This page covers both: the physics of latency, and how a transport network carries synchronization without wrecking it.
Latency asks "how long does one bit take to get there?" It is set mostly by fiber length and by the fixed processing delay of the electronics. Synchronization asks "do both ends agree on frequency and on the time of day?" A link can have tiny latency and still deliver terrible sync, or long latency and perfect sync — they are independent properties, engineered separately.
Part 1 — Latency: the speed of light in glass
Light in a vacuum travels at c ≈ 300,000 km/s. Inside a fiber it is slower, because the glass has a refractive index n ≈ 1.47. The signal travels at c / n, which works out to a number worth memorizing:
That "1 ms per 100 km round trip" figure is the fastest a signal can possibly complete a request-and-response over that distance. No equipment can beat it — it is physics. Everything else (transponders, FEC, switching) only adds to it.
Think of the fiber as a very long, very fast pneumatic tube. The length of the tube fixes the minimum trip time; you cannot make the capsule travel faster than c/n. If a customer needs a shorter delay, the only physical lever is a shorter or more direct fiber route — fewer kilometres of glass. Every other component you add can only make it slower.
Worked round-trip examples
| Route length (one way) | One-way fiber delay | Round-trip (RTT) fiber delay |
|---|---|---|
| 10 km | ~49 µs | ~0.10 ms |
| 100 km | ~490 µs | ~1.0 ms |
| 300 km | ~1.47 ms | ~2.9 ms |
| 1000 km | ~4.9 ms | ~9.8 ms |
These are fiber-only numbers. The physical route is almost always longer than the map distance ("as the cable runs, not as the crow flies"), so real latency runs a bit higher than a straight-line calculation suggests.
What the equipment adds on top of the fiber
Transponders, regenerators, muxponders and especially FEC (Forward Error Correction) each add a small, fixed processing delay every time the signal is decoded and re-encoded:
FEC delay
Strong error correction has to buffer a block of bits before it can correct them, and that buffering is delay. SD-FEC (soft-decision) adds more latency than HD-FEC (hard-decision) because it does more work on a larger block. Some products offer a low-latency FEC mode that trades some coding gain (reach) for reduced delay — a deliberate choice when latency is the priority.
Regen / transponder delay
Every 3R regenerator and every transponder hop adds its own fixed processing time. A chain of regens on a long route accumulates these fixed delays. They are small compared to the fiber on a long span, but on a short latency-critical route they can matter.
A diverse protection route is chosen to be physically separate from the working route — which almost always means it is longer. So when a protection switch fires, latency can jump. If a customer bought a link for its low latency, a protection event may push delay outside their budget even though traffic is technically still flowing. Engineer and disclose the protection-path latency, not just the working-path latency.
Who actually pays for latency
Finance / HFT
High-frequency trading pays for the shortest, lowest-latency path between venues — microseconds are money. Finance also has a separate regulatory need: accurately timestamping trades (see synchronization below).
Storage replication
Synchronous replication waits for the far end to acknowledge every write, so it is directly latency-bound. Beyond a practical distance the wait becomes unacceptable and you must switch to asynchronous replication.
Mobile fronthaul
The link between a radio and its baseband (CPRI / eCPRI) has very tight latency budgets. Exceed them and the radio protocol breaks. Fronthaul also needs tight phase sync (below).
Because synchronous replication blocks on every acknowledgement, application latency rises with distance. As a practical rule of thumb, synchronous replication is limited to roughly 100–200 km (a few milliseconds RTT). Beyond that the per-write wait slows the application unacceptably, and the design moves to asynchronous replication (which does not block on the far end but risks a small amount of un-replicated data if the site is lost). The exact cutoff depends on the application's tolerance — verify with the storage vendor.
An end-to-end latency budget
Add up the pieces the way you would for power or OSNR — fiber first, then every fixed contributor:
The takeaway: on a long route, the fiber length is the budget and equipment is a rounding error. On a short metro route the opposite is true — the fixed per-card delays dominate, and a low-latency FEC mode or one fewer regen hop can be the difference.
Part 2 — Synchronization: frequency vs phase/time
Synchronization is about clocks agreeing. There are two distinct kinds, and they are not the same thing:
Frequency sync ("syntonization")
All clocks tick at the same rate — the same number of ticks per second — even if they disagree on what time it actually is. Analogy: two metronomes beating at exactly the same tempo, but not necessarily on the same beat. This is what keeps bit streams from slipping.
Phase / time sync
All clocks agree on the same instant — the same time of day, aligned to within a tiny tolerance. Analogy: two metronomes not only at the same tempo but striking on exactly the same beat. This is what TDD radios and timestamping need.
Two technologies: SyncE and PTP
Transport networks carry these two kinds of sync with two different mechanisms:
| SyncE (Synchronous Ethernet) | PTP / IEEE 1588v2 | |
|---|---|---|
| Delivers | Frequency sync only | Phase / time-of-day sync (and frequency) |
| How it works | Recovers a clock from the physical-layer line bit-rate — the Ethernet signal itself carries the frequency | Exchanges timestamped packets and measures their delay to align time |
| Key standard | ITU-T G.8262 | ITU-T telecom profiles G.8275.1 (full on-path support) / G.8275.2 (partial support) |
| Quality signalling | Carries an SSM / ESMC quality level so nodes pick the best clock source | Best-master selection via the profile's algorithm |
| Sensitive to path asymmetry? | No — frequency only cares about rate | Yes — unequal forward/return delay directly causes phase error |
SyncE and PTP are complementary, not competitors. A common design uses SyncE to deliver a rock-steady frequency and PTP to deliver phase/time on top of it. SyncE keeps the frequency clean even if PTP packets are momentarily disturbed.
Boundary and transparent clocks
Left alone, every switch a PTP packet crosses adds a little variable queuing delay, which corrupts the time estimate. Two device behaviours fix this:
Boundary clock (BC)
The node recovers time from upstream and re-serves it downstream as a fresh master. It terminates the timing on each hop, so accumulated packet-delay variation does not pile up across the chain.
Transparent clock (TC)
The node measures how long each PTP packet actually spent inside it and writes that residence time into the packet (a correction field), so the receiver can subtract it out. It makes the switch's own delay "transparent."
Both reduce timing error. Full on-path support (G.8275.1) assumes every node is a BC or TC; partial support (G.8275.2) tolerates some nodes that are not timing-aware, at the cost of accuracy.
The ultimate source: GNSS and the PRTC
Phase/time sync has to start from a source that actually knows the correct time. That source is a PRTC (Primary Reference Time Clock), usually locked to GNSS (GPS/Galileo/etc.) satellites, defined in ITU-T G.8272. The grandmaster distributes this reference into the PTP network. If GNSS is lost, the PRTC holds over on its internal oscillator, slowly drifting — which is why holdover quality matters.
PTP estimates time by assuming the forward and return paths have equal delay. It measures the round trip and splits it in half. If the forward and return directions are not equal — different fiber lengths, different amplifier or dispersion-compensation delays, an asymmetric protection route — then that split is wrong, and the error goes directly into the phase offset. A rule of thumb: an asymmetry of Δ nanoseconds of round-trip delay difference produces roughly Δ/2 of phase error. This is why transport for phase sync must be symmetric, or the asymmetry must be measured and compensated. Frequency sync (SyncE) does not have this problem — only phase/time sync does.
What the transport network must do to preserve timing
- Carry SyncE transparently, preserving the physical-layer clock and passing the SSM/ESMC quality level so downstream nodes select the best source.
- Support PTP as boundary or transparent clocks where accuracy demands it, per the chosen G.8275.1/.2 profile.
- Keep forward and return paths symmetric, or measure and compensate any known asymmetry (fiber length difference, one-way amplification, dispersion compensation on one side only).
- Ensure regenerators and muxponders preserve or regenerate timing rather than breaking the recovered clock — a device that terminates the line must re-serve sync.
- Account for protection switches: a switch to a longer/asymmetric path can disturb phase — decide whether that is acceptable or must be compensated.
1. A dark-fiber route is 250 km of actual cable. Estimate the one-way and round-trip fiber propagation delay.
2. A customer wants synchronous storage replication between sites 400 km apart. Any concern?
3. Which kind of sync does a mobile TDD radio need, and which technology delivers it?
4. The forward and return fibers on a PTP-carrying link differ in length. Which sync suffers, and roughly how much?
5. A link is engineered right at a customer's latency limit on the working path. Why is that risky?
6. Why do SyncE and PTP often run together rather than one instead of the other?