To synchronise clocks across a local area network (LAN), it is necessary to measure the transmission delay caused by network’s technical and usage factors.
When a machine receives a message with a timestamp from a master clock, a delay is introduced due to the distance to this clock. Indeed, if a message travels along one metre of optical fibre, or crosses several different data centres, the transmission time may vary and introduce a variable delay. As a result, it is better to know this latency to synchronise a clock correctly.
What are the sources of latency in the PTP protocol?
There are many factors influencing latency on a network, including:
- The physical network. The latency introduced by this factor is static and controllable, since it only depends on hardware characteristics.
- The number of routers/switches traversed by the message.
- Network traffic. Indeed, a network packet can be blocked in a router or a switch because of very heavy traffic and the QoS (Quality of Service) rules implemented. This phenomenon is not common but it can generate significant latency.
Symmetric or asymmetric latency?
Latency can be symmetric or asymmetric. If the latency is asymmetric, it is more difficult to obtain the maximum accuracy. The PTP protocol (Precision Time Protocol) is known for being one of the most accurate protocols. It features a built-in mechanism for calculating the delay and adjusting its clock during a synchronisation. It is also equipped with a specific field (the correction field) which makes the protocol robust to asymmetric latencies.
Calculation of latency in the PTP protocol or how to adjust the latency of receiving servers?
The PTP latency calculation mechanism uses SYNC, FOLLOW_UP, DELAY_REQ and DELAY_RESP messages.
The server wishing to synchronise its client clocks sends a SYNC message to start synchronisation. The message is sent at t1 timestamp. The client receives the message at t2 time. If the server is not able to send the t1 timestamp directly in the SYNC message, it will send a FOLLOW_UP message shortly afterwards along with the t1 timestamp so that the client is informed.
Then, the client sends a DELAY_REQ message to the server at t3 time. The server will receive this message at t4 time. The latter will resend the DELAY_RESP message to the client at t4’ time.
Therefore, the client can calculate the back and fourth delay between the server and itself and use this delay to adjust its clock during synchronisation.
This exchange of messages is illustrated in figure 1 - Delay calculation mechanism in the PTP protocol
At the right of the receiver (Slave Clock) we can see the timestamps known by the receiver after each message received/sent.
With these four timestamps, the receiver is able to calculate the transmission delay between the generating server (Master Clock) and itself, and use this calculation to correct the delay.
To do so, it calculates an offset that it will apply to its clock. This offset is ½ (t2 – t1 – t4 + t3). The calculation is correct if the delay is symmetric.
Applications within a PTP network infrastructure
Sometimes, the delay is not symmetric. This is the case when exchanges between the server and the PTP client pass through several routers or switches that are not compatible with PTP. Each device analyses the packet to propagate it across the network. This processing time results in an additional delay, which is not the same for each packet.
In the case of a PTP network infrastructure, two key peripheral devices enable time to be distributed to the various devices, ensuring accurate synchronisation:
- The Boundary Clock (BC). This device acts as a time reference for receiving devices. It is able to generate synchronisation packets itself.
- The Transparent Clock (TC). This device measures the time required for a packet to traverse the network. The TC will add this propagation time in the correction field. The client then knows the part of the dynamic delay attributable to message processing times and can take this into account to synchronise its clock with that of the server.
In a PTP network infrastructure, each component plays an essential role. It is then necessary to prepare and define the architecture meticulously to ensure reliable and consistent time synchronisation across the network.
With more than 150 years of expertise in time management and present in more than 140 countries, Bodet Time is a major French leader in time synchronisation and time frequency. Our Netsilon PTP time servers allow synchronisation of all equipment present on a network in a secure way.