White Rabbit keeps sub-nanosecond time by separating frequency, phase, and delay

Engineers test White Rabbit switches and optical links at CERN in June 2020. The bench makes the architecture's physical dependency visible: timing quality comes from measured hardware and fiber, not from packets alone. Photograph by Piotr Traczyk/CERN.[10]

For most software, a clock is a service somewhere below the application. For a particle detector, radio telescope, power system, or distributed measurement rig, time is part of the instrument. If two sensors disagree about when a signal arrived, their otherwise correct samples may not describe the same event.

White Rabbit is an open-source extension of Ethernet timing built for that harder problem. Its headline is synchronization with sub-nanosecond accuracy, but the more useful engineering idea is how it divides the work. Synchronous Ethernet makes clocks run at the same rate. Precision Time Protocol establishes the clock hierarchy and exchanges time. Hardware phase measurement resolves fractions of a clock cycle. Calibration accounts for unequal delays through boards, transceivers, and fiber. Remove any one of those layers and the headline number stops being a system property.[1][2][3]

The CERN photograph above shows two engineers working across switches, optical fibers, an oscilloscope, and loose transceiver parts.[10] That is White Rabbit in its honest form: not a daemon that turns an arbitrary LAN into a timing appliance, but an open hardware-and-software stack whose physical path remains part of the computation.

One Ethernet network, two different shapes

A White Rabbit network carries ordinary Ethernet data, yet timing imposes a hierarchy on top of it. A switch synchronizes to an upstream source and then becomes the time source for devices and switches downstream. A node sits at an endpoint, often beside a sensor, trigger generator, or time tagger. Data can move between peers through the switched network; frequency and time descend from a selected grandmaster.[1][4]

This distinction prevents a common architecture mistake. Redundant data paths do not automatically make redundant timing paths, and an Ethernet link being up does not prove that a port is locked to the intended clock. Operators need to know both the packet topology and the timing tree: which port is upstream, which grandmaster won, whether each link completed White Rabbit setup, and whether the endpoint is synchronized or merely reachable.

The scope is narrower than the name “Ethernet” can suggest. The Collaboration states that sub-nanosecond synchronization is provided between White Rabbit switches and nodes.[1] A conventional switch may still carry compatible PTP traffic in a mixed network, but it cannot perform the full White Rabbit link procedure or provide its calibrated physical-layer behavior. The high-accuracy island ends where the specialized ports end.

Frequency comes first

Two clocks can show the same time now and immediately begin to drift because their oscillators run at slightly different rates. White Rabbit first removes that rate error through physical-layer syntonization, the frequency-transfer job associated with Synchronous Ethernet.

In the reference design, a master encodes Gigabit Ethernet using a 125 MHz reference. The slave recovers that frequency from the incoming serial stream instead of relying only on a free-running local oscillator. A downstream switch can recover the upstream clock and use it to encode its own outgoing links, extending a common rate through the timing tree.[3][4]

Syntonization is deliberately not called synchronization. Sharing 125 million cycles per second does not tell a slave which cycle corresponds to a particular second, nor does it remove the phase shift introduced by a length of fiber. It merely makes the clocks beat together. That stable frequency relationship gives the later layers a moving target they can actually measure.

It also creates an immediate failure signature. The White Rabbit specification treats link loss as a loss of syntonization that requires the link setup to be established again.[3] A monitoring system should therefore surface lock and re-lock state, not smooth over an optical flap because IP connectivity returned quickly.

PTP names the time and measures the round trip

Precision Time Protocol supplies the next layer. Announce messages let ports select a clock hierarchy. Sync and FollowUp messages carry the master's time; DelayReq and Delay_Resp complete a two-way measurement. Hardware records the familiar transmit and receive timestamps—t1, t2, t3, and t4—close to the wire, avoiding the variable scheduling and queue delays that would swamp a sub-nanosecond budget.[3][4]

Those exchanges answer two different questions: “What time does the grandmaster say it is?” and “How long did this link appear to take?” White Rabbit extends the protocol with link setup and hardware support so that the answers can be more precise than ordinary software PTP. Its core ideas were later generalized into the High Accuracy Default PTP Profile in IEEE 1588-2019, including layer-1 performance enhancements, delay-asymmetry calculation, timestamp correction, calibration procedures, and externally assigned port roles.[2]

That standardization matters for longevity, but it does not erase a migration detail. The Collaboration says legacy WR-PTP and the newer High Accuracy profile are not protocol-compatible with each other, even though both can use White Rabbit hardware and target the same synchronization performance; the High Accuracy implementation is still described as beta while backward compatibility is maintained.[2] Procurement must therefore specify protocol mode and tested interoperability, not just “IEEE 1588” on both data sheets.

Phase measurement gets below one tick

At 125 MHz, one clock period is 8 nanoseconds—already eight times larger than the entire advertised accuracy target. A timestamp counter that only chooses clock edges cannot resolve enough detail. White Rabbit turns the missing fraction into a phase-measurement problem.

