|Download Help (Windows Only)|
Using the IEEE 1588-2008 precision time protocol (PTP), you can synchronize several clocks connected via a multicast capable network, such as Ethernet. The protocol requires little network bandwidth overhead, processing power, and administrative setup. Depending on the hardware you use, IEEE 1588-2008 can provide submicrosecond synchronization over long distances with standard cabling. Refer to the device's hardware manual for typical performance results with NI-Sync.
NI-Sync is a hardware implementation of the IEEE 1588-2008 protocol; NI-Sync devices operate at the Layer 3 level and use the default profile.
|Tip Visit ni.com/info and enter the info code swsync for more detailed information on the IEEE 1588 protocol and distributed clock technology.|
Refer to the following table to compare synchronization accuracy using the PXI backplane, multichassis synchronization using cabling from a PXI system timing slot, a hardware implementation of the IEEE 1588-2008 protocol over Ethernet, and network time protocol (NTP):
|PXI Backplane||PXI System Timing Slot||IEEE 1588||NTP on IP|
|Event Resolution||~0.01 ns||~50 ns||~50 ns*||<1x107 ns|
|Event Jitter||~0.002 ns||~0.5 ns||~100 ns*||~3x106 ns|
|Distance||~0.5 m||<200 m||<400 m†||Worldwide|
|Sample Rates||100s of MHz||100s of MHz||<100 KHz||<10 Hz|
|Asynchronous Trigger||Supported||Supported||Not Supported||Not Supported|
|Cabling Type||n/a||Coaxial||CAT 5 Ethernet||Ethernet, etc.|
|Source: Special Focus: Understanding the IEEE 1588 Precision Time Protocol|
*Best case, topology- and traffic-dependent.
†Can extend further using boundary clocks and transparent switches.
IEEE 1588-2008 mainly uses bidirectional multicast communication to synchronize slave clocks to the 1588 grandmaster. The grandmaster clock periodically issues a sync packet, which is timestamped when it leaves the grandmaster clock. Optionally, the grandmaster may issue a follow up packet that contains the timestamp for the sync packet. Using a follow up packet, the grandmaster can accurately timestamp the sync packet on networks where you cannot know the departure time of a packet beforehand.
A slave clock receives the grandmaster's sync packet and timestamps the packet's arrival time using its own clock. The difference in the sync packet's departure timestamp and its arrival timestamp is the combination of the slave clock's offset from the grandmaster and the propagation delay of the network. When the slave adjusts its clock by the offset it measures when it receives the sync packet, it reduces the offset between the master and slave to the network propagation delay only.
The slave clock then compensates for the network propagation delay using a delay request packet. The delay request packet is timestamped when it departs from the slave, timestamped again when the master clock receives it, and then sent back to the slave clock with the new arrival timestamp. The difference between the arrival and the departure timestamps is the network propagation delay. Slave clocks can accurately measure the offset between their local clock and the master's clock using these synchronization packets, allowing them to adjust their clocks to match the time of the master. The IEEE 1588-2008 specification does not include any standard implementation for adjusting a clock, it merely provides a standard protocol for exchanging the synchronization messages, allowing devices from different manufacturers and with different implementations to work together.
Actual performance on an IEEE 1588 network is highly application-specific. For example, the protocol does not specify the clock frequency in the master and slaves, so lower-frequency clocks have poorer time resolution, resulting in less-accurate timestamps in the PTP synchronization messages. 1588's performance is also dependent on clock stability: clocks based on TXCOs and OCXOs have a higher stability than clocks using uncontrolled crystal oscillators. Clocks with lower stabilities drift apart faster, resulting in more frequent phase or frequency corrections and larger skews. Network topology also impacts IEEE 1588 performance.
IEEE 1588-2008 uses two steps to synchronize devices: (1) the Best Master Clock algorithm (BMCA) determines which device serves as the master clock, and (2) the NI-Sync driver measures and corrects time skew caused by clock offsets and network delays.
The BMCA defines a standard set of clock characteristics—such as the origin of a clock's time source and the stability of the clock's frequency—and then assigns a value to each clock in order to determine the highest ranking, most accurate clock on the network, which then becomes the grandmaster clock. All the slave clocks in the network synchronize to the grandmaster clock. The BMCA continues to assess the quality of each clock, so if the grandmaster clock leaves the network or is no longer the most accurate clock, the algorithm automatically selects a new grandmaster. The BMCA also takes into account user-defined priority values, which you can set using the Priority 1 and Priority 2 properties.
You can use IEEE 1588 boundary clocks and transparent switches to measure and correct time skew across large networks. A boundary clock is a network switch with an accurate IEEE 1588 clock. A switch acting as a boundary clock runs the PTP protocol and is synchronized to an attached master clock. The boundary clock then acts as a master clock to all attached slaves. Boundary clocks do not pass Sync, Follow_Up, Delay_Req, or Delay_Resp messages. Within a subnet, a port of a boundary clock acts just like an ordinary clock with respect to synchronization and the BMC algorithm. Boundary clocks define a parent-child hierarchy of master-slave clocks: the boundary clock internally selects a port that sees the best clock as the single slave port, which then becomes a slave in the selected subnet. All other ports of the boundary clock internally synchronize to this slave port. Using a boundary clock, all internal latencies and jitter in the switch can be compensated for and do not affect synchronization accuracy.
Transparent switches solve the same problem as boundary clocks, but in a slightly different manner. A transparent switch is so called because it does not operate as a PTP node in an IEEE 1588-2008 system. Instead, it modifies the timing contents of PTP packets to account for the delay caused by the switch. Typically, a transparent switch calculates how much time a sync packet spends inside the switch, and then modifies the timestamp of the associated follow up packet to account for this delay. The use of transparent switches allows PTP nodes to operate as if they were all part of one LAN segment connected by hubs.