The goal of this protocol is to have a set of slave devices determine the offset between time measurements on their clocks and time measurements on a master device. [2] Let the variable t represent physical time. For a given slave device, the offset o(t) at time t is defined by:
where s(t) represents the time measured on the slave device's clock at physical time t, and m(t) represents the time measured on the master device's clock at physical time t.
In the protocol, the master device periodically launches an exchange of messages with slave devices to help each slave clock recompute the offset between its clock and the master's clock. This offset will drift with time, and so these periodic exchanges mitigate the impact of this drift on clock synchronization. One assumption is that this exchange of messages happens over a period of time so small that this offset can safely be considered constant. Another assumption is that the transit time of a message going from the master to a slave is equal to the transit time of a message going from the slave to the master. Finally, it is assumed that both the master and slave can measure the time they send or receive a message. The degree to which these assumptions are enforced in an application regulate the accuracy of the offset measured at a slave device.
Each message exchange begins with a multicast SYNC message sent by the master clock to all the slaves listening on the PTP multicast group. A slave receiving this message takes note of the time T2 measured on its clock when it receives this message.
The master next sends a multicast TIME T1 message to notify the slaves of time T1 when it sent the SYNC message. Each slave now knows T1 and T2.
If d is the transit time of this message, and
is the constant offset during this transaction, then
Each slave now sends a RESPONSE message back to the master. For implementation reasons, this message is implemented as a multicast message, but it is a directed multicast message in that the packet containing this message includes information about the master it is being sent to. The slave measures the time T3 that it sends this message, and the master measures the time T4 that it receives this message. The master then sends a directed multicast TIME T4 message back to the slave to notify the slave what time it received the RESPONSE message. Note that
The slave now knows times T1, T2, T3, and T4. Combining the above two equations, we find that

The slave now knows the offset
during this transaction. While this offset will drift with time, it will be corrected the next time this exchange of transactions is launched.
0x88F7 is used as EtherType for PTP over Ethernet.
IEEE 1588-2008
Also known as IEEE 1588 Version 2, an updated version of the standard was approved in March 2008. The new version adds the following enhancements:[3]
- Transparent clocks through 1588-aware network equipment for improved accuracy
- Reduced size sync messages
- Protocol support for improved precision
- Layer 2 transport option
- Unicast transport option
- Fault tolerance support
- Rapid reconfiguration in response to network changes
- Varied (faster) update rates
This new version of the standard is not directly interoperable with the previous version.
Related initiatives
The Institute of Embedded Systems (InES) of the University of Winterthur 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.
Kilde: Wikipedia, the free encyclopedia