Its reference implementation uses a Digital Dual Mixer Time Difference circuit, or DDMTD, to compare clocks with the same nominal frequency. Because SyncE has already aligned their rates, the circuit can measure the phase relationship between the returned clock and the local reference. That information refines receive timestamps beyond the base 8 ns tick and drives a phase shifter on the slave. Coarse time, whole clock cycles, and the remaining sub-cycle phase are corrected separately.[3][4]

The ordering is the architecture: frequency lock first, packet exchange and delay estimate next, fine phase correction last. Trying to make packet timestamps do all three jobs would leave oscillator drift and clock-edge resolution mixed into the same noisy estimate. White Rabbit earns precision by giving each error source a mechanism suited to it.

Half the round trip is not necessarily one way

Even perfect timestamps do not make a two-way link symmetric. A White Rabbit optical link sends in both directions over one fiber using different wavelengths. Fiber dispersion makes those wavelengths propagate at slightly different speeds. The transmit and receive paths also contain unequal fixed delays through the FPGA, PCB traces, electronic components, and SFP modules. Receiver alignment adds a measurable “bitslide” term.[3][5]

Simply dividing the round-trip time by two would hide all of that asymmetry inside the clock offset. White Rabbit instead models four device delays—transmit and receive at the master, transmit and receive at the slave—plus the two fiber propagation delays. Its calibration procedure determines device delay and a relative fiber-delay coefficient, then uses those values when converting the observed round trip into a one-way delay.[5]

This is the least glamorous and most important adoption constraint. The official procedure calls for matched device designs and bitstreams, complementary transceivers, reference fibers, 1-PPS outputs, and an instrument able to measure intervals below 1 ns.[5] Change an SFP pair, FPGA image, board revision, or optical route and a previously measured constant may no longer describe the system. Temperature can move long-fiber latency as well. “Locked” means the control loop converged with the parameters it was given; it does not prove those parameters are correct.

The Collaboration's developing qualification process reflects that risk. It calls for a separate test for every device model and after significant firmware, software, or behavioral changes, explicitly treating sub-nanosecond accuracy and cross-vendor interoperability as properties to demonstrate rather than labels to inherit.[9]

The open stack is larger than the protocol

White Rabbit's inspectable surface crosses several kinds of engineering. The switch design includes mechanics and PCBs, FPGA gateware, bare-metal firmware, embedded Linux software, and documentation. Nodes instantiate the White Rabbit PTP Core and then add platform- and board-support packages around it.[1]

The source layout preserves those seams. The wr-cores repository contains the HDL used by nodes and switches, including the White Rabbit PTP Core; its README points builders to the separate wrpc-sw repository for the software wrapper, PTP daemon, and device drivers that run against the core's hardware blocks.[6][7] At publication, wr-cores lists a tagged WRPC v5.0 line and master as the development branch, making a versioned gateware/firmware pairing more meaningful than “latest White Rabbit.”[6]

Openness makes inspection, porting, and multi-vendor implementation possible. It does not make every extension part of the timing core. The Collaboration explicitly allows proprietary or open features around documented interfaces while keeping modifications to the shared technology under weakly reciprocal hardware and gateware licenses.[1] An integrator still has to identify which layer owns a behavior—and which organization will debug it at 3 a.m.

What a credible pilot proves

White Rabbit fits teams that truly need tightly correlated measurements and can own optics, calibration, monitoring, and spares. It is excessive for services whose real requirement is millisecond ordering, and risky for a small team that wants appliance-grade timing without maintaining a reference source or measurement capability.

A credible pilot should use the exact grandmaster, switches, nodes, SFP pairs, fibers, gateware, and firmware intended for deployment. It should verify cold starts and link re-locks; compare 1-PPS outputs at the chosen reference plane; record fixed-delay and fiber-asymmetry parameters; exercise the maximum switch depth; and test what downstream applications do during loss of lock. Keep raw measurements and configuration beside the bill of materials. A timing result without that provenance is hard to reproduce and harder to challenge.

An independent 2026 radio-astronomy study shows both the reach and the work involved. Researchers used White Rabbit to distribute a reference for radio interferometry, including a 169 km path on SURF's production DWDM network alongside high-speed data traffic.[8] That was not a plug-and-play extension of the ordinary 10 km optical profile: the setup used selected wavelengths, bidirectional optical amplification, measured phase noise, and fiber-dispersion calibration. The successful telescope observations demonstrate a powerful extension precisely because the paper exposes the extra engineering rather than hiding it.[8]

White Rabbit's deepest open-source lesson is therefore not that nanoseconds can be downloaded. It is that a difficult physical guarantee becomes reviewable when frequency transfer, time exchange, phase detection, delay calibration, hardware implementation, and operational evidence remain separate enough to test. The clock on the wall is one number. The system that deserves to trust it is a chain of proofs.

cronfeed.work