We demonstrate sub-nanosecond synchronization of distributed instruments over a White Rabbit network.

Sync over White Rabbit

White Rabbit extends standard Ethernet with a deterministic, hardware-based synchronization layer. Every switch in the network measures and compensates its own link delay, so a common timebase propagates from the grandmaster to the end nodes without accumulating jitter. This makes it possible to compare time stamps taken by physically distributed instruments down to the sub-nanosecond range. The same fabric also carries ordinary data traffic, which keeps the deployment effort low.

The key idea is that synchronization does not rely on software timestamps or best-effort polling. Instead, each port continuously exchanges sync and delay messages and locks a local clock to the upstream reference. As a result, the residual error is dominated by the physical layer rather than by protocol jitter. Long chains of switches remain stable because every hop re-times the signal.

For our testbed we connected two time taggers to a small White Rabbit network and fed both with the same optical pulse train. The taggers were configured as ordinary nodes, while a dedicated switch acted as the grandmaster reference. After the initial lock, both devices reported a continuous, gap-free stream of time stamps.

This arrangement mirrors a realistic user scenario: instruments are not co-located but share a common timing fabric. The measurements below therefore show what can be expected when synchronization is taken out of the software domain entirely.

Measurement setup

The core of the setup is a pair of time taggers that record the arrival time of each detected pulse. Both instruments were connected to the White Rabbit network and synchronized to the grandmaster clock. The same optical signal was split and delivered to the two inputs so that any remaining offset becomes directly visible in the recorded timestamps.

We operated the system for 24 hours and logged every timestamp together with the local clock status. This gives us both a short-term view of the raw timing error and a long-term view of drift and holdover behaviour. Clock status flags were recorded as well, allowing us to discard any intervals in which a node lost synchronization.

All measurements were taken with the default configuration of the instruments; no additional averaging or post-processing was applied to the timing data. The environment was a standard laboratory with moderate temperature variation, which represents a realistic operating condition for precision instrumentation.

In addition to the pulse stream, we recorded network statistics from the switches to confirm that the data plane stayed healthy during the entire run. This is important because a measurement campaign is only valid if the synchronization fabric itself is stable.

Results and outlook

Over the full 24 hours the two time taggers stayed within the expected range of each other. The residual timing difference remained well below one nanosecond for the vast majority of the measurement window. Only a small number of outliers were observed, and each of them could be traced to a known clock-status event rather than to the measurement itself.

The jitter histogram is narrow and shows no bimodal structure, which indicates that the synchronization loop is well damped and free of parasitic periodic components. This is exactly the behaviour required for applications such as pump-probe experiments or coincidence counting, where timing errors translate directly into measurement uncertainty.

An interesting aspect for the future is the scalability of the approach. Because every hop re-times the signal, adding more nodes does not fundamentally degrade the achievable accuracy. Larger networks with additional switches and longer fiber runs are the next step to verify this expectation in a production-like environment.

We are also evaluating tighter integration between the timing fabric and the instruments themselves, for example by exposing the clock status directly in the measurement stream. Combined with the results shown here, this would give users a complete and verifiable timing chain from the reference down to the recorded data.