Examination of time and frequency control across wide area networks using IEEE-1588v2 unicast transmissions

Abstract

The IEEE 1588-2008 Precision Time Protocol (PTP) version 2 (IEEE 1588v2) can be used to synchronize a slave clock to a grandmaster clock over a wide area network (WAN). However, many of the algorithms the slaves use to steer to the master are optimized for a scenario where both devices are on the same subnet or local area network (LAN). This paper is a study of existing PTP hardware from a number of different manufacturers in unicast mode. We characterize the performance of the equipment, beginning with the timing outputs of the masters that are locked to their built-in Global Positioning System (GPS) receivers. Next, we compare the results of steering unicast clients to their masters through a LAN versus several wider-area network configurations such as virtual-LANs and the public Internet. Analysis of the results will show how clients of different manufacture handle the various network paths. It is our hope that these comparisons will instigate changes to clock steering and synchronization algorithms, which may help improve the overall capabilities of PTP for telecom and other networking environments. As network synchronization techniques improve, the quality of the PTP masters will become more significant. Therefore, the performance and calibration of PTP masters with respect to UTC(NIST) is also discussed.

A resilient architecture for the realization and distribution of coordinated universal time to critical infrastructure systems in the United States :

“…Then, the cable to the antenna splitter was removed from Server B, forcing GPS reception to be lost, and forcing Server B to become a PTP client of Server A. As previous experiments have shown, a PTP client, using the standard profile settings on a LAN, can be synchronized to within 100 ns of its reference [97]. That was confirmed here, as shown in Fig.…”

“…In this example, the remote Server C is connected to its own GPS antenna, and Servers A and B are both configured as unicast clients, specifically using the IP address of Server C, so they do not use each other as their PTP reference. In this example, the network asymmetry that exists between Servers A and B and Server B may result in PTP synchronization errors that exceed 1 µs, as shown in previous experiments with a similar configuration [97]. Therefore, using PTP as a frequency holdover source that preserves existing GPS synchronization, rather than relying upon PTP as a time synchronization source, is a key principle of the PTP Ring method.…”