17.2. Using PTP

In order to use PTP, the kernel network driver for the intended interface has to support either software or hardware time stamping capabilities.

17.2.1. Checking for Driver and Hardware Support

In addition to hardware time stamping support being present in the driver, the NIC must also be capable of supporting this functionality in the physical hardware. The best way to verify the time stamping capabilities of a particular driver and NIC is to use the ethtool utility to query the interface as follows:
~]# ethtool -T eth3
Time stamping parameters for eth3:
        hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
        software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
        hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
        software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
        software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
        hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off                   (HWTSTAMP_TX_OFF)
        on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
        none                  (HWTSTAMP_FILTER_NONE)
        all                   (HWTSTAMP_FILTER_ALL)
Where eth3 is the interface you want to check.
For software time stamping support, the parameters list should include:
For hardware time stamping support, the parameters list should include:

17.2.2. Installing PTP

The kernel in Red Hat Enterprise Linux includes support for PTP. User space support is provided by the tools in the linuxptp package. To install linuxptp, issue the following command as root:
~]# yum install linuxptp
This will install ptp4l and phc2sys.
Do not run more than one service to set the system clock's time at the same time. If you intend to serve PTP time using NTP, see Section 17.8, “Serving PTP Time with NTP”.

17.2.3. Starting ptp4l

The ptp4l program can be started from the command line or it can be started as a service. When running as a service, options are specified in the /etc/sysconfig/ptp4l file. Options required for use both by the service and on the command line should be specified in the /etc/ptp4l.conf file. The /etc/sysconfig/ptp4l file includes the -f /etc/ptp4l.conf command line option, which causes the ptp4l program to read the /etc/ptp4l.conf file and process the options it contains. The use of the /etc/ptp4l.conf is explained in Section 17.4, “Specifying a Configuration File”. More information on the different ptp4l options and the configuration file settings can be found in the ptp4l(8) man page.

Starting ptp4l as a Service

To start ptp4l as a service, issue the following command as root:
~]# systemctl start ptp4l
For more information on managing system services in Red Hat Enterprise Linux 7, see Chapter 9, Managing Services with systemd.

Using ptp4l From The Command Line

The ptp4l program tries to use hardware time stamping by default. To use ptp4l with hardware time stamping capable drivers and NICs, you must provide the network interface to use with the -i option. Enter the following command as root:
~]# ptp4l -i eth3 -m
Where eth3 is the interface you want to configure. Below is example output from ptp4l when the PTP clock on the NIC is synchronized to a master:
~]# ptp4l -i eth3 -m
selected eth3 as PTP clock
port 1: new foreign master 00a069.fffe.0b552d-1
selected best master clock 00a069.fffe.0b552d
master offset -23947 s0 freq +0 path delay       11350
master offset -28867 s0 freq +0 path delay       11236
master offset -32801 s0 freq +0 path delay       10841
master offset -37203 s1 freq +0 path delay       10583
master offset  -7275 s2 freq -30575 path delay   10583
master offset  -4552 s2 freq -30035 path delay   10385
The master offset value is the measured offset from the master in nanoseconds. The s0, s1, s2 strings indicate the different clock servo states: s0 is unlocked, s1 is clock step and s2 is locked. Once the servo is in the locked state (s2), the clock will not be stepped (only slowly adjusted) unless the pi_offset_const option is set to a positive value in the configuration file (described in the ptp4l(8) man page). The adj value is the frequency adjustment of the clock in parts per billion (ppb). The path delay value is the estimated delay of the synchronization messages sent from the master in nanoseconds. Port 0 is a Unix domain socket used for local PTP management. Port 1 is the eth3 interface (based on the example above.) INITIALIZING, LISTENING, UNCALIBRATED and SLAVE are some of possible port states which change on the INITIALIZE, RS_SLAVE, MASTER_CLOCK_SELECTED events. In the last state change message, the port state changed from UNCALIBRATED to SLAVE indicating successful synchronization with a PTP master clock.

Logging Messages From ptp4l

By default, messages are sent to /var/log/messages. However, specifying the -m option enables logging to standard output which can be useful for debugging purposes.
To enable software time stamping, the -S option needs to be used as follows:
~]# ptp4l -i eth3 -m -S Selecting a Delay Measurement Mechanism

There are two different delay measurement mechanisms and they can be selected by means of an option added to the ptp4l command as follows:
The -P selects the peer-to-peer (P2P) delay measurement mechanism.
The P2P mechanism is preferred as it reacts to changes in the network topology faster, and may be more accurate in measuring the delay, than other mechanisms. The P2P mechanism can only be used in topologies where each port exchanges PTP messages with at most one other P2P port. It must be supported and used by all hardware, including transparent clocks, on the communication path.
The -E selects the end-to-end (E2E) delay measurement mechanism. This is the default.
The E2E mechanism is also referred to as the delay request-response mechanism.
The -A enables automatic selection of the delay measurement mechanism.
The automatic option starts ptp4l in E2E mode. It will change to P2P mode if a peer delay request is received.


All clocks on a single PTP communication path must use the same mechanism to measure the delay. Warnings will be printed in the following circumstances:
  • When a peer delay request is received on a port using the E2E mechanism.
  • When a E2E delay request is received on a port using the P2P mechanism.