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.
The Ethernet MAC with IEEE 1588 of XVN 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 XVN 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.
The PTP functionality can be (de)activated in the web interface on the configuration –> time page.
Time Configuration page in the web interface
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.
PTP Profile configuration options
This is the standard PTPv2 profile, which uses the E2E delay mechanism and is specified according to IEEE 1588-2008.
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. XVN 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. XVN can only be operated as a master, i.e. it provides its exact time but does not receive it.
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.
This example can be run on a Linux device that supports gPTP (IEEE 802.1AS). It has been mostly copied from here.
In the Linux ecosystem, Linux PTP is the most popular implementation of PTP. Linux PTP provides some tools to carry out time synchronization:
Although this example was tested with two XVNs (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.
Several Linux distributions provide a package for Linux PTP. This section discusses how to get Linuxptp source, build, and install the tools.
By default, Linux PTP artifacts are installed into /usr/local/sbin/.
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 XVN) 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.
The 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.
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.
Once UTC-TAI offset is properly set, synchronize the System clock with PHC.
The -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.
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:
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.
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.
Tests have shown that the precision of the time synchronization with XVN using PTP is sub-microsecond. The time accuracy is based on the time provided by the GNSS receiver and is approximately 3us on XVN 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.