2 Using PTP Messages for Time Synchronization

Any time aware network segment will contain one clock source, either a bridge or the grandmaster. The clock source uses PTP messages to distribute its clock to its clock followers, as shown in Figure 2-1. The clock source will periodically send a PTP Sync message, which contains the timestamp when the packet was assembled. Since there will be some delay between assembling of the packet and its transmission as the packet moves through various software layers and hardware buffers, the timestamp contained in the assembled Sync packet is not the exact transmission time. All time aware devices contain hardware which can capture the required timestamps. The timestamp for the Sync packet is then provided later in a Follow_up packet. In some cases, the MAC is able to update the original timestamp in the Sync packet to the correct value while it is going through the MAC; in this case no Follow_up packet is needed. To indicate that a Followup_up packet will be sent, the twoStepFlag bit will be set it the flagField of the Sync packet.

Figure 2-1. PTP Message Timing Example

When the clock follower detects a Sync packet, it will capture a timestamp based on its own wallclock. Even on a simple local network segment, there will always be some delay between the clock source and clock follower. This delay includes the propagation time for the signal to traverse the network, as well as any delays caused by electronic components or buffers in hardware. To determine the total delay, the clock follower requires more information. To acquire this information, PTP uses two more message types with corresponding timestamps. The follower sends a Pdelay_request message to the clock source and captures a timestamp when the message is transmitted. The clock source will return a Pdelay_response message which contains the clock source timestamp taken when the Pdelay_Request is received.

At the end of this set of messages, the follower has received two timestamps from the clock source: tSYNC_TX, the time that the Sync message was sent and tPDR_RX, which is when the clock source received the Pdelay_Req packet. The follower has also captured two timestamps based on its own local clock, tSYNC_RX, when it received the Sync packet and tPDR_TX, when it transmitted the Pdelay_Req. Assuming a symmetric and constant delay, it is possible to calculate the propagation delay and the error in the local clock from these four timestamps using the following formulas:

Equation 2-1. 
tPD=((tPDR_RX −tSYNC_TX )−(tPDR_TX  −tSYNC_RX ))/2
Equation 2-2. 
Clock Error =(tSYNC_RX −tSYNC_TX )− tPD 

As an example, using the values in Figure 2-1

tPD=(20s − 10s)/2((12:00:25 − 12:00:05) − (12:00:30 − 12:00:20 ) )/2  =(20s − 10s)/2 =5s
Clock Error =(12:00:20 − 12:00:05)−5s =15s − 5s=10s

Modifications Needed to Support Multidrop and PLCA

At the time of publication, networking standards do not yet consider multidrop network segments to be “time-aware” and standard software implementations do not provide full support for multidrop networks. The PDelay messages are currently defined as broadcast messages. If multiple devices on a multidrop segment send PDelay_req messages and each uses the broadcast address, it will be unclear which device sent the message and which device needs to return the timestamp response. If PDelay messages are used, software must be customized to support multiple nodes generating these messages, and the clock source must capture multiple timestamps and return each to the proper requesting device. These exact modifications are software dependent and are beyond the scope of this application note.

The standards also assume that the timestamp is taken when a first nibble following the Start-of-Frame Delimiter (SFD) leaves the MAC, but the elastic buffer of PLCA causes a small bounded but variable delay through the PHY. To achieve a constant delay, transmit timestamps need to be taken in the PHY; as long as the propagation delay remains constant, it does not matter exactly where it is taken. To achieve a symmetric delay for transmit and receive, receive timestamps also need to be taken at the PHY. The LAN8650/1includes hardware support to allow timestamps to be taken when the packet is actually being transmitted. Based on this hardware, here are two propagation delay options that could be implemented:

  • Determine (by measurement, simulation, or theoretical calculation) the peer delay between the clock source and every other node on the mixing segment and use this as a fixed value directly in Equation 2-2. If the propagation delay is significantly smaller than the required timestamp precision, it may even be ignored and compensated for by the error correction. This method only uses Sync messages, which are only transmitted from the clock source and can continue to use broadcast address.
    • Timestamp that must be captured on the clock source - Sync transmit
    • Timestamp that must be captured on the clock follower- Sync receive
  • Determine propagation delay using Equation 2-1 after modifying the software to work around the broadcast issue for PDelay _Req and PDelay_Resp.
    • Timestamps that must be captured on the clock source - Sync transmit, PDelay_Req receive
    • Timestamp that must be captured on the clock follower - Sync receive, PDelay_Req transmit

Synchronizing the Wall Clock of the Clock Follower

Wall clocks are implemented as counters, as shown in Figure 2-2. Its time can be set or changed by writing to a set of registers. After a clock has been set, it continuously updates based on a local oscillator. The amount that a wall clock increments per oscillator tick is also controlled by one or more increment registers. These increment registers enable control down to sub-nanosecond resolution; this precision is needed to compensate for the frequency drift of the local oscillator. Wall clocks often also have an additional register that allows a one time addition or subtraction of an adjustment to the clock value; this register would allow a clock that is a few nanoseconds fast or slow to be corrected in a single tick of the local oscillator.
Figure 2-2. Block Diagram of a Wall Clock Plus Oscillator
Once the error between the follower's wallclock and the clock source is determined from PTP messages, the wall clock needs to be updated to drive the error to zero. A simple way to do this would be to update the wall clock once per Sync message to eliminate the clock error. While this method is straightforward, it results in an error that is based on the time required to process the inbound messages and write the update to the wall clock. Figure   5 shows the clock error over the first second from a simulation using random timing for the clock updates based on a realistic model of the LAN8650/1. Because the register updates are done over the same Serial Peripheral Interface (SPI) used to transmit Ethernet packets, there is a significant variation in write times, which results in the large variation in clock error.
Figure 2-3. Local Clock Error when Updating the Clock Time

Even in devices that do not use SPI, updating the clock value alone does not produce reliable synchronization. No matter how accurate the timestamp and the propagation delay on the transmission line can be evaluated, the local clock will not be completely synchronized with the clock source. This is due to the delay between obtaining the last timestamp and updating the local clock, including the time required to calculate the updated value. Any time variation in this procedure will further add jitter to the clock error. As a result, setting clock time directly is normally only done once to set the initial clock value.

Another method to adjust the clock is to adjust once per Sync message. A simulated example of this is shown in Figure 2-4. Using this method will cause an immediate shift in the wall clock and may result in timestamps being slightly out of sequence but, for systems can tolerate such clock jitter, this easy-to-implement method may be all that is required.

Figure 2-4. Local Clock Error Using only Phase Adjust
Instead of trying to update the clock each time a Sync message is received, most synchronization algorithms modify the registers which contain the amount of time the wall clock increments per tick of the local oscillator. The simulation results in Figure 2-5, which use the same update delay jitter as above, show that modifying this increment once per Sync message enables the local wall clock to be quickly synchronized to the clock source. In this simulation, the value that the increment is updated is based on a filtered value of the error.
Figure 2-5. Local Clock Error when Updating the Increment

Algorithms designed to synchronize and maintain clocks vary greatly. Simple ones, used in systems with minimal clock skew, require only filtered values of the clock error. Other algorithms will also analyze the rate ratio, that is, the time difference between successive Sync message timestamps on the source and local clocks. More complicated clock servo algorithms add Proporitonal-Integral (PI) or Proportional–Integral–Derivative (PID) control loops based on both of clock error and rate ratio, and use a combination of adjusting the increment when error is small with one-time clock adjustments when the error is larger. Most algorithms use all three methods of adjusting the clock; the exact method used depends on recent error history.