Special Focus: Understanding the IEEE 1588 Precision Time Protocol

Publish Date: Nov 06, 2015 | 28 Ratings | 3.57 out of 5 | Print | 1 Customer Review | Submit your review

Measurement and automation applications often must precisely synchronize events over a widely distributed system. For example, an industrial automation system may need to synchronize distributed motion controllers, or a test and measurement system may need to measure strain gages distributed over the wing span of an airplane. The IEEE 1588 precision time protocol (PTP) provides a standard method to synchronize devices on a network with submicrosecond precision. The protocol synchronizes slave clocks to a master clock ensuring that events and timestamps in all devices use the same time base. IEEE 1588 is optimized for user-administered, distributed systems; minimal use of network bandwidth; and low processing overhead. This article explains IEEE 1588 synchronization technology and compares it with other synchronization technologies.

IEEE 1588 Technology Overview
By synchronizing multiple clocks over networks such as Ethernet, IEEE 1588 provides submicrosecond synchronization over long distances with standard cabling. There are two steps for synchronizing devices using IEEE 1588: (1) determine which device serves as the master clock, and (2) measure and correct time skew caused by clock offsets and network delays. When a system is initialized, the IEEE 1588 protocol uses the Best Master Clock algorithm to automatically determine which clock in the network is the most precise. It becomes the master clock. All other clocks become slaves and synchronize their clocks with the master.

Because the time difference between the master clock and slave clock is a combination of the clock offset and message transmission delay, correcting the clock skew is done in two phases -- offset correction and delay correction. The master clock initiates offset correction using "sync" and "follow-up" messages (see Figure 1). When the master sends a sync message, the slave uses its local clock to timestamp the arrival of the sync message and compares it to the actual sync transmission timestamp in the master clock’s follow-up message. The difference between the two timestamps represents the offset of the slave plus the message transmission delay. The slave clock then adjusts the local clock by this difference at point A. To correct for the message transmission delay, the slave uses a second set of sync and follow-up messages with its corrected clock to calculate the master-to-slave delay at point B. The second set of messages is necessary to account for variations in network delays. The slave then timestamps the sending of a delay request message. The master clock timestamps the arrival of the delay request message. It then sends a delay response message with the delay request arrival timestamp at point C. The difference between the timestamps is the slave-to-master delay. The slave averages the two directional delays and then adjusts the clock by the delay to synchronize the two clocks. Because the master and slave clocks drift independently, periodically repeating offset correction and delay correction keeps the clocks synchronized.




Figure 1. This simplified IEEE 1588 example shows offset and delay correction to synchronize clocks.


Typical Performance
Most IEEE 1588 implementations will have submicrosecond skew, but actual performance is highly application-specific. For example, the IEEE 1588 protocol does not specify the clock frequency in the master and slaves; thus, lower-frequency clocks have poorer time resolution resulting in less-accurate timestamps in the PTP synchronization messages. Clock stability is another implementation dependency. Clocks based on temperature-controlled crystal oscillators (TCXOs) and oven-controlled crystal oscillators (OCXOs) have higher stability, usually in the parts per billion, compared with clocks using uncontrolled crystal oscillators, with stability in the parts per million. Clocks with lower stabilities will drift apart faster, resulting in more frequent frequency and phase corrections or resulting in larger skews. Another factor is network topology. The simplest network topology -- two devices on a single cable -- provides less network jitter than many devices linked using routers and switches. If more than one subnet is required to increase distance or number of devices, then a network switch with an accurate IEEE 1588 clock, called a boundary clock, becomes the master clock and synchronizes the devices on the subnets. Also, wide variations in network traffic may negatively impact clock skew as the delay correction lags current traffic conditions. Because many factors can degrade skew performance, benchmarking and monitoring actual skew performance over time is recommended.

Comparing Synchronization Alternatives
There is a range of synchronization alternatives available to measurement and automation developers. Table 1 compares synchronization using a PXI backplane, multichassis synchronization using a PXI timing control slot (slot 2), IEEE 1588 over Ethernet, and network time protocol (NTP), an Internet software protocol for synchronizing clocks over a network.



PXI Backplane Cabling from a PXI Timing Control Slot IEEE 15881 NTP on IP
Event Resolution ~0.01 ns ~50 ns ~50 ns2 <1x107 ns
Event Jitter ~0.002 ns ~0.5 ns ~100 ns2 ~3x106 ns
Distance ~0.5 m <200 m <400 m3 Worldwide
Sample Rates 100s of MHz 100s of MHz <100 KHz <10 Hz
Async Trigger 4
Cabling n/a Coaxial CAT 5 Ethernet Ethernet, etc.
Topology User-defined User-defined Auto-resolve, master/slave Peer-to-peer

1The values provided here are based on a hardware implementation of IEEE 1588.
2Best case; topology- and traffic-dependent; NI PCI-1588 supports a 200 ns skew
3Can extend further with additional expense using boundary clocks
4UDP supports asynchronous events

Table 1. Compare event resolution with distance and latency for industry-standard synchronization alternatives.


The minimum skew between events influences the typical sampling rates of synchronized acquisition and generation. Event resolution is the minimum determinable time period to start, stop, or timestamp an event. Unlike most clocks -- for which jitter is smaller than the clock resolution -- with IEEE 1588 Ethernet packet delays, the clock jitter is more likely to be larger than the resolution and the limiting factor in event resolution. Most IEEE 1588 implementations have event resolutions well below the submicrosecond target skew.

Event latency is another trade-off in comparing the alternatives. This is the time it takes for an event request to leave the master and reach the slave. Because both IEEE 1588 and NTP are using IP, the event latency is limited by the packet latency plus device IP stack overhead and is usually in the millisecond range. Therefore, while backplanes and timing control modules with cabling can trigger events in nanoseconds, the IP-based protocols are limited to milliseconds. This larger latency also limits the ability of IEEE 1588 to effectively handle asynchronous events.

Backplane synchronization schemes such as PXI are ideal for high-accuracy, high-speed acquisition, and with multichassis synchronization modules, can be extended over long distances. Standard NTP synchronization over Ethernet offers millisecond synchronization appropriate for lower-speed events that are not time-critical. IEEE 1588 provides an important alternative for systems requiring submicrosecond skew in geographically distributed systems. By leveraging the advantages of Ethernet cabling, providing submicrosecond skew, and operating with minimal processor and network administrator overhead, IEEE 1588 has a broad appeal across many industries, especially industrial automation, test and measurement, and communications, for device synchronization over Ethernet networks.


This article first ran in the Q4 2005 LabVIEW Special Edition issue of Instrumentation Newsletter.

 

Back to Top

Customer Reviews
1 Review | Submit your review

VXI is missing from table 1 !!  - Feb 23, 2006

Inclusion of VXI in table 1 would be useful for those of us who have VXI hardware, but have not been using the timing capabilities that are inherent.

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit