IEEE 1588 precise time protocol

Now that this standard is so mature it is time to consider how to use it in OSC. It is already integrated into high quality time reference hardware and in Intel network processors.

This paper on packet timestamping seems particularly useful:
IEEE 1588 Implementation and Performance of Time Stamping Techniques

Special Focus: Understanding the IEEE 1588 Precision Time Protoc

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.

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.

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.

_________________________________________

Ines Del Alma Mia

ntpd, ptpd etc

There is an IEEE 1588 software implementation available for linux machines at http//ptpd.sourceforge.net/ The authors claim synchronization accuracy far in excess of what is currently possible with ntpd.

Many of the problems voiced regarding clock jitter problems observed with NTP sync will go away when PTP replaces NTP as the preferred method of time synchronization for local area networks.

The question then is what, if anything, must be done to OSC to support PTP. OSC timestamps use the NTP format but given that the format resolution is sufficient it would seem that this does not need to change (the OSC 1.0 spec leaves the issue of how to synchronize time to other technologies). The further question of how to use precise timing effectively in distributed multimedia is one of best practices and algorithms.

-aws

Precision Time Protocol available

in case PTP (Precision Time Protocol) IEEE 1588 is still considered - we also have a solution without extra hardware required - uses regular network interfaces. www.real-time-systems.com (low Microsec. Jitter)

Gerd

and ptpd

PTPd [ http://ptpd.sourceforge.net/ ] is another pure software solution which is open source and runs on embedded linux including several embedded variants. How does it compare with the above?

PTPd is much better

i think PTPd is much better.

Syndicate content