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
For the record, the onboard NIC's (aka LOM's) of that era, including and up to i219 I believe, did have issues. I recall getting the infamous "timed out while polling for tx timestamp" on an i219, even after adjusting the tx_timestamp_timeout to 20 ms or so. The i82579 (and i82580) are even older (phased out by Intel as of the time of this writing).
I have good experience with PTP on the i210 and i350 - which by now is fairly old hardware. With a good GM (= stable oscillator, HW timestamping), the ptp4l slave can converge down to low double digit nanoseconds (ppb) with an undisciplined xtal oscillator (or literally to zero with an Rb- or GPS-referenced 25MHz clock). I do recall trying with the i82574L (= the predecessor to i210) and other NIC's of that generation, and although the HW timestamping does work, the results reported by ptp4l were less stellar, compared to the i210 generation.
Also note that the i219 comes integrated in several generations and models of PC chipsets, and these slightly different "editions" may exhibit marginal differences in their HW timestamping capability/performance/bugs. If there were early bugs, they may have got fixed in later silicon revisions. And, with every NIC that does HW timestamping, even with the i210, stability of the 25MHz crystal may play a role. To get an idea, try touching the crystal with your finger while ptp4l is running.