RADclock Accuracy and Robustness

The most common question asked about the RADclock is: "How accurate does it get?". The less common question asked is "How robust is the RADclock?". We see these two questions as equally important.

The absolute accuracy depends mostly on:

• the quality of the NIC used (see here).
• the temperature environment (bad periodic air conditioning systems).
• the distance / delay / congestion to the reference server.
• the polling period you choose your RADclock daemon to use.

The RADclock is designed to be extremely robust (i.e. will not exhibit unstable behavior) to many events, including

• server errors
• network disconnection
• congestion periods

The RADclock publications contain thorough analysis of the RADclock performance using our methodology. Here we only present a very small subset of these results as particular case studies.

Performance on a LAN

Comparison RADclock and ntpd-GPS

Here we show a zoomed-in view of the performance of the RADclock (blue), running on a FreeBSD 6.1 on a Dell GX620 (Pentium D, 3.4GHz). The NIC is a Realtek 8139 PCI card (100Mbps). The RADclock is synchronising to a Stratum-1 NTP server located on a LAN (couple of switches away) with a polling period of 16 [sec]. The minimum RTT is of the order of 280 [mus], there is barely any congestion on the network.

We also show the performance of the ntpd daemon running simultaneously on the some host (red). Here, ntpd is not synchronising over the network but by a GPS signal and a PPS from our atomic clock through the computer serial port, and runs with a Stratum-1 status.

In this experiment the RADclock synchronising to a server on a LAN performs as well as ntpd with an atomic clock! The RADclock performance exhibits an IQR smaller than 10 [mus]. The oscillations the two clocks exhibits are due to the change of temperature of the environment: the air conditioning system cycles of the room where the host is located.

Comparison RADclock and ntpd-NTP

Here we show a 43 day long copture of the RADclock (blue) and ntpd (red), running simultaneously on a on a FreeBSD 6.1 on a Dell Optiplex GX1 (Pentium 3, 600Mhz). The NIC is a 3Com 3c905B card (100Mbps) embedded on the motherboard. The RADclock and ntpd share the same flow of NTP packets to a Stratum-1 NTP server located on a LAN using the RADclock piggy-backing mode. The polling period is fixed to 256 [sec]. The minimum RTT is of the order of 280 [mus], there is barely any congestion on the network.

While ntpd shows long period of correct behaviour, it also exhibits week long periods of instability and large deviations. The RADclock, which uses the exact same input shows extremely stable performance with an IQR below 10 [mus].

Comparison RADclock and ptpd

Here we present a 5 days capture showing the performance of the RADclock and ptpd running both on Linux 2.6.20 on a Dell Dimension 8100 (Pentium 4 1.4GHz). The NIC is a 3Com 3c905C card (100Mbps) embedded on the motherboard. The RADclock and ptpd both synchronise to a Stratum-1 server on the LAN with a 16 [sec] polling period. There is negligible network traffic and very light host load. The time series show very consistent performance for each clock, however the RADclock is considerably less variable, with an Inter-Quartile Range (IQR) of 8.1μs compared to 31.6μs for ptpd.

Here we examine the robustness of both the RADclock and ptpd when facing a loss of connection to the time server. We first allow each clock to converge. We then disconnect the testbed monitoring hub from the network for about 2 hours, then reconnect it. Over the disconnected period, the RADclock shows a gradual drift, the inevitable result of a lack of access to a master, and immediate recovery upon reconnection. In contrast the reaction of ptpd is extreme. As shown in the first zoomed-in timeseries, following the disconnection at 150 minutes ptpd dives to reach an error of −300[ms] before reconnection. After reconnection, ptpd's error remains in the [ms] range for most of the hour required for convergence as shown on the second zoomed-in timeseries. More detailed results have been published in our paper The Cost of Variability.

RADclock difference clock stability and robustness

Here we show the performance and robustness of the difference clock capability provided by the RADclock. The RADclock runs on FreeBSD 5.3 on a Dell Precision 410 (Pentium 3 600MHz). The NIC is a 3Com 3c905B (100Mbps) embedded on the motherboard. The RADclock synchronises to a NTP server on a LAN with a 16 [sec] polling period.

The first results (blue) show the accuracy of the difference clock which is within a [-1,+1] [mus] band when compared internally against a GPS and PPS synchronised ntpd clock. The actual performance of the difference clock is below the level of system noise and likely to be much better than the micro-second level shown here! Note that due its design, the difference clock cannot be responsible by the spikes seen here, whose cause can be traced back to ntpd.

We now use the replay capability of the RADclock feedforward algorithm to emulate a loss of network connectivity of 25 days! The RADclock algorithm does not get any NTP packets to compensate for local drift for this entire period. The performance of the RADclock difference clock remains almost identical, an amazing performance. As shown by the corresponding histograms, the clock error median is shifted by only 150 nanoseconds. The corresponding IQR measure shows a degradation of stability of 30 nanoseconds.

These results show the extreme robustness of the RADclock difference clock.

Performance beyond the LAN

To appear here soon, please see our papers Robust Synchronization of Absolute and Difference Clocks over Networks and Ten Microseconds Over LAN, for Free (Extended) for results already published.