View source for Precision Time Protocol

{{short description|Network time synchronization protocol}}
{{Infobox networking protocol
| title        = Precision Time Protocol
| logo         = 
| logo alt     = 
| image        = 
| image alt    = 
| caption      = 
| is stack     = No
| abbreviation = PTP
| purpose      = Time
| developer    = IEEE
| date         = {{Start date and age|2002|  |  }}<!--Fill in: Year (4 digits), month and day (2 digits)-->
| based on     = 
| influenced   = 
| osilayer     = 
| ports        = udp/319, udp/320
| rfcs         = 
| hardware     = 
}}

The '''Precision Time Protocol''' ('''PTP''') is a protocol for [[Clock synchronization|clock synchronization]] throughout a [[Computer network|computer network]] with relatively high [[Accuracy and precision|precision]] as compared to using the earlier developed [[Network Time Protocol]] (NTP) and therefore ''potentially'' higher accuracy depending on the configuration. In a [[Engineering:Local area network|local area network]] (LAN), accuracy can be sub-microsecond {{endash}} making it suitable for measurement and control systems applications.<ref>{{cite web
|url=https://www.nist.gov/document/tutorial-basicpdf
|title=IEEE-1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, a Tutorial
|publisher=National Institute of Standards and Technology (NIST) |last=Eidson |first=John |date=10 October 2005
}}</ref> PTP can be used to synchronize [[Finance:Financial transaction|financial transaction]]s<ref>{{Cite web |last=Oehler |first=Erik |date=2023-07-19 |title=The Significance of Accurate Timekeeping and Synchronization in Trading Systems |url=https://safran-navigation-timing.com/timekeeping-and-synchronization-in-trading-systems/ |access-date=2025-12-03 |website=Safran - Navigation & Timing |language=en-US}}</ref>, mobile phone tower transmissions<ref>{{Cite web |title=Celona PTP Guidelines and Best Practices {{!}} Celona Help Center |url=https://docs.celona.io/en/articles/10581128-celona-ptp-guidelines-and-best-practices |access-date=2025-12-03 |website=docs.celona.io |language=en}}</ref>, sub-sea acoustic arrays<ref>{{Cite journal |last1=Wei |first1=Zhengrong |last2=Pei |first2=Yanliang |last3=Zhu |first3=Xiangqian |last4=Liu |first4=Kai |last5=Zhang |first5=Xiaobo |last6=Zong |first6=Le |last7=Li |first7=Xinyu |date=2024-07-29 |title=A high-precision positioning method for deep-towed multichannel seismic arrays |journal=Frontiers in Marine Science |language=English |volume=11 |article-number=1351327 |doi=10.3389/fmars.2024.1351327 |bibcode=2024FrMaS..1151327W |doi-access=free |issn=2296-7745}}</ref>, and networks that require precise timing as an alternative to using the timestamp of [[Earth:Satellite navigation|satellite navigation]] signals or where sub-nanosecond accuracy as provided by the [[White Rabbit Project|white rabbit project]] is unnecessary.<ref>{{Cite web |last=Austin |date=2025-02-18 |title=Nanosecond accurate PTP server (grandmaster) and client tutorial for Raspberry Pi |url=https://austinsnerdythings.com/2025/02/18/nanosecond-accurate-ptp-server-grandmaster-and-client-tutorial-for-raspberry-pi/ |access-date=2025-12-03 |website=Austin's Nerdy Things |language=en-US}}</ref>

The first version of PTP, '''IEEE 1588-2002''', was published in 2002. '''IEEE 1588-2008''', also known as PTP Version 2, is not backward compatible with the 2002 version. '''IEEE 1588-2019''' was published in November 2019 and includes backward-compatible improvements to the 2008 publication. IEEE 1588-2008 includes a ''profile'' concept defining PTP operating parameters and options. Several profiles have been defined for applications including telecommunications, [[Engineering:Electric power distribution|electric power distribution]] and [[Engineering:Audiovisual|audiovisual]] uses. '''{{vanchor|IEEE 802.1AS}}''' is an adaptation of PTP, called gPTP, for use with [[Audio Video Bridging]] (AVB) and [[Time-Sensitive Networking]] (TSN).

==History==
According to John Eidson, who led the IEEE 1588-2002 standardization effort, "IEEE 1588 is designed to fill a niche not well served by either of the two dominant protocols, [[Network Time Protocol|NTP]] and [[Engineering:GPS|GPS]]. IEEE 1588 is designed for local systems requiring accuracies beyond those attainable using NTP. It is also designed for applications that cannot bear the cost of a GPS receiver at each node, or for which GPS signals are inaccessible."<ref name="Eidson">{{cite book
|last=Eidson
|first=John C.
|title=Measurement, Control and Communication Using IEEE 1588
|publisher=[[Company:Springer Science+Business Media|Springer]]
|date=April 2006
|isbn=978-1-84628-250-8
}}</ref>

PTP was originally defined in the IEEE 1588-2002 standard, officially titled ''Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems'', and published in 2002. In 2008, IEEE 1588-2008 was released as a revised standard; also known as PTP version 2 (PTPv2), it improves accuracy, precision and robustness but is not backward compatible with the original 2002 version.<ref name=Eidson2>{{cite web |url=http://ieee1588.nist.gov/2006%20IEEE1588%20Agenda/Eidson_1588_Version%202.pdf |title=IEEE 1588 Standard Version 2 - A Tutorial |date=2 October 2006 |first=John |last=Eidson |archive-url=https://web.archive.org/web/20100331083017/http://ieee1588.nist.gov/2006%20IEEE1588%20Agenda/Eidson_1588_Version%202.pdf |archive-date=31 March 2010 |access-date=12 June 2008 |url-status=dead}}</ref> IEEE 1588-2019 was published in November 2019,<ref>{{cite web |url=https://standards.ieee.org/ieee/1588/6825/ |title=1588-2019 - IEEE Approved Draft Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems |publisher=IEEE |access-date=2020-02-15}}</ref> is informally known as ''PTPv2.1'' and includes backwards-compatible improvements to the 2008 publication.<ref name="Arnold 2017">{{cite web |url=https://blog.meinbergglobal.com/2017/09/24/whats-coming-next-edition-ieee-1588/ |title=What's coming In the Next Edition of IEEE 1588? |author=Douglas Arnold |date=24 September 2017 |access-date=2020-02-15}}</ref>

==Architecture==
The IEEE 1588 standards describe a hierarchical master–slave architecture for clock [[Distributed computing|distribution]] consisting of one or more [[Network segment|network segment]]s and one or more clocks. An ''ordinary clock'' is a device with a single network connection that is either the source of or the destination for a synchronization reference. A source is called a ''master'' (alternately ''timeTransmitter''<ref name="IEEE 1588g">{{citation |title=IEEE 1588g-2022 Amendment 2: Master-Slave Optional Alternative Terminology |publisher=IEEE |date=2022-12-03}}</ref>), and a destination is called a ''slave'' (alternately ''timeReceiver''<ref name="IEEE 1588g" />). A ''boundary clock'' has multiple network connections and synchronizes one network segment to another. A single, synchronization leader is selected, a.k.a. elected, for each network segment. The root timing reference is called the ''grandmaster''.<ref>{{cite web |title=Meanings of common terms used in IEEE 1588 |url=http://ieee1588.nist.gov/terms.htm |archive-url=https://web.archive.org/web/20100527161310/http://ieee1588.nist.gov/terms.htm |archive-date=27 May 2010 |publisher=National Institute of Standards and Technology |access-date=19 May 2006 |url-status=dead}}</ref>

A relatively simple PTP architecture consists of ordinary clocks on a single-segment network with no boundary clocks. A grandmaster is elected and all other clocks synchronize to it.

IEEE 1588-2008 introduces a clock associated with network equipment used to convey PTP messages. The ''transparent clock'' modifies PTP messages as they pass through the device.<ref name="TI2013">{{cite web |title=AN-1838 IEEE 1588 Boundary Clock and Transparent Clock Implementation Using the DP83640 |url=http://www.ti.com/lit/an/snla104a/snla104a.pdf |website=ti.com |publisher=Texas Instruments |access-date=17 July 2019}}</ref> Timestamps in the messages are corrected for time spent traversing the network equipment. This scheme improves distribution accuracy by compensating for [[Packet delay variation|delivery variability]] across the network.

PTP typically uses the same epoch as [[Unix time]] (start of 1 January 1970).{{efn|The profile capability under IEEE 1588-2008 allows the use of application-specific epochs.<ref name="1588-2008">{{citation |publisher=IEEE |date=24 July 2008 |doi=10.1109/IEEESTD.2008.4579760|isbn=978-0-7381-5400-8 |title=IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems }}</ref>{{rp|Annex B}}}} While the Unix time is based on [[Coordinated Universal Time]] (UTC) and is subject to leap seconds, PTP is based on [[Physics:International Atomic Time|International Atomic Time]] (TAI). The PTP grandmaster communicates the current offset between UTC and TAI, so that UTC can be computed from the received PTP time.

==Protocol details==
Synchronization and management of a PTP system is achieved through the exchange of messages across the communications medium. To this end, PTP uses the following message types.
*''Sync'', ''Follow_Up'', ''Delay_Req'' and ''Delay_Resp'' messages are used by ''ordinary'' and ''boundary'' clocks and communicate time-related information used to synchronize clocks across the network.
*''Pdelay_Req'', ''Pdelay_Resp'' and ''Pdelay_Resp_Follow_Up'' are used by ''transparent'' clocks to measure delays across the communications medium so that they can be compensated for by the system. ''Transparent'' clocks and these messages associated with them are not available in original IEEE 1588-2002 PTPv1 standard, and were added in PTPv2.
*''Announce'' messages are used by the best master clock algorithm in IEEE 1588-2008 to build a clock hierarchy and select the ''grandmaster''.{{efn|In IEEE 1588-2002, information carried by ''Announce'' messages is carried in the ''Sync'' messages. In IEEE 1588-2008, the ''Sync'' message has been optimized and this information is no longer carried here.}}
*''Management'' messages are used by [[Network management|network management]] to monitor, configure and maintain a PTP system.
*''Signaling'' messages are used for non-time-critical communications between clocks. Signaling messages were introduced in IEEE 1588-2008.

Messages are categorized as ''event'' and ''general'' messages. ''Event'' messages are time-critical in that accuracy in transmission and receipt timestamp accuracy directly affects clock distribution accuracy. ''Sync'', ''Delay_Req'', ''Pdelay_Req'' and ''Pdelay_resp'' are ''event'' messages. ''General'' messages are more conventional protocol data units in that the data in these messages is of importance to PTP, but their transmission and receipt timestamps are not. ''Announce'', ''Follow_Up'', ''Delay_Resp'', ''Pdelay_Resp_Follow_Up'', ''Management'' and ''Signaling'' messages are members of the ''general'' message class.<ref name="1588-2008"/>{{rp|Clause 6.4}}

===Message transport===
PTP messages may use the [[User Datagram Protocol]] over [[Internet Protocol]] (UDP/IP) for transport. IEEE 1588-2002 uses only [[IPv4]] transports,<ref name="1588-2002">{{citation |doi=10.1109/IEEESTD.2002.94144 |date=8 November 2002 |publisher=IEEE|isbn=978-0-7381-3369-0 |title=IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems }}</ref>{{rp|Annex D}} but this has been extended to include [[IPv6]] in IEEE 1588-2008.<ref name="1588-2008"/>{{rp|Annex F}} In IEEE 1588-2002, all PTP messages are sent using [[Engineering:Multicast|multicast]] messaging, while IEEE 1588-2008 introduced an option for devices to negotiate [[Unicast|unicast]] transmission on a port-by-port basis.<ref name="1588-2008"/>{{rp|Clause 16.1}} Multicast transmissions use [[IP multicast]] addressing, for which multicast group addresses are defined for IPv4 and IPv6 (see table).<ref name="1588-2008"/>{{rp|Annex D and E}} Time-critical ''event'' messages (Sync, Delay_req, Pdelay_Req and Pdelay_Resp) are sent to port number 319. ''General'' messages (Announce, Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, management and signaling) use port number 320.<ref name="1588-2008"/>{{rp|Clause 6.4}}

{| class="wikitable"
|-
|+ Multicast group addresses
|-
! Messages
! IPv4
! IPv6
! IEEE 802.3 Ethernet<ref name="1588-2008"/>{{rp|Annex F}}{{efn|PTP over bare IEEE 802.3 Ethernet using Ethertype 0x88F7}}
! Type
|-
| All except peer delay messages
| 224.0.1.129{{efn|IEEE 1588-2002 non-default domains use destination addresses 224.0.1.130 through 224.0.1.132 (see #Domains).}}
| FF0x::181{{efn|Where ''x'' is the address scope (2 for link-local) as per RFC 2373 (see [[Multicast address#IPv6|IPv6 multicast address]])}}
| 01-1B-19-00-00-00{{efn|In some PTP applications it is permissible to send all PTP messages to 01-1B-19-00-00-00}}
| Forwardable
|-
| Peer delay messages: ''Pdelay_Req'', ''Pdelay_Resp'' and ''Pdelay_Resp_Follow_Up''{{efn|Peer delay messages are intended to propagate to the immediately connected neighbor. The multicast addresses for these messages are designed to be link-local in scope and are not passed through a [[Engineering:Router (computing)|router]]. IEEE 1588-2008 also recommends setting [[Time to live|time to live]] to 1 (IPv4) or hop limit to 0 (IPv6) as further insurance that the messages will not be routed.}}
| 224.0.0.107{{efn|Peer delay messaging is not present in IEEE 1588-2002}}
| FF02::6B
| 01-80-C2-00-00-0E
| Non-forwardable
|}

In IEEE 1588-2008, encapsulation is also defined for [[DeviceNet]],<ref name="1588-2008"/>{{rp|Annex G}} [[ControlNet]]<ref name="1588-2008"/>{{rp|Annex H}} and PROFINET.<ref name="1588-2008"/>{{rp|Annex I}}

===Domains===
A domain{{efn|IEEE 1588-2002 defines a ''domain'' as any interconnected set of clocks (regardless of whether they synchronized to one another) and uses ''subdomain'' to refer to what is known as a ''domain'' in IEEE 1588-2008.}} is an interacting set of clocks that synchronize to one another using PTP. Clocks are assigned to a domain by virtue of the contents of the ''Subdomain name'' (IEEE 1588-2002) or the ''domainNumber'' (IEEE 1588-2008) fields in PTP messages they receive or generate. Domains allow multiple clock distribution systems to share the same communications medium.

{| class="wikitable"
|-
! ''Subdomain name'' field contents ({{gaps|IEEE|1588-2002}})
! IPv4 multicast address<br />({{gaps|IEEE|1588-2002}}){{efn|IEEE 1588-2008 uses 224.0.1.129 as the address for all multicast messages.}}
! ''domainNumber''<br />({{gaps|IEEE|1588-2008}})
! Notes
|-
| _DFLT
| 224.0.1.129
| 0
| Default domain
|-
| _ALT1
| 224.0.1.130
| 1
| Alternate domain 1
|-
| _ALT2
| 224.0.1.131
| 2
| Alternate domain 2
|-
| _ALT3
| 224.0.1.132
| 3
| Alternate domain 3
|-
| Application specific up to 15 octets<ref name="1588-2002"/>{{rp|Clause 6.2.5.1}}
| 224.0.1.130, 131 or 132 as per [[Hash function|hash function]] on ''Subdomain name''<ref name="1588-2002"/>{{rp|Annex C}}
| 4 through 127
| User-defined domains
|}

==Best master clock algorithm==
The ''best master clock algorithm'' (BMCA) performs a distributed selection of the best clock to act as leader based on the following clock properties:
* Identifier{{snd}}A universally unique numeric identifier for the clock. This is typically constructed based on a device's [[MAC address]].
* Quality{{snd}}Both versions of IEEE 1588 attempt to quantify clock quality based on expected timing deviation, technology used to implement the clock or location in a clock stratum schema, although only V1 (IEEE 1588-2002) knows a data field ''stratum''. PTP V2 (IEEE 1588-2008) defines the overall quality of a clock by using the data fields ''clockAccuracy'' and ''clockClass''.
* Priority{{snd}}An administratively assigned precedence hint used by the BMCA to help select a ''grandmaster'' for the PTP domain. IEEE 1588-2002 used a single Boolean variable to indicate precedence. IEEE 1588-2008 features two 8-bit priority fields.
* Variance{{snd}}A clock's estimate of its stability based on observation of its performance against the PTP reference.

IEEE 1588-2008 uses a hierarchical selection algorithm based on the following properties, in the indicated order:<ref name="1588-2008"/>{{rp|Figure 27}}
# Priority 1{{snd}}the user can assign a specific static-designed priority to each clock, preemptively defining a priority among them. Smaller numeric values indicate higher priority.
# Class{{snd}}each clock is a member of a given class, each class getting its own priority.
# Accuracy{{snd}}precision between clock and UTC, in nanoseconds (ns)
# Variance{{snd}}variability of the clock
# Priority 2{{snd}}final-defined priority, defining backup order in case the other criteria were not sufficient. Smaller numeric values indicate higher priority.
# Unique identifier{{snd}}MAC address-based selection is used as a tiebreaker when all other properties are equal.

IEEE 1588-2002 uses a selection algorithm based on similar properties.

Clock properties are advertised in IEEE 1588-2002 ''Sync'' messages and in IEEE 1588-2008 ''Announce'' messages. The current leader transmits this information at regular interval. A clock that considers itself a better leader will transmit this information in order to invoke a change of leader. Once the current leader recognizes the better clock, the current leader stops transmitting ''Sync'' messages and associated clock properties (''Announce'' messages in the case of IEEE 1588-2008) and the better clock takes over as leader.<ref>{{citation |url=https://cdn.selinc.com/assets/Literature/Publications/Technical%20Papers/6650_UnderstandingApplying_SA_20140206_Web3.pdf |title=Understanding and Applying Precision Time Protocol |first1=Steve T.|last1=Watt |first2=Shankar|last2=Achanta |first3=Hamza|last3=Abubakari |first4=Eric|last4=Sagen |date=March 2014 |access-date=2017-09-09}}</ref> The BMCA only considers the self-declared quality of clocks and does not take network link quality into consideration.<ref>{{citation |url=http://www.fsmlabs.com/news/2015/09/18/socalledbestmasterclock.html |title=Smart and Dumb PTP Client and the "so-called"Best Master Clock Algorithm |author=FSMLabs Technical Staff |date=September 2015 |access-date=2018-05-17}}</ref>

==Synchronization==
Via BMCA, PTP selects a source of time for an IEEE 1588 domain and for each network segment in the domain.

Clocks determine the offset between themselves and their leader.<ref name="IEC">[[International standard]] IEC 61588: Precision clock synchronization protocol for networked measurement and control systems. 2004.</ref> Let the variable <math>t</math> represent physical time. For a given follower device, the offset <math>o(t)</math> at time <math>t</math> is defined by:

:<math>\ o(t) = s(t) - m(t)</math>

where <math>s(t)</math> represents the time measured by the follower clock at physical time <math>t</math>, and <math>m(t)</math> represents the time measured by the leader clock at physical time <math>t</math>.

The leader periodically broadcasts the current time as a message to the other clocks. Under IEEE 1588-2002 broadcasts are up to once per second. Under IEEE 1588-2008, up to 10 per second are permitted.

[[File:IEEE1588 timing.svg|center|thumb|549px|IEEE 1588 synchronization mechanism and delay calculation]]

Each broadcast begins at time <math>T_1</math> with a ''Sync'' message sent by the leader to all the clocks in the domain. A clock receiving this message takes note of the local time <math>T_1'</math> when this message is received.

The leader may subsequently send a multicast ''Follow_Up'' with accurate <math>T_1</math> timestamp. Not all leaders have the ability to present an accurate timestamp in the ''Sync'' message. It is only after the transmission is complete that they are able to retrieve an accurate timestamp for the ''Sync'' transmission from their network hardware. Leaders with this limitation use the ''Follow_Up'' message to convey <math>T_1</math>. Leaders with PTP capabilities built into their network hardware are able to present an accurate timestamp in the ''Sync'' message and do not need to send Follow_Up messages.

In order to accurately synchronize to their leader, clocks must individually determine the network transit time of the ''Sync'' messages. The transit time is determined indirectly by measuring round-trip time from each clock to its leader. The clocks initiate an exchange with their leader designed to measure the transit time <math>d</math>. The exchange begins with a clock sending a ''Delay_Req'' message at time <math>T_2</math> to the leader. The leader receives and timestamps the ''Delay_Req'' at time <math>T_2'</math> and responds with a ''Delay_Resp'' message. The leader includes the timestamp <math>T_2'</math> in the ''Delay_Resp'' message.

Through these exchanges a clock learns <math>T_1</math>, <math>T_1'</math>, <math>T_2</math> and <math>T_2'</math>.

If <math>d</math> is the transit time for the ''Sync'' message, and <math>\tilde{o}</math> is the constant offset between leader and follower clocks, then

:<math>\ T_1' - T_1 = \tilde{o} + d \text{ and } \ T_2' - T_2 = - \tilde{o} + d</math>

Combining the above two equations, we find that

:<math>\tilde{o} = \frac 1 2 (T_1'-T_1-T_2'+T_2)</math>

The clock now knows the offset <math>\tilde{o}</math> during this transaction and can correct itself by this amount to bring it into agreement with their leader.

One assumption is that this exchange of messages happens over a period of time so small that this offset can safely be considered constant over that period. Another assumption is that the transit time of a message going from the leader to a follower is equal to the transit time of a message going from the follower to the leader. Finally, it is assumed that both the leader and follower can accurately measure the time they send or receive a message. The degree to which these assumptions hold true determines the accuracy of the clock at the follower device.<ref name="1588-2008"/>{{rp|Clause 6.2}}

==Optional features==
IEEE 1588-2008 standard lists the following set of features that implementations may choose to support:
*Alternate Time-Scale
*Grand Master Cluster
*Unicast Masters
*Alternate Master
*Path Trace

IEEE 1588-2019 adds additional optional and backward-compatible features:<ref name="Arnold 2017"/>
*Modular transparent clocks
*Special PTP ports to interface with transports with built-in time distribution
*Unicast ''Delay_Req'' and ''Delay_Resp'' messages
*Manual port configuration overriding BMCA
*Asymmetry calibration
*Ability to utilize a physical layer frequency reference (e.g. [[Synchronous Ethernet]])
*Profile isolation
*Inter-domain interactions
*Security TLV for integrity checking
*Standard performance reporting metrics
*Slave port monitoring

==Related initiatives==
*The ''International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication'' (ISPCS) is an IEEE-organized annual event that includes a [[Engineering:Plugtest|plugtest]] and a conference program with paper and poster presentations, tutorials and discussions covering several aspects of PTP.<ref>[http://www.ispcs.org ISPCS website]</ref>
*The Institute of Embedded Systems (InES) of the Zurich University of Applied Sciences/ZHAW is addressing the practical implementation and application of PTP.
*IEEE 1588 is a key technology in the LXI Standard for Test and Measurement communication and control.
*IEEE 802.1AS-2011 is part of the IEEE [[Audio Video Bridging]] (AVB) group of standards.{{efn|AVB is further extended by the IEEE 802.1 [[Time-Sensitive Networking]] (TSN) Task Group.}} It specifies a profile for use of IEEE 1588-2008 for time synchronization over a virtual bridged local area network as defined by [[IEEE 802.1Q]]. In particular, 802.1AS defines how [[IEEE 802.3]] ([[Ethernet]]), [[IEEE 802.11]] ([[Wi-Fi]]), and [[Engineering:Multimedia over Coax Alliance|MoCA]] can all be parts of the same PTP timing domain.<ref>{{citation |url=https://www.itu.int/dms_pub/itu-t/oth/06/38/T06380000040002PDFE.pdf |title=IEEE 802.1AS and IEEE 1588 |author=Geoffrey M. Garner |date=28 May 2010}}</ref>
*SMPTE 2059-2 is a PTP profile for use in synchronization of broadcast media systems.<ref>{{Citation |url=https://www.smpte.org/news-events/news-releases/smpte%C2%AE-publishes-first-two-parts-standard-enabling-deployment-ptp-timed |title=SMPTE Publishes First Two Parts of Standard Enabling Deployment of PTP-Timed Equipment in Existing SDI Plants |publisher=Society of Motion Picture and Television Engineers |date=2015-04-13 |access-date=2015-05-21}}</ref>
*The [[AES67]] audio networking interoperability standard includes a PTPv2 profile compatible with SMPTE ST2059-2.<ref>{{citation |url=http://www.aes.org/publications/standards/search.cfm?docID=105 |title=AES-R16-2016: AES Standards Report - PTP parameters for AES67 and SMPTE ST 2059-2 interoperability |date=2016-05-02 |publisher=[[Organization:Audio Engineering Society|Audio Engineering Society]]}}</ref> 
*[[Dante (networking)|Dante]] uses PTPv1 for synchronization.<ref name=coveloz2016>https://www.smpte.org/sites/default/files/users/user27446/AES67%20for%20Audio%20Production-Background%20Applications%20and%20Challenges.pdf </ref>
*[[Q-LAN]]<ref>{{cite web |title=PTPv2 Timing protocol in AV networks |work=Luminex |url=https://www.luminex.be/improve-your-timekeeping-with-ptpv2/ |date=6 June 2017 |quote=Q-LAN updated to PTPv2 approximately two years ago. |last1=Oyen |first1=Seppe }}</ref> and [[Ravenna (networking)|RAVENNA]]<ref name=coveloz2016/> use PTPv2 for time synchronization.
*[[The White Rabbit Project]] combines [[Synchronous Ethernet]] and PTP.
*[[Precision Time Protocol Industry Profile]] PTP profiles (L2P2P and L3E2E) for industrial automation in IEC 62439-3
*IEC/IEEE 61850-9-3 PTP profile for substation automation adopted by IEC 61850
*[[Parallel Redundancy Protocol]] use of PTP profiles (L2P2P and L3E2E) for industrial automation in parallel networks
*PTP is being studied to be applied as a secure time synchronization protocol in power systems' Wide Area Monitoring<ref>{{citation |doi=10.23919/AEIT.2018.8577414 |chapter=A reliable architecture based on Precision Time Protocol for WAMPAC synchronization |date=2018-12-17 |publisher=IEEE|title=2018 AEIT International Annual Conference |last1=Pepiciello |first1=Antonio |last2=Vaccaro |first2=Alfredo |pages=1–5 |isbn=978-8-8872-3740-5 |s2cid=58819556 }}</ref>

==See also==
* {{Annotated link|List of PTP implementations}}
* {{Annotated link|Real-time communication}}

==Notes==
{{Notelist}}

==References==
{{Reflist}}

==External links==
* [https://www.nist.gov/el/intelligent-systems-division-73500/ieee-1588 NIST IEEE 1588 site]
* [https://web.archive.org/web/20131206102327/http://www.zhaw.ch/en/engineering/institutes-centres/ines/downloads/documents.html PTP documentation at InES]
* [https://www.albedotelecom.com/src/lib/WP-Mobile-PTP.pdf PTP and Synchronization of LTE mobile networks] 
*[https://www.albedotelecom.com/src/lib/WP-PTP.pdf PTP explained under the installation / maintenance point of view]
* [https://web.archive.org/web/20110818184219/http://www.belden.com/pdfs/Techpprs/Precision_Clock_Synchronization_WP.pdf Hirschmann PTP Whitepaper]
* [https://www.cisco.com/c/en/us/td/docs/switches/connectedgrid/cgs2520/software/release/12_2_58_ey/configuration/cgs_2520_swcg.html#wp1988925 PTP overview in Cisco CGS 2520 Switch Software Configuration Guide]
* [https://web.archive.org/web/20160304192052/http://www.bcit.ca/files/appliedresearch/pdf/ruggedcom_industry.pdf Perspectives and priorities on RuggedCom Smart Grid Research IEC 61850 Technologies]
* [https://web.archive.org/web/20120114222001/http://xn--61850-txen0l.xn--p1ai/wp-content/plugins/downloads-manager/upload/Introduction%20of%20Smart%20Subsltation%20Projects.pdf Projects with Smart Substation Solution]
* {{Citation|doi=10.1109/SMARTGRID.2010.5622092|isbn=978-1-4244-6510-1|chapter=Smart High Voltage Substation Based on IEC 61850 Process Bus and IEEE 1588 Time Synchronization|title=2010 First IEEE International Conference on Smart Grid Communications|year=2010|last1=McGhee|first1=Jim|last2=Goraj|first2=Maciej|pages=489–494|s2cid=30638718}}
* {{Cite book|date=2011 |doi=10.1109/PTC.2011.6019243 |chapter-url=https://eprints.qut.edu.au/41257/ |publisher=IEEE |location=Trondheim, Norway|first1=D.M.E|last1=Ingram |first2=D.A.|last2=Campbell |first3=P.|last3=Schaub |first4=G.F.|last4=Ledwich|title=2011 IEEE Trondheim PowerTech |chapter=Test and evaluation system for multi-protocol sampled value protection schemes |pages=1–7 |isbn=978-1-4244-8419-5 |s2cid=42991214 }}
* [https://safran-navigation-timing.com/solution/white-rabbit-solutions/ The White Rabbit Project PTP]
* [https://web.archive.org/web/20170205095756/http://lamspeople.epfl.ch/kirrmann/Pubs/IEC_62439-3/PacWorld_038_043_IEC_IEEE_61850-9-3_September_2016_HK.pdf IEC&IEEE Precision Time Protocol]'', Pacworld, September 2016''
* [https://webstore.iec.ch/publication/24447 IEC 62439-3 Annexes A-E Redundant attachment of clocks and network management]
*[https://www.luminex.be/improve-your-timekeeping-with-ptpv2-2/ PTPv2 Timing protocol in AV networks]
*[https://www.fsmlabs.com/news/2016/03/31/singlesource.html FSMLabs: Single source IEEE PTP 1588 cannot meet financial regulatory standards]
*[https://blog.albedotelecom.com/ptp-testing-guide/ A PTP Testing Guide for Reliable and Accurate Verification] by Fran Hens (ALBEDO 2019)

{{IEEE standards}}

[[Category:Synchronization]]
[[Category:IEEE standards]]
[[Category:Network time-related software]]
[[Category:Network protocols]]
[[Category:Application layer protocols]]

{{Sourceattribution|Precision Time Protocol}}