Precision Time Protocol (PTP) Synchronization
Precision Time Protocol (PTP) is a network protocol used to synchronize clocks throughout a
computer network. It is defined in the IEEE 1588 standard, also known as the "Standard for a
Precision Clock Synchronization Protocol for Networked Measurement and Control Systems." PTP is
widely used in scenarios where precise time synchronization is crucial, such as telecommunications,
industrial automation, power systems, and financial trading networks.
1. Basic Concept of PTP
PTP works by exchanging timing messages between a master clock and one or more slave clocks to
achieve clock synchronization. The protocol enables synchronization accuracy in the sub-
microsecond range, which is much more precise than the Network Time Protocol (NTP).
The synchronization is achieved through a series of message exchanges that measure the time it
takes for messages to travel from the master to the slave and vice versa. The protocol accounts for
these transmission delays to align the clocks accurately.
2. Key Components of PTP
• Master Clock: The clock that serves as the reference time source. It is selected based on a
clock selection algorithm that considers clock quality, stability, and configuration.
• Slave Clock: The clock that synchronizes its time to the master clock.
• Ordinary Clock (OC): A device with a single PTP port that can act as either a master or a slave
clock.
• Boundary Clock (BC): A device with multiple PTP ports, which synchronizes itself to a master
clock and can act as a master clock to other devices.
• Transparent Clock (TC): A network device that measures the time it takes for PTP messages
to pass through it, adding that information to the messages to improve accuracy.
3. PTP Synchronization Process
PTP achieves synchronization using several types of messages exchanged between clocks:
1. Sync Message: Sent periodically by the master clock to the slave clocks, containing the
precise time the message was sent.
2. Follow-Up Message: Sent by the master clock immediately after the Sync message, providing
additional timing information, such as the exact transmission time of the Sync message.
3. Delay Request (Delay_Req) Message: Sent by the slave clock to the master clock to measure
the delay in the path.
4. Delay Response (Delay_Resp) Message: Sent by the master clock in response to the Delay
Request, containing the reception timestamp of the Delay Request message.
By using these four messages, the slave clock can calculate the round-trip delay and synchronize its
clock to the master clock with high precision.
4. PTP Communication Protocol and Message Format
PTP messages are generally transmitted over Ethernet using the following communication
mechanisms:
• Transport Protocol: PTP typically uses Ethernet (Layer 2) or UDP over IP (Layer 3). Layer 2
PTP messages are not routable across networks, while Layer 3 messages can traverse
routers.
• Multicast vs. Unicast: PTP messages can be transmitted using multicast or unicast
communication. Multicast is more efficient in large networks with multiple slaves, while
unicast may be preferred in simpler networks to reduce traffic.
PTP Message Format
PTP messages have a specific format defined in the IEEE 1588 standard. Each PTP message consists of
a header and a body, and different message types have different body contents.
• Common Header Fields:
o messageType: Identifies the PTP message type (e.g., Sync, Follow_Up, Delay_Req,
Delay_Resp).
o versionPTP: Indicates the PTP version.
o messageLength: Specifies the total length of the PTP message.
o domainNumber: Indicates the PTP domain to which the message belongs.
o flagField: Contains various flags relevant to the message type.
o correctionField: Contains corrections to the message's timestamp to account for
transmission delays.
o sourcePortIdentity: Identifies the source of the message.
• Body Fields: Each message type has specific body fields. For example, the Sync message has a
field for the precise origin timestamp.
5. Implementing PTP on Microcontroller Hardware
Implementing PTP on a microcontroller involves using the microcontroller's Ethernet interface and
internal timers to send and receive PTP messages and adjust its clock accordingly. This requires both
hardware support for timestamping Ethernet frames and software to handle the PTP protocol.
Here is an example of how you might implement basic PTP functionality in C for a microcontroller
with an Ethernet interface:
Example C Code for PTP on Microcontroller
This example assumes the microcontroller has hardware support for Ethernet communication and
timestamping.
#include <stdint.h>
#include <stdio.h>
#include <string.h>
// PTP message types
#define PTP_SYNC 0x00
#define PTP_FOLLOW_UP 0x08
#define PTP_DELAY_REQ 0x01
#define PTP_DELAY_RESP 0x09
// PTP header structure
typedef struct {
uint8_t messageType;
uint8_t versionPTP;
uint16_t messageLength;
uint8_t domainNumber;
uint8_t flagField;
uint64_t correctionField;
uint8_t sourcePortIdentity[10];
uint16_t sequenceId;
uint8_t controlField;
int8_t logMessageInterval;
} PTPHeader;
// Function to send PTP Sync message
void sendPTPSync() {
PTPHeader syncMsg;
memset(&syncMsg, 0, sizeof(syncMsg));
[Link] = PTP_SYNC;
[Link] = 2; // PTP version 2
[Link] = sizeof(syncMsg);
// Set other header fields as necessary
[Link] = 0; // Example sequence ID
// send the message over Ethernet
// sendEthernetFrame((uint8_t*)&syncMsg, [Link]);
printf("PTP Sync message sent.\n");
// Function to handle received PTP messages
void handlePTPMessage(uint8_t* buffer, uint16_t length) {
PTPHeader* ptpHeader = (PTPHeader*)buffer;
switch (ptpHeader->messageType) {
case PTP_SYNC:
printf("Received PTP Sync message.\n");
// Extract and process sync message data
break;
case PTP_FOLLOW_UP:
printf("Received PTP Follow-Up message.\n");
// Extract and process follow-up message data
break;
case PTP_DELAY_REQ:
printf("Received PTP Delay Request message.\n");
// Extract and process delay request message data
break;
case PTP_DELAY_RESP:
printf("Received PTP Delay Response message.\n");
// Extract and process delay response message data
break;
default:
printf("Unknown PTP message type.\n");
break;
}
// Main function
int main() {
// Example code to send Sync message and handle received messages
sendPTPSync();
// Simulate receiving a PTP message
uint8_t receivedBuffer[128]; // Example buffer
uint16_t receivedLength = 128; // Example length
handlePTPMessage(receivedBuffer, receivedLength);
return 0;
}
Precision Time Protocol (PTP) can be implemented over various communication systems beyond
Ethernet, though Ethernet is the most common due to its wide adoption and built-in support for PTP.
Implementing PTP over other communication systems such as RS-485, ARINC 429, or others requires
adaptations in the protocol's implementation due to differences in communication characteristics
and message handling.
Implementing PTP Over Different Communication Systems
1. RS-485
RS-485 is a standard for serial communication that is often used for long-distance and multi-drop
communication in industrial settings. Implementing PTP over RS-485 involves several key
considerations:
• Timing Precision: RS-485 is typically used in environments where timing is less critical, and its
baud rates and synchronization capabilities might not be as precise as Ethernet.
• Protocol Adaptation: PTP messages need to be encapsulated in a way that suits RS-485's
serial nature. This involves handling message framing, addressing, and error detection.
Example Adaptation Steps:
1. Message Framing: RS-485 doesn't have the concept of message length like Ethernet frames.
You would need to define a custom frame structure with start and end delimiters.
2. Addressing: RS-485 is often used in multi-drop configurations, so you need to handle
addressing to ensure messages reach the correct devices.
3. Synchronization: Implementing high-precision time synchronization over RS-485 may be
challenging due to the lack of hardware timestamping and higher latency compared to
Ethernet.
2. ARINC 429
ARINC 429 is a data bus standard used in avionics for transmitting data between avionics systems. It
has a specific protocol for data transmission and is typically used for aircraft communication systems.
• Timing Characteristics: ARINC 429 is not designed for real-time clock synchronization, but
with appropriate modifications, it could be adapted for PTP-like functionality.
• Message Format: ARINC 429 messages are transmitted in a predefined format with a fixed
length and parity checking. Adapting PTP to ARINC 429 requires encoding PTP messages into
the ARINC 429 format and handling the data transmission protocol.
Example Adaptation Steps:
1. Encoding: PTP messages would need to be encoded into the ARINC 429 format, ensuring that
the message length and data fields fit within ARINC's constraints.
2. Synchronization: ARINC 429 does not have built-in mechanisms for timestamping or high-
precision synchronization, so additional software or hardware support may be needed.
3. Other Communication Systems
Other communication systems, such as CAN bus or Modbus, can also be adapted for PTP with similar
considerations:
• CAN Bus: Known for its robustness in automotive and industrial applications, but with lower
data rates and message length constraints compared to Ethernet. Adapting PTP to CAN bus
involves handling message framing and synchronization protocols within the constraints of
the CAN protocol.
• Modbus: Primarily used for communication in industrial environments. Adapting PTP to
Modbus would involve similar considerations for message framing and addressing.
General Steps for Adapting PTP to Non-Ethernet Systems
1. Message Framing: Define how PTP messages will be framed and delimited according to the
communication system's characteristics.
2. Timestamping: Implement mechanisms for timestamping messages if the communication
system does not support hardware timestamping. This may involve software-based
timestamping with associated delays.
3. Error Handling: Ensure that message integrity and error detection mechanisms are in place,
as different communication systems have different methods for detecting and handling
errors.
4. Synchronization Algorithms: Adapt the PTP synchronization algorithms to work with the
characteristics of the chosen communication system, including adjusting for any additional
delays or latencies.
Dealing with Clock Drift in PTP
1. Regular Synchronization Updates
PTP handles clock drift primarily through regular updates from the master clock to the slave clocks.
The Sync and Follow-Up messages ensure that slaves frequently adjust their clocks based on the
most recent information from the master clock.
o Sync Message: Sent periodically by the master clock, it provides a timestamp
indicating the time at which the Sync message was sent.
o Follow-Up Message: Sent immediately after the Sync message, it provides additional
timestamp information to correct for network delays and precise synchronization.
2. Delay Measurement and Compensation
To handle clock drift effectively, PTP calculates and compensates for network delays through the use
of Delay Request and Delay Response messages.
o Delay Request Message: Sent by the slave clock to request the master’s timestamp
when the Delay Request was received.
o Delay Response Message: Sent by the master clock in response to the Delay
Request, containing the timestamp of receipt.
The round-trip delay calculated from these messages helps in adjusting the clock offset and
compensating for the network transmission time.
3. Clock Correction Mechanism
PTP includes mechanisms to correct the clock offset and drift. The offset correction is applied to the
slave clock’s time based on the calculated difference between the master and slave clocks.
o Correction Field: PTP messages contain a correction field that helps account for
network delays and clock drift by adjusting the time reported in Sync messages.
4. Adaptive Synchronization
PTP can adapt to changing network conditions and clock drifts through its adaptive synchronization
algorithm. The algorithm continuously updates the slave clock based on the most recent
measurements and corrections.
5. High Precision Timestamps
PTP systems often use hardware timestamping to achieve higher precision. By using hardware
support for timestamping packets as they are transmitted and received, PTP reduces the impact of
software-induced delays and improves accuracy.
Detailed Steps for Handling Clock Drift
1. Initial Synchronization:
o When a slave clock first synchronizes with a master clock, it measures the time offset
using the Sync and Follow-Up messages and adjusts its clock accordingly.
2. Ongoing Adjustment:
o The slave clock continuously receives Sync messages from the master clock at regular
intervals. It calculates the time offset and drift based on these messages and adjusts
its time to stay synchronized.
3. Compensating for Drift:
o PTP calculates the time drift by comparing the current offset with historical data. If
the clock drift is significant, it adjusts the clock offset more aggressively.
o The algorithm used in PTP for this is typically a Proportional-Derivative (PD)
controller or similar adaptive mechanism that adjusts the clock frequency and offset
to minimize drift.
4. Handling Network Delay Variability:
o PTP uses the Delay Request and Delay Response messages to measure and correct
for network delay variations. By continuously monitoring these delays, PTP adjusts
the clock synchronization to account for any network-induced timing errors.
Clock Selection Algorithm in PTP
In Precision Time Protocol (PTP), the clock selection algorithm is crucial for choosing the best master
clock among several available options. This selection process ensures that the network clocks are
synchronized with the most accurate and stable source available.
Key Criteria for Clock Selection
1. Clock Quality: Measures the accuracy and stability of the clock, typically represented by the
ClockClass, ClockAccuracy, and OffsetScaledLogVariance fields in the PTP messages.
2. Clock Stability: Refers to the consistency of the clock's timekeeping. More stable clocks have
lower variance and jitter.
3. Configuration: Includes network topology, preferences for specific master clocks, and
administrative settings.
Clock Selection Process
The clock selection process generally follows these steps:
1. Receive Announce Messages: Clocks in the network send Announce messages that include
information about their quality and stability.
2. Evaluate Clocks: Each clock evaluates the quality and stability of the received clocks using
the ClockClass, ClockAccuracy, and OffsetScaledLogVariance fields.
3. Select the Best Clock: Based on the evaluation, the clock with the highest quality and
stability is selected as the master clock. This selection process might involve comparing
values to determine the best candidate.
PTP Clock Selection Fields
1. ClockClass: A value indicating the class of the clock (e.g., 6 for a hardware clock, 9 for a
software clock). Lower values indicate higher quality clocks.
2. ClockAccuracy: Provides the accuracy of the clock, often in parts per million (ppm).
3. OffsetScaledLogVariance: Represents the variance of the clock's offset from its peers, with
lower values indicating better stability.
Example C Code for Clock Selection Algorithm
Here's a simplified example of how you might implement a basic clock selection algorithm in C. This
example assumes you have received PTP Announce messages containing clock quality information.
#include <stdint.h>
#include <stdio.h>
#include <limits.h>
// Define a structure for storing PTP Announce message data
typedef struct {
uint8_t clockClass;