Meinberg PTP270PEX, Manual

Page: 11 / 23

Page 8 3 Precision Time Protocol (PTP) / IEEE1588
3.4.4 Two-Step or One-Step
The PTP protocol requires the master to periodically send SYNC messages to the slave devices. The hardware time
stamping approach of PTP requires that the master records the exact time when such a SYNC packet is going on
the network wire and needs to communicate this time stamp to the slaves. This can be achieved by either sending
this time stamp in a separate packet (a so-called FOLLOW-UP message) or by directly manipulating the outgo-
ing SYNC message, writing the hardware time stamp directly into the packet just before it leaves the network port.
At the time of delivery of this product, Meinberg devices support only the former approach, called Two-Step
(because two packets are required).
3.4.5 End-To-End (E2E) or Peer-To-Peer (P2P) Delay Measurements
In addition to receiving the SYNC/FOLLOWUP messages a PTP slave device needs to be able to measure the
network delay, i.e. the time it took the SYNC message to traverse the network path between the master and
the slave. This delay is required to correct the received time information accordingly and it is measured by the
slave in a congured interval (more about the message intervals later). A delay measurement is performed by
sending a so-called DELAY_REQUEST to the master which timestamps it and returns the timestamp in a DE-
LAY_RESPONSE message.
IEEE 1588-2008 oers two dierent mechanisms for performing the delay measurements. A slave can either
measure the delay all the way to the master, this is called End-To-End (or E2E in short) or to its direct network
neighbors (which would in almost all cases be a switch or two in a redundant setup), using the Peer-To-Peer
delay measurement mechanism (P2P). The delay measurements of all links between the master and the slave are
then added and accumulated while a SYNC packet is traversing the network.
The advantage of this method is that it can dramatically reduce the degradation of accuracy after topology
changes. For example: in a redundant network ring topology the network delay will be aected when the ring
breaks open and network trac needs to be redirected and ows into the other direction. A PTP slave in a sync
infrastructure using E2E would in this case apply the wrong delay correction calculations until it performs the
next delay measurement (and nds out that the network path delay has changed). The same scenario in a P2P
setup would see much less time error, because the delay of all changed network links were already available.
The drawback: the P2P approach requires that all involved PTP devices and all switches support this mech-
anism. A switch/hub without P2P support would in the best case simply pass the so-called PDELAY messages
through and as a result degrade the accuracy of the delay measurements. In the worst case it would block/drop
the PDELAY messages completely, which eectively would result in no delay measurements at all.
So, E2E is the only available choice if you are running PTP trac through non-PTP-aware switches. It is a
reasonable choice if you are not using redundant network topologies or can accept that the delay measurements
are wrong for a certain amount of time.
3.4.6 Mode Recommendations
Meinberg recommends to set up your PTP infrastructure to use Layer 3, Multicast, Two-Step and End-To-
End Delay measurements if that is possible. This will provide the largest possible compatibility and reduces
interoperability problems.
3.4.7 Message Rate Settings
The decision between the dierent general mode options is mainly dictated on the network environment in which
the PTP infrastructure is installed.
In addition to the mode selection, a number of intervals for certain types of PTP network messages needs to be
dened. In most cases, the default values as dened in the standard are a safe bet, but there are applications and
scenarios where a custom message rate is required.
A possible example is a situation where the PTP infrastructure is integrated within an environment with high
network load. In this case, the PTP packets can be aected by the eect of packet delay variation (PDV). An
increase of the PTP message rate(s) can avoid synchronization problems due to packet queuing within non-PTP
compliant switches which might cause false measurements. At higher rates, these false measurements can be
detected and corrected faster as compared to lower rates at the cost of increased trac.
8 Date: 22nd November 2012 PTP270PEX