Using LinuxPTP for time synchronization (software/hardware timestamp) – Yanyi

Reprinted from:
Official documentation:
Check whether the network card supports software and hardware timestamps:

sudo ethtool -T eno1
Time stamping parameters for eno1:
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
Hardware Receive Filter Modes:
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)

Software timestamps need to include parameters

Hardware timestamp needs to include parameters

View Usage

ptp4l -h

  Delay mechanism options
  -A Auto, automatically selects the delay mechanism. , starting from E2E, switching to P2P when receiving a peer delay request
  -E E2E, selects the deferred request-response (E2E) mechanism. This mechanism is used by default. All clocks on a single PTP communication path must use the same mechanism. When receiving a delayed request from a peer on a port using the E2E mechanism, a warning will be output.
  -P P2P, peer-to-peer delay mechanism
  Network transfer options
  -2 IEEE 802.3
  -4 UDP IPV4 (default)
  -6 UDP IPV6
  Timestamp options
  -H use hardware timestamp (default)
  -S Use software timestamp
  -L LEGACY HW timestamp
  other options
  -f [file] Read configuration from the specified file file. By default no configuration files are read.
  -i [dev] Select the PTP interface device, such as eth0 (can be specified multiple times) At least one port must be specified using this option or configuration file.
  -p [dev] Prior to Linux kernel v3.5, PHC devices associated with network interfaces could not be discovered. This option specifies the PHC device to use when running on older kernels (e.g. /dev/ptp0). Clock device to use, default is auto, ignore software/LEGACY HW timestamps (this option is deprecated)
  -s slaveOnly mode, slave clock mode (override configuration file)
  -t transparent clock mode
  -l [num] Set logging level to 'num', default is 6
  -m print messages to stdout
  -q do not print messages to syslog
  -v print software version and exit
  -h help

2. run linuxptp
2.1 Software timestamp, master-slave mode test
Server (master clock):

sudo ptp4l -i enp0s31f6 -m -S

Client (slave):

sudo ptp4l -i eno1 -m -S -s

![Insert image description here](

After running for a while:
The content in the log is:

master offset: The master-slave time difference defined in the PTP protocol, unit: ns
s0, s1, s2: Indicates different states of the clock server. s0 means unlocked, s1 means synchronizing, s2 means locked. The locked state means that step synchronization will not occur again, but will be adjusted slowly.
port 0:INITIALIZING to LISTENING on INIT_COMPLET: Unix domain socket managed by local PTP;
port 1:new foreign … : port on eno1;
When the slave clock port status changes from UNCALIBRATED to SLAVE, the slave clock has successfully synchronized with the best master.
2.2 Hardware timestamp test
Server (master clock):

sudo ptp4l -i enp0s31f6 -m -H

Client (slave):

sudo ptp4l -i eno1 -m -H -s

If you want to modify the system time, the PHC needs to synchronize the time obtained through the PTP protocol to the system and execute the phc2sys command:

sudo phc2sys -m -s CLOCK_REALTIME -c enp0s31f6 -w
sudo ptp4l -i enp0s31f6 -m -H
sudo phc2sys -m -s eno1 -w
sudo ptp4l -i eno1 -m -H -s

operation result:
From the clock:

Obviously, the accuracy of hardware timestamp synchronization is much higher, and this is just an ordinary network card, and it is still on the campus network.

2.3 Configuration file
You can use -f to specify the configuration file when running. The command line will overwrite the configuration file. Commonly used configuration items are as follows (#’ is followed by a comment. If you want to leave a comment during actual configuration, the comment needs to be on a separate line. This is currently the case):

twoStepFlag 1 #PTP two-step mode is turned on
clientOnly 0 #
socket_priority 0
priority1 128 #corresponds to priority 1 in BMCA
priority2 128 #corresponds to priority 2 in BMCA
domainNumber 0 #PTP domain number
#utc_offset 37 #Configure leap seconds. As of now, it is 37 seconds. Generally, there is no need to configure it because the clock source has been configured (the default is commented)
clockClass 248 #corresponds to clockClass in BMCA
logAnnounceInterval 1 #log interval
delayAsymmetry 0 # Configurable link asymmetry, positive number means rx delay is higher than tx delay, negative number means lower, unit ns.
BMCA ptp # Specify BMCA algorithm ptp, noop, custom
ptp_dst_mac 01:1B:19:00:00:00
p2p_dst_mac 01:80:C2:00:00:0E
clock_type OC
network_transport UDPv4 #L2 UDPv4 UDPv6, corresponding to -2 -4 -6 on the command line
delay_mechanism E2E # E2E P2P

2.4 Transparent Clock (TC) mode test (fixed)
/- This bug has been fixed -\

Both TC and BC require at least two interfaces;
Execute the following command

sudo ptp4l -i eno1 eno2 -m -H -t

Prompt for invalid options:

Um? It is clearly written in usage that -t means transparent clock.
sudo vim ptp4l.8
Well, -f -i -m -p -l -i -A -E -P -2 -4 -6 -H -S -L -q -v -h
? ? There is just no -t, I don’t understand

Manual TC/BC: The device needs to have two network cards, one card is bound to the slave clock and the other card is bound to the master clock, to implement TC/BC. The effect is actually about the same.
USRP U L O issues encountered during recent development:

"U" error
When the host PC or the application running on it cannot provide samples to USRP at a fast enough rate, a "U" error often occurs. For example: USRP requires samples at a set sampling rate of 5M/s, but When the host PC can only provide samples at a rate lower than 5M/s, a "U" error will occur.
"O" error
"O" errors often occur when the host PC or the application running on it cannot process the samples provided by USRP at a fast enough rate. Distance description: When USRP provides samples at a set sampling rate of 5M/s If the host PC can only process samples at a rate lower than 5M/s, an "O" error will occur.
"L" error
The design mechanism of USRP is to require the timestamp in the Packet to be earlier than the timestamp in the FPGA. If the timestamp in the Packet is out of date when the instruction arrives at the FPGA, USRP will give an "L" error, that is, the instruction arrives later than the expected execution time.