As electronics systems become more complex, they tend to become more distributed. The more capable a system needs to be, the more components it may involve. But, they all need to work in sync with each other, especially in time-critical systems, or the whole thing falls flat.
For example, autonomous vehicles that rely on rapid processing of data from many different sensors (optical, LIDAR, proximity, GPS, inertial, etc.) may have several different devices processing that data interconnected by a communications bus or network. At some point, the analyzed data from different sensors is combined to make decisions (data fusion).
Data fusion requires that all data either is of the same age or is of a known age. To use the autonomous vehicle example once more, that’s more likely a matter of milliseconds than minutes. It also requires accurate time-synchronization among all of the data acquisition devices. In fact, most distributed time-critical systems need some form of time-synchronization.
Several commercially available solutions exist that provide various mechanisms and degrees of time-synchronization. Most solutions require dedicated hardware and infrastructure (e.g. wiring) and can increase a system’s size, weight, and cost (SWaP) considerably. Many solutions can only adjust for drift (relative time) and have no inherent mechanism to synchronize to absolute time.
The Precision Time Protocol (PTP), first standardized in 2002, provided a mechanism of synchronizing absolute time over standard Ethernet. Since then, several new versions and variants have been developed which are not all interoperable. Often the terms PTP, gPTP, and 1588 are misused or used interchangably without specifying a specific standard or version.
This can all be quite confusing. Let me help clear that up a bit.
The earliest version of PTP (2002) synchronizes each device’s absolute time to that of a “grand-master” (GM). Each slave device periodically sends a packet to the GM and the GM sends a response back. The packets contain incoming and outgoing timestamps added by the hardware that time-aware devices use to calculate propagation delays. The time-aware devices use the propagation delays to correct the GM time that is periodically sent in a separate packet in order to calculate the time difference between the GM and local device clocks. Typically, a device uses this difference to speed up or slow down its clock increment until it converges with the GM time.
PTP has the benefit of using the same physical medium (e.g. Ethernet) used for general communications, thereby reducing system size, weight, and cost. It also simplifies integration.
|Features||IEEE 1588-2002||IEEE 1588-2008 (v2)||IEEE 802.1AS-2011||IEEE 802.1AS-REV (draft only)|
|Residence time correction||No transparent clocks – e.g. switches are not time-aware||Transparent clocks – switch adjusts packet timestamps with residence time|
|Hardware timestamping||one step only||one and two-step||two-step only||one and two-step|
|Delay calculation mechanism||path delay||peer delay or path delay||peer delay|
|Bridge compatibility||time-aware and non-time-aware||time-aware only|
|Protocols supported||layer 2-4, IPv4 multicast only||layer 2-4, IPv4 or IPv6, multicast or unicast||layer 2 only|
|GM time transmit interval||up to 1/s||up to 10/s|
|Grandmaster redundancy||Multiple domains supported simultaneously (different subnets)||Single domain (single active grandmaster)||Redundant GMs in “hot-Standby”|
|Min End to End Sync Accuracy||< 1 us||< 1 us for <= 7 hops||<1 us for <= 7 hops|
FFO +/- 100 ppm; RR: +/-0.1 ppm
Jitter <2ns/60s; Granularity: <40ns
Although the basic concept of PTP has remained the same over the years, the protocol itself has gone through several substantial revisions, which are not all compatible with each other, as shown in the table above. In general, there are two dominant variants, the IEEE 1588 series [1, 2], commonly referred to as PTP, and IEEE 802.1AS series [3, 4], commonly referred to as Generalized PTP or gPTP.
The 2008 version of PTP (known as v2) introduced the most substantial differences in functionality. Unfortunately, this version introduced so many new variations that it became difficult to ensure interoperability among implementations. IEEE 802.1AS-2011 reduced the number of supported options in order to provide better performance guarantees and consistent interoperability.
The most notable features introduced by IEEE 1588-2008 that persist in the IEEE 802.1AS standard are the peer delay and transparent clock mechanisms. In the previous version of the standard (2002), end-to-end (path) latency delay is determined from the end-point all the way to the GM. This is inefficient on a multi-hop network especially if either topology or routing is dynamic. IEEE 1588-2008 introduced a peer delay mechanism whereby each device in a path only calculates its delay to its peer or neighbor(s). When the GM transmits its timestamp in a packet, each time-aware device in the path accounts for its latency to its neighbor.
All time-aware devices also have a transparent clock feature, which allows them to update the timestamp in packets on the fly to account for latency and residence time.
IEEE 1588-2008 introduced one other important aspect that persists in the IEEE 802.1AS standards. It specified what is required for a device to be conformant with the standard, which is essential given the number of possible different variations.
IEEE 802.1AS-2011 eliminates several variants to improve interoperability. It does not support layer 3 (e.g. IPv4, IPv6) and 4 (e.g. TCP, UDP) PTP protocols.
All gPTP protocols are layer 2 (Ethernet), which greatly reduces complexity for hardware or logic-based solutions. It eliminates the path delay mechanism in favor of the peer delay mechanism and it mandates that all bridges in the path between a time-aware device and the GM must be time-aware (i.e. provide transparent clock functionality). It also adds performance requirements on the stability and variance associated with the accuracy of time-synchronization.
IEEE 802.1AS-REV is the latest draft standard. Its goal is to tighten-up the performance requirements further to better accommodate the emerging TSN standard .
A majority of devices currently on the market only support IEEE 1588v2. There are only a few devices that support IEEE 802.1AS. While it is possible for a device to support both of these protocols, keep in mind that a device that only supports IEEE 1588v2 cannot synchronize with a device that only supports IEEE 802.1AS.
The next time you are in the market to purchase a device that supports time-synchronization, make sure all of your devices support the same protocol.
I hope this summary helps to reduce the confusion.
 “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” IEEE Std 1588-2002, pp. i–144, 2002.
 “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” IEEE Std 1588-2008 (Revision of IEEE Std 1588-2002), pp. 1–300, Jul. 2008.
 “IEEE Standard for Local and Metropolitan Area Networks – Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks,” IEEE Std 802.1AS-2011, pp. 1–292, Mar. 2011.
 “IEEE Draft Standard for Local and Metropolitan Area Networks – Timing and Synchronization for Time-Sensitive Applications,” IEEE P802.1AS-Rev/D6.0 December 2017, pp. 1–496, Jan. 2018.
 “IEEE Standard for a Transport Protocol for Time-Sensitive Applications in Bridged Local Area Networks,” IEEE Std 1722-2016 (Revision of IEEE Std 1722-2011), pp. 1–233, Dec. 2016.
 “IEEE Approved Draft Standard for Local and Metropolitan Area Networks–Bridges and Bridged Networks,” IEEE P802.1Q-REV/D2.2, January 2018, pp. 1–2000, Jan. 2018.