SyncE Explained: The Clock Hidden in the Ethernet Cable

The metronome was inside the cable all along

Think of an orchestra whose musicians sit in different buildings. To stay in time they need two different things: a shared tempo — everyone counting at exactly the same speed — and a shared downbeat — everyone agreeing which beat is "now". Most timing articles are about the downbeat. This one is about the tempo, and about a surprising place it hides: inside the Ethernet cable itself.

Ethernet looks digital and abstract, but physically it is a stream of signals sent at a rate set by the transmitter's clock. When a switch sends bits at 10 gigabits per second, "10 gigabits" is not a wish — it is that switch's oscillator, ticking. SyncE (Synchronous Ethernet) is the set of standards that lets a receiver recover that clock from the incoming signal and use it as its own timing reference — the way a musician can fall into step just by listening to a steady drumbeat through the wall. No timing packets need to be sent. The beat arrives with the music.

How SyncE actually works, step by step

Start at the top. Somewhere in the network sits a primary reference clock — typically disciplined by GNSS (the satellite systems behind GPS) and built to telecom grade. A SyncE device connected to it does something an ordinary Ethernet device never does: instead of running its ports from its own local oscillator, it extracts the clock from the incoming bit stream on the reference-facing port and disciplines its internal EEC to match. Its outgoing ports then transmit using that same recovered tempo. The next device down the chain does the same. Hop by hop, the reference's tick rate propagates across the whole network at the speed of the links themselves.

Two properties make engineers trust this more than packet-based timing for frequency. First, because the timing lives at the physical layer, it is immune to the things that corrupt packets: a congested queue can delay a PTP message, but it cannot delay the rate at which bits physically arrive. Second, it is continuous — the receiver is locked to the incoming stream every instant, not sampling a timestamp every second or two and steering between samples.

The standards split the job three ways. ITU-T G.8261 defines the overall architecture and how much timing noise (wander) a network may add. ITU-T G.8262 specifies the EEC — the clock inside each device: how accurately it must follow, how much noise it may generate, and how it behaves in holdover. ITU-T G.8264 defines ESMC, the messaging that keeps the chain organised, covered next.

Frequency is not time: the limit you must not forget

SyncE's great strength is also its hard limit. It synchronises rate, nothing else. Two SyncE-locked devices tick at exactly the same speed, but SyncE says nothing about whether their ticks happen at the same instant, and it carries no time of day at all — there is no "it is now 14:03:22.123456789" anywhere in the mechanism.

Why the rate alone still matters: a clock whose frequency is off by just 1 part per million (1 ppm — one tick in a million wrong) drifts away from true time by about 86 milliseconds every day if nothing corrects it. Mobile networks feel this first: base stations transmitting on shared spectrum must hold their carriers to within a few tens of parts per billion, or neighbouring cells interfere. Trading systems, power grids and 5G radios all share the same shape of problem — first make every clock tick at the right speed, then argue about what time it is.

That second job belongs to PTP (Precision Time Protocol), which exchanges timestamped packets to set phase and time of day — see our NTP vs PTP guide for how that message exchange works. The division of labour in serious designs is:

SyncE delivers the tempo, physically, immune to packet delay. PTP delivers the downbeat and the clock reading, in packets, on top of equipment whose oscillators are already running at exactly the right speed. Engineers call that combination hybrid mode, and it is the standard pattern in telecom and increasingly in financial timing.

ESMC and quality levels: how the chain organises itself

A chain needs rules, or it tangles. What if a device can hear two candidate references, one excellent and one poor? What if a cable is rearranged so two devices end up following each other in a circle — a timing loop, where both drift together, each convinced the other is the reference? SyncE answers with ESMC.

Every SyncE port sends ESMC messages at a steady heartbeat of about one per second, and immediately when something changes. Each message carries a quality level (QL) — a short code, inherited from the older SONET/SDH world, grading the clock that ultimately stands behind that port:

With those grades arriving on every port, selection becomes mechanical: follow the best quality level you can hear, break ties by configured priority, and never follow a port marked DNU. The DNU rule is the loop-breaker — a device marks its reference-facing direction "do not use" downstream, so a downstream device can never offer timing back up the chain and close a circle. And when a reference fails, the QL on its ports drops, ESMC announces the change at once rather than waiting for the next heartbeat, and every device below re-selects the best source it has left — or falls back on its own oscillator in holdover, now coasting at the last good tempo it learned.

Why PTP works measurably better on top of SyncE

PTP's job is to steer a local clock until its phase and time match the grandmaster. Steering is easy when the oscillator already ticks at the right rate: the servo (the control loop doing the steering) only has to nudge phase, a quantity that then stays put. Steering is hard when the oscillator also runs fast or slow: phase corrections keep unravelling between messages, and every congested or asymmetric packet path adds noise the servo cannot distinguish from real drift.

Hybrid mode removes the second problem. With SyncE underneath, the PTP servo inherits a frequency-locked oscillator, so its corrections hold, its filters can average over longer windows, and the delivered time is steadier — especially across long chains of boundary clocks, where small per-hop errors otherwise accumulate. The same lock improves the bad days too: when PTP's grandmaster or path fails, a SyncE-locked device in holdover keeps ticking at a disciplined rate instead of free-running wherever its crystal happens to sit — the difference our PTP holdover guide quantifies oscillator by oscillator. At the extreme end, White Rabbit builds directly on this pattern: SyncE for frequency, an enhanced PTP for phase, and extra phase measurement hardware to reach sub-nanosecond agreement.

A worked picture: a colocation timing chain runs PRC, then two SyncE switches, then a PTP boundary clock serving trading servers. If the PTP path breaks, the boundary clock still receives SyncE frequency from the second switch, so its time coasts slowly and predictably rather than wandering. Remove SyncE from just the second switch — replace it with an ordinary switch — and two things break at once: the boundary clock loses its frequency reference, and traceability ends, because that switch transmits from its own crystal and whatever it passes on is its guess, not the PRC's tempo.

Five SyncE mistakes that quietly ruin a timing design

1. Expecting time of day from SyncE. It cannot provide it. If an audit asks "what time does this device think it is", SyncE is never the answer — PTP or NTP must be running too.

2. Leaving one non-SyncE hop in the chain. The design drawing shows a clean chain; the rack contains one legacy switch. Everything below that hop is free-running while dashboards still show the top of the chain locked. Verify every hop, not the endpoints.

3. Disabling ESMC to "keep it simple". Without quality levels, devices cannot grade sources, re-selection after a failure becomes guesswork, and the DNU protection against timing loops is gone.

4. Chasing the best QL across a rearranged network. After maintenance, a device may legitimately re-select a different source. If your monitoring alarms on the source name rather than the quality level and lock state, you will page people for the system working as designed.

5. Assuming SyncE fixes a bad PTP path. Hybrid mode steadies frequency; it does nothing for packet-path asymmetry, which still biases PTP's delay calculation. Both layers need engineering — budget the PTP side properly rather than trusting the lock.