Reprinted from: https://blog.csdn.net/BUPTOctopus/article/details/86246335
Official documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s1-using_ptp
Check whether the network card supports software and hardware timestamps:
sudo ethtool -T eno1
Time stamping parameters for eno1: 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)
Software timestamps need to include parameters
SOF_TIMESTAMPING_SOFTWARE
SOF_TIMESTAMPING_TX_SOFTWARE
SOF_TIMESTAMPING_RX_SOFTWARE
Hardware timestamp needs to include parameters
SOF_TIMESTAMPING_RAW_HARDWARE
SOF_TIMESTAMPING_TX_HARDWARE
SOF_TIMESTAMPING_RX_HARDWARE
View Usage
ptp4l -h
1 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
fa2f6de3b904a25802eec8b79ae23fe.png)
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.
freq:
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:
#Masterclock sudo phc2sys -m -s CLOCK_REALTIME -c enp0s31f6 -w sudo ptp4l -i enp0s31f6 -m -H #fromclock 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):
[global] 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.