How to enable Precision Time Protocol (PTP)
A lot of knowledge is required to implement PTP correctly in a network. In particular, a lot of time must also be invested to validate the accuracy of the clock synchronization between the involved devices. This can involve a considerable amount of extra work and the purchase of special measuring equipment.
Introduction
In reality, the time kept by clocks in different network devices can drift from each other. In time-sensitive applications, this drift is mitigated by using time synchronization.
Having time synchronized between any two clocks means that the difference in time between them has an upper bound. This can be achieved by periodically synchronizing the time between the clocks (i.e., before the time difference gets too large). If the required precision of the synchronization must be in the range of a few microseconds, this is exactly what PTP provides.
If a precision of a few milliseconds (or even sub-milliseconds via a direct Ethernet connection) is sufficient, it is much easier to use only NTP. VRTK2 by default operates as NTP master.
The Ethernet MAC with IEEE 1588 of VRTK2 integrates a standard IEEE 802.3 Ethernet MAC with a time-stamping module. The IEEE 1588 standard provides accurate clock synchronization for distributed control nodes, for example for industrial automation applications.
Since VisionRTK 2.81.x the sensor can be a Precision Time Protocol (PTP) Grand Master (GM). The sensor provides the very precise time (sub-microseconds), which can be used by other devices if required.
VRTK2 cannot be synchronized via PTP itself. It only operates as a master and does not act as a slave.
Configuration
The PTP functionality can be (de)activated in the web interface on the configuration –> time page.
PTP profiles
IEEE-1588 defines profile as “The set of allowed Precision Time Protocol (PTP) features applicable to a device”.
The purpose of a PTP profile is to allow organizations to specify specific selections of attribute values and optional features of PTP that, when using the same transport protocol, inter-work and achieve a performance that meets the requirements of a particular application.
The following three PTP profiles are supported and can be selected in the Profile drop down menu.
PTPv2 E2E (IEEE 1588-2008)
This is the standard PTPv2 profile, which uses the E2E delay mechanism and is specified according to IEEE 1588-2008.
gPTP (IEEE 802.1AS)
See: https://youtu.be/3vsO4Ndv-9M
In this profile time synchronization is specified by IEEE 802.1AS, also known as Generalized Precision Time Protocol (gPTP). gPTP consists of simplifications and constraints to PTP to optimize it to time-sensitive applications. gPTP also introduces the Grand Master (GM) role which can be played by any node in the gPTP domain (such as end-stations or bridges) and is determined by the Best Master Clock Algorithm (BMCA). The GM provides clocking information to all other nodes in the gPTP domain.
gPTP devices operate in one of three roles, according to their location in the spanning tree: master, bridge or slave. VRTK2 contains the master clock for the time domain, creates gPTP sync messages, and broadcasts them down-tree to bridge and slave nodes. Bridge nodes forward sync messages to bridge and slave nodes as well. VRTK2 can only be operated as a master, i.e. it provides its exact time but does not receive it.
If one or more Ethernet bridges are involved in the customer’s network, they must of course be able to bridge gPTP. This can be implemented with bridges specially designed for this purpose.
Avnu automotive profile
Due to the static nature of the automotive network, AVnu has specified the Automotive Profile which does some optimizations to gPTP to improve startup time and reduce network load. The main difference from gPTP is that the BMCA is disabled so each device is statically assigned as master or slave.
Example
This example can be run on a Linux device that supports gPTP (IEEE 802.1AS). It has been mostly copied from here.
Compatibility: This example was tested both with a VRTK2 as a slave and with an NVIDIA Jetson AGX Xavier as slave. It is possible that problems may occur with certain Ethernet PHYs/drivers in computers as they might not be fully AVB compatible.
In the Linux ecosystem, Linux PTP is the most popular implementation of PTP. Linux PTP provides some tools to carry out time synchronization:
ptp4l: daemon that synchronizes the PTP Hardware Clock (PHC) from the NIC
phc2sys: daemon that synchronizes the PHC and the System clock
pmc: utility tool to configure ptp4l in run-time.
Although this example was tested with two VRTK2s (one configured to be a PTP slave), it is hardware-agnostic and applies to any 802.1AS-capable NIC with proper device driver support. By following this example, the reader will be able to synchronize time using Linux PTP.
Installing Linux PTP
Several Linux distributions provide a package for Linux PTP. This section discusses how to get Linuxptp source, build, and install the tools.
git clone http://git.code.sf.net/p/linuxptp/code linuxptp
cd linuxptp/
make
sudo make installBy default, Linux PTP artifacts are installed into /usr/local/sbin/.
Synchronizing the PHC
The PTP Hardware Clock (PHC) synchronization step is mandatory for all Time-Sensitive Networking (TSN) systems. It guarantees the PHC from the NIC is in sync with the GM clock (provided by VRTK2) from the gPTP domain. This is achieved by the ptp4l daemon.
To synchronize PHC with the GM clock, run the command below. Make sure to replace eth0 by the interface name corresponding to the TSN-capable NIC in the system.
sudo ptp4l -i eth0 -f configs/gPTP.cfg --step_threshold=1 -s -mThe file gPTP.cfg (available in configs folder of Linux PTP source) specified by the -f option contains the configuration options to required to run ptp4l in gPTP mode while the -i option specifies the network interface this instance of ptp4l is controlling. The --step_threshold is set so ptp4l converges faster when “time jumps” occur. The -s option tells ptp4l to operate only in slave mode. The -m option enables log messages on standard output. For further details, see ptp4l(8) manpage.
Run this step in all end-points of the network.
Synchronizing the System Clock
PHC time is set in TAI coordinate while System clock time is set in UTC coordinate. To ensure System clocks (CLOCK_REALTIME and CLOCK_TAI) are properly set, configure the UTC-TAI offset in the system. This is done by a run-time option from ptp4l that is set via pmc utility tool as shown below.
sudo pmc -u -b 0 -t 1 "SET GRANDMASTER_SETTINGS_NP clockClass 248 \
clockAccuracy 0xfe offsetScaledLogVariance 0xffff \
currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 1 \
ptpTimescale 1 timeTraceable 1 frequencyTraceable 0 \
timeSource 0xa0"Once UTC-TAI offset is properly set, synchronize the System clock with PHC.
sudo phc2sys -s eth0 -c CLOCK_REALTIME --step_threshold=1 \
--transportSpecific=1 -w -mThe -s option specifies the PHC from eth0 interface as the master clock while the -c option specifies the System clock as slave clock. In the command above PHC disciplines the System clock, that is, the system clock is adjusted. The --transportSpecific option is required when running phc2sys in a gPTP domain. The --step_threshold is set so phc2sys converges faster when “time jumps” occurs. Finally, the -w option makes phc2sys wait until ptp4l is synchronized and the -m option enables log messages on standard output. For more information about phc2sys configuration option refer to phc2sys(8) manpage.
Checking Clocks Synchronization
On ptp4l, the slave devices report out the time offset calculated from the master. This information can be used to determine whether the systems have been synchronized. The output for ptp4l is:
ptp-client:~/linuxptp $ sudo ptp4l -i eth0 -f configs/gPTP.cfg --step_threshold=1 -s -m
ptp4l[783969.247]: selected /dev/ptp0 as PTP clock
ptp4l[783969.284]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[783969.284]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[783972.562]: port 1: new foreign master f8dc7a.fffe.8f121c-1
ptp4l[783973.218]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[783973.219]: selected local clock f8dc7a.fffe.8f12ba as best master
ptp4l[783973.219]: port 1: assuming the grand master role
ptp4l[783974.563]: selected best master clock f8dc7a.fffe.8f121c
ptp4l[783974.563]: port 1: MASTER to UNCALIBRATED on RS_SLAVE
ptp4l[783975.575]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[783976.201]: rms 18500062511 max 37000126306 freq -30357 +/- 6539 delay 398 +/- 0
ptp4l[783977.201]: rms 9311 max 9921 freq -18299 +/- 2048 delay 397 +/- 0
ptp4l[783978.202]: rms 5463 max 7430 freq -15940 +/- 344 delay 396 +/- 0
ptp4l[783979.202]: rms 1605 max 2745 freq -17971 +/- 690 delay 397 +/- 0
ptp4l[783980.203]: rms 392 max 568 freq -19938 +/- 401 delay 398 +/- 0
ptp4l[783981.203]: rms 544 max 594 freq -20768 +/- 105 delay 400 +/- 0
ptp4l[783982.203]: rms 322 max 426 freq -20908 +/- 20 delay 404 +/- 0
ptp4l[783983.204]: rms 96 max 167 freq -20788 +/- 49 delay 401 +/- 0
ptp4l[783984.204]: rms 42 max 61 freq -20635 +/- 34 delay 401 +/- 0
ptp4l[783985.205]: rms 47 max 61 freq -20576 +/- 17 delay 401 +/- 0
ptp4l[783986.205]: rms 19 max 35 freq -20587 +/- 17 delay 403 +/- 0
ptp4l[783987.206]: rms 10 max 22 freq -20593 +/- 13 delay 404 +/- 0
ptp4l[783988.206]: rms 9 max 14 freq -20609 +/- 9 delay 404 +/- 0
ptp4l[783989.207]: rms 7 max 10 freq -20601 +/- 9 delay 404 +/- 0
The rms value reported by ptp4l once the slave has locked with the GM shows the root mean square of the time offset between the PHC and the GM clock. If ptp4l consistently reports rms lower than 100 ns, the PHC is synchronized.
Like ptp4l, phc2sys reports the time offset between PHC and System Clock, which determines if the clocks are synchronized.
@fp-8f12ba:~/linuxptp $ sudo phc2sys -s eth0 -c CLOCK_REALTIME --step_threshold=1 --transportSpecific=1 -w -m
phc2sys[787954.400]: CLOCK_REALTIME phc offset 59 s0 freq -20614 delay 625
phc2sys[787955.401]: CLOCK_REALTIME phc offset 179 s2 freq -20494 delay 750
phc2sys[787956.401]: CLOCK_REALTIME phc offset 39 s2 freq -20455 delay 625
phc2sys[787957.401]: CLOCK_REALTIME phc offset -96 s2 freq -20578 delay 625
phc2sys[787958.401]: CLOCK_REALTIME phc offset -174 s2 freq -20685 delay 625
phc2sys[787959.402]: CLOCK_REALTIME phc offset -34 s2 freq -20597 delay 625
phc2sys[787960.402]: CLOCK_REALTIME phc offset 27 s2 freq -20547 delay 625
phc2sys[787961.402]: CLOCK_REALTIME phc offset 13 s2 freq -20552 delay 625
phc2sys[787962.402]: CLOCK_REALTIME phc offset -33 s2 freq -20595 delay 750
phc2sys[787963.402]: CLOCK_REALTIME phc offset -57 s2 freq -20628 delay 625
The offset information reported by phc2sys shows the time offset between the PHC and the System clock. If phc2sys consistently reports offset lower than 100 ns, the System clock is synchronized.
Precision and accuracy
Measurement inaccuracies cannot be precluded. For more precise results, the measurements would have to be carried out again with a more accurate measurement setup.
Tests have shown that the precision of the time synchronization with VRTK2 using PTP is sub-microsecond. The time accuracy is based on the time provided by the GNSS receiver and is approximately 3us on VRTK2 with good GNSS reception. During periods of operation when there is no or only degraded GNSS reception, the time provided by PTP will naturally start to drift to the same extent as the time from the GNSS receiver and accuracy may suffer. In other words, under these conditions, PTP will continue to provide the system time and synchronize all connected slaves relative to each other and precision stays the same. However, the time provided may deviate from the global time and accuracy suffers.