Robust Synchronization of Absolute and Difference Clocks Over Networks

Abstract

We present a detailed re-examination of the problem of inexpensive yet accurate clock synchronization for networked devices. Based on an empirically validated, parsimonious abstraction of the CPU oscillator as a timing source, accessible via the TSC register in popular PC architectures, we build on the key observation that the measurement of time differences, and absolute time, requires separate clocks, both at a conceptual level and practically, with distinct algorithmic, robustness, and accuracy characteristics. Combined with round-trip time based filtering of network delays between the host and the remote time server, we define robust algorithms for the synchronization of the absolute and difference TSCclocks over a network. We demonstrate the effectiveness of the principles, and algorithms using months of real data collected using multiple servers. We give detailed performance results for a full implementation running live and unsupervised under numerous scenarios, which show very high reliability, and accuracy approaching fundamental limits due to host system noise. Our synchronization algorithms are inherently robust to many factors including packet loss, server outages, route changes, and network congestion.

Clockscalpel: Understanding Root Causes of Internet Clock Synchronization Inaccuracy

“…Second, we found the main sources of this inaccuracy come from propagation delay asymmetry and queueing delay asymmetry in the wide area. Third, although the path delay asymmetry is considered not measurable [6] 1 , we find that synchronization accuracy is well-correlated with some path properties that can be probed by end-hosts. To address this, we evaluate several heuristics that compensate for this error (by estimating the error and correcting for it).…”

“…Recently, novel frameworks [5,6] are proposed to further improve the synchronization accuracy. While these studies showed that some NTP servers are inaccurate, the underlying cause of inaccuracies remain unclear.…”

Probing the latencies of software timestamping

“…For more general use however, where time intervals may be larger, the error may be unacceptable. In future work we will significantly reduce it by using timestamp in conjunction with the RADclock difference clock [2], [8].…”

“…More importantly still, the fact that it does not respect causality (packets can, and often do, leave before their timestamp is made), means it cannot even be used to measure RTTs, and fatally, cannot be bounded by them. This is very dangerous for timekeeping as it excludes effective methods for the filtering of delay variability [2]. An alternative approach could be to pair an so timestamp on incoming with a different timestamp on outgoing.…”

“…These include the latencies between the packet timestamping locations typically used by ntpd [1], RADclock [2], ptpd [3], and timekeeper [4], and span user, kernel, and (to a close approximation) NIC based timestamping. Our study is focussed on the FreeBSD operating system, as it is a stable and mature platform within which to perform metrology, and because it supports the DTrace system profiler tool.…”