The PTP protocol (Precision Time Protocol) is designed for critical applications, offering more precise time synchronisation than other protocols.
Where NTP provides precision at the millisecond level, PTP delivers microsecond-level precision. Such precision is achieved with mechanisms that rely on the network’s capacity to handle synchronisation messages without introducing unpredictable delays. And yet network equipment (switches and routers) introduces exactly this type of delay. The transparent clock is the mechanism provided for by standard IEEE 1588 to address this problem.
Why does a switch affect PTP precision?
To understand why a transparent clock is useful, we first need to understand how PTP synchronisation works. A PTP client exchanges timestamped messages with a grandmaster or reference server. Based on the timestamps of these messages, it calculates the propagation delay on the network and works out the difference between its clock and the grandmaster’s clock. This calculation is based on the assumption that the propagation delay is stable in time.
The problem arises when there is an Ethernet switch on the path between the grandmaster and the client. Each synchronisation message is treated by the switch just like another network packet: it is received on an input port, placed in a queue, and then sent by the output port. The time spent in this queue depends on the volume of traffic. When the network is saturated, packet processing can be delayed and take several additional microseconds, without this being measured.
This variation in transit delay (Packet Delay Variation or PDV) will distort the propagation delay calculation performed by the PTP client. Worse still, the error can be magnified if there are several switches between the grandmaster and the client.
In some cases, PTP precision will deteriorate to the point that it is close to that obtained with NTP. In other words, without a compensation mechanism, deploying PTP on a standard network is not really worth it.
How does a transparent clock work?
A transparent clock is a PTP correction mechanism that is defined in version 2 of standard IEEE 1588, published in 2008. It is used to manage network equipment between the grandmaster and the clients that synchronises. The idea is to compensate for the variation in the transit delay of the network equipment by measuring its value. This measurement is then communicated to the client so that it can take it into account during synchronisation.
The principle is, in reality, very simple.
When a PTP message reaches the switch’s input port, the equipment notes the exact time of arrival. When this same message goes through the output port, it notes the departure time. The difference between the two corresponds to the time spent in the equipment, i.e., the variable delay that we need to compensate. The transparent clock enters this time in a specific field of the PTP message, known as the correction field.
The mechanism is cumulative. If the message passes through several successive transparent clocks, each one adds the time it takes for the message to pass through it to the correction field. When it receives the message, the client therefore has the sum of all the delays entered by the intermediate equipment. It just has the subtract this value from its time calculation to obtain a precise measurement.
It is known as a transparent clock because, thanks to the correction field, the network equipment is “invisible” to the synchronisation process.
But it is something of a misnomer. Indeed, it does not synchronise with the grandmaster itself, it merely measures a delay and annotates the messages.
Reliable synchronisation for your critical environments
Provide accurate and consistent synchronisation across all your equipment, without any drift.
Two variants: End-to-End and Peer-to-Peer
The PTP standard defines two methods for measuring the time between two pieces of equipment: the End-to-End method and the Peer-to-Peer method. The transparent clock manages both methods.
The End-to-End (E2E) transparent clock is the most common. It only measures the switch’s or the router’s transit delay and enters it in the correction field. Calculation of the total time between the grandmaster and the client remains entirely the client's responsibility. The client continues to exchange time measurement messages with the grandmaster, like a conventional PTP network. This clock, which depends on a type of equipment, is transparent and “passive”, as it does not modify how the synchronisation works, making it easy to deploy.
The Peer-to-Peer (P2P) transparent clock does more, but needs more advanced equipment. Indeed, in addition to the equipment’s transit delay, the P2P transparent clock also measures the propagation delay on the cable connecting it to the previous piece of equipment. For this, it exchanges specific measurement messages with neighbouring equipment, in peer-to-peer mode.
The correction field therefore takes into account both the equipment transit delay and the time it takes to transmit the information between the equipment. The benefit of this approach is that when the client receives a message, it doesn’t even need to exchange with the grandmaster to find out the time as the correction field contains all the information. The result is therefore potentially more precise.
Transparent Clock or Boundary Clock?
This is the question everyone asks when designing a PTP architecture. The two mechanisms respond to the same problem, each with a different solution.
The transparent clock allows PTP messages to pass through by annotating them. The boundary clock interrupts the PTP chain. First, it synchronises with the grandmaster like any client and then redistributes the time to the downstream equipment as if it were the grandmaster. It therefore cuts the PTP network into distinct segments.
The boundary clock has one important advantage for larger networks. With transparent clocks, each client exchanges its synchronisation messages directly with the grandmaster. As the number of clients increases, the grandmaster then becomes a bottleneck and can cause the synchronisation system to fail. With boundary clocks, each PTP switch deals with a subset of clients, thus distributing the load. The BMCA algorithm (Best Master Clock Algorithm) ensures that the best reference server is automatically selected in the event of failure.
The transparent clock, on the other hand, has the advantage of not introducing additional clocks into the synchronisation chain. A boundary clock is a separate clock: it synchronises with the grandmaster but, like any clock, has its own deviation.
The transparent clock avoids this deviation. For a moderately sized network, this is often the most appropriate approach. In practice, the two approaches are not mutually exclusive. For example, boundary clocks can be used at the structuring points of the network and transparent clocks in the access switches.
Key points for successful deployment
A PTP network only achieves its theoretical precision if each piece of equipment on the path between the grandmaster and the clients is PTP-compatible. This means that each switch must operate either as a transparent clock, or as a boundary clock. A switch that treats PTP messages as ordinary traffic would introduce a delay variation. A single piece of incompatible equipment is therefore enough to affect the precision of the whole system.
The second point concerns the quality of the timestamping in the switch. For the transit delay measurement to be reliable, timestamping must be done at hardware level. Timestamping at software level itself introduces variation, which reduces the benefit of the transparent clock. When a switch is chosen for PTP deployment, it is therefore necessary to check that the timestamping is integrated into the hardware.
Finally, the transparent clock solves the problem of delay variation in the equipment, but does not address the network asymmetry issue. This asymmetry stems from the fact that the time needed for an outbound message is not the same as that needed for an inbound message, for example because the physical paths are different. This problem is addressed at network design level and not at synchronisation protocol level.
