Discrepancy in PTP (Precision Time Protocol) hardware Timestamping accuracy measurements

Question

We are analyzing PTP for a control system software and measuring the accuracy of PTP clock synchronization with a small setup of 2 personal computers making one of them as a master and the other as slave. Our current setup is very crude and we do not have a grandmaster yet. The problem is that our accuracy numbers (as we currently measure them, which might be incorrect) do not match with the standard numbers PTP protocol claims and varies by a degree of magnitude 10.

As part of the analysis, we are trying out both Hardware and Software Timestamping and trying to measure the accuracy of both.

We are using ptp4l and ph2sys v1.8 tools. Our current measure of accuracy is based on master-slave offsets reported by the ptp4l process. (ptp4l also reports path delays, we don't use those numbers currently. Is there any significance of these numbers in accuracy measurement?)

In Hardware Timestamping, we are getting >1000 nanoseconds offset from the master which is far larger than the expected value of around 50 ns of PTP H/W Timestamping.

For Software Timestamping, we are getting the expected offsets from the master which is <100 μs.

Details of setup and execution:

Master: Dell Latitude E6220 (Intel 82579LM Gigabit Ethernet controller) - CentOS7

Slave: Dell Latitude E6320 (Intel 82579LM Gigabit Ethernet controller) - CentOS7

Network: Ethernet cable with 1 GBPS speed

Ethtool output:

Capabilities:

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)

ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)

ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)

ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)

ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)

ptpv2-l2-sync         (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)

ptpv2-l2-delay-req    (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)

ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)

ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)

ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)

We are using ptp4l for software timestamping as follows:

Master:

sudo ptp4l -i em1 -m -S

Slave:

sudo ptp4l -i em1 -m  -s -S

And ptp4l and phc2sys for hardware timestamping as follows:

Master:

sudo ptp4l -i em1 -m

sudo phc2sys -s CLOCK_REALTIME -c em1 -m -w 

(Since we do not have a grand-master currently, we are using Master's system clock as the Master clock for phc2sys)

Slave:

sudo ptp4l -i em1 -m -s

sudo phc2sys -s  em1 -c CLOCK_REALTIME -m -w

(Note: We are running the above commands with default configuration. Please let us know if any configurations need to be tweaked for better accuracy?)

We are seeking help in figuring out the reasons behind this discrepancy in hardware timestamping accuracy and any mistakes in our test setup or measuring methods.

Thanks,

Dolly

Answer 1

We are using ptp4l and ph2sys v1.8 tools.

with

Intel 82579LM

LinuxPTP v1.8 was released in November 2016 and a patch was added in February 2017 to the code regarding an issue with the frequency of the hardware that impact the accuracy of the hardware clock.

This explain why only hardware mode is impacted.

The use of a more recent version should solve the issue.