Linux Time Synchronization

Many applications in factory automation, test and measurement, and telecommunications require close time synchronization. This is often a scenario where multiple boards are transmitting on the same RF channel and the system clocks must be synchronized precisely. Time Division Multiplex (TDM) is used so the transmitters are not producing collisions, thus maximizing RF throughput.

There are two common solutions to this problem:

IEEE 1588 Precision Time Protocol - uses Ethernet frames GPS Pulse-Per-Seconds - uses GPS information

Time synchronization via IEEE 1588 Precision Time Protocol (PTP) (Ethernet)

The IEEE 1588 Precision Time Protocol (PTP) is designed to provide high-precision clock synchronization across networked devices, achieving sub-microsecond accuracy. The implementation of PTP varies between Ethernet Media Access Controllers (MACs) and Physical Layer (PHY) devices which may include dedicated GPIO support for 1588.

The following timestamping scenarios exist:

• software-only PTP (lowest accuracy): relies on the OS to timestamp PTP even messages as they pass through the network statck without requiring hardware support for precise timestamping. This is supported in the kernel with timestamps based on the system clock rather than a dedicated PTP Hardware Clock (PHC)
• MAC timestamping: if supported by MAC, this allows captured timestamps to be inserted by the hardware via a dedicated PTP Hardware Clock (PHC) at the MAC layer which reduces latency introduced by the network stack and queuing ensuring high accuracy.
• PHY timestamping (highest accuracy): if supported by PHY, this allows timestamps to be captured as frames pass through the PHY minimizing latency and jitter compared to MAC-only timestamping.

The Linux kernel has IEEE 1588 PTP support for a handful of ethernet devices.

Gateworks Venice PTP

Gateworks venice MAC/PHY's supporting IEEE 1588 PTP include:

• IMX8M FEC ethernet MAC
• IMX8MP EQOS ethernet MAC
• LAN7430 PCIe Gigabit Ethernet controller MAC/PHY (used as an additional ethernet device on boards)

The NXP FEC MAC and EQOS supports timestamping at the MAC layer and achieves sub-microsecond synchronization accuracy, suitable for industrial automation, automotive, and IoT applications. The iMX8M’s improved timer and driver support offer slightly better precision than the iMX6, especially in modern Linux kernels. Both MAC's additionally have GPIO support where PTP-related timing signals (ie Pulse-per-Second or event triggers) can be pinmuxed to specific GPIO's and made available if supported by the individual board design.

The LAN7430 PCIe Ethernet controller supports timestamping at the PHY layer (which minimizes latency and jitter compared to MAC-layer using a dedicated PTP clock. The LAN7430 supports both one-step and two-step PTP modes, where timestamps are either inserted directly into packets (one-step) or sent in follow-up messages (two-step)

Gateworks Newport PTP

The CN80xx SoC supports PTP at the MAC layer. From CN80xx reference manual:

The CN80XX hardware supports very accurate timestamping in the PTP, BGX, GTI, and NIC blocks. This timestamping is suitable for use in IEEE 1588 Precision Time Protocol (PTP) or other purposes.

The CN80XX outbound timestamping hardware captures timestamps, but cannot insert the timestamp into any outgoing packets. Using IEEE 1588 vernacular, this means that the CN80XX outbound timestamping hardware is most useful when implementing a two-step clock, not a one-step clock, for PTP event messages sent from CN80XX. After the hardware captures the timestamp for the outgoing 1588 event message and delivers it to software, the 1588 software running on the CN80XX may need to send the timestamp to required recipients in a subsequent 1588 general message as a second step.

NIC has no specific mode supporting PTP timestamping, but contains a number of features to compensate for the PTP timestamp introduced by BGX when it is timestamping. When BGX is in the receive-timestamp mode, NIC receives the timestamp plus packet from the BGX. NIC packet parsing is able to skip over the received timestamps. NIC MAXERR, MINERR, and LENERR checks can compensate for the additional header, since the MAXERR and MINERR byte counts are programmable, and the programmed value can easily be increased by 8. The LENERR check already compensates based on the skip value. NIC makes the timestamp available for software with every packet. The timestamp can be present in the completion-queue entry and/or the receive buffer in L2/DRAM for software, depending on NIC configuration. The software will likely use the timestamp when IEEE 1588 event messages arrive. For other packets, the software may choose to discard or ignore the timestamp that is present with every packet in this mode.

Gateworks Ventana PTP

Gateworks ventana MAC/PHY's supporting IEEE 1588 PTP include:

• IMX6Q/DL FEC ethernet
• Intel I210 PCIe Gigabit Ethernet controller MAC/PHY (used as an additional ethernet device on boards)

The NXP FEC MAC supports timestamping at the MAC layer and achieves sub-microsecond synchronization accuracy, suitable for industrial automation, automotive, and IoT applications. The MAC additionally has GPIO support where PTP-related timing signals (ie Pulse-per-Second or event triggers) can be pinmuxed to specific GPIO's and made available if supported by the individual board design.

The I210 Ethernet controller implements PTP timestamping ath the PHY layer minimizing latency and jitter compared to MAC-only timestamping. The I210 includes a dedicated hardware clock for PTP and supports both one-step and two-step PTP modes, where timestamps are either inserted directly into packets (one-step) or sent in follow-up messages (two-step)

The Linux PTP Project (linuxptp)

The ​Linux PTP Project is an implementation of the IEEE 1588 for Linux featuring:

• Supports software time stamping via the Linux SO_TIMESTAMPING socket option (use the -S parameter)
• Supports the Linux PTP Hardware Clock (PHC) subsystem by using the clock_gettime family of calls, including the new clock_adjtimex system call.
• Implements Boundary Clock (BC) and Ordinary Clock (OC).
• Transport over UDP/IPv4, UDP/IPv6, and raw Ethernet (Layer 2).
• Supports IEEE 802.1AS-2011 in the role of end station.
• Modular design allowing painless addition of new transports and clock servos.

Example usage on a GW54xx:

apt-get install linuxptp -y

Master:

root@ventana:~# ptp4l -i eth0 -m
ptp4l[112.404]: selected /dev/ptp0 as PTP clock
ptp4l[112.409]: driver changed our HWTSTAMP options
ptp4l[112.409]: tx_type   1 not 1
ptp4l[112.409]: rx_filter 1 not 12
ptp4l[112.409]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[112.409]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[120.064]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[120.065]: selected best master clock 00d012.fffe.13f09d
ptp4l[120.065]: assuming the grand master role

• the ptp4l tries to use hardware time stamping by default, otherwise you can use the '-H' to force hardware timestamping, or '-S' to force software timestamping
• the -m parameter tells ptp4l to output messages to the console
• no master was found so this target became the master

Slave:

root@ventana:~# ptp4l -i eth0 -m
selected /dev/ptp0 as PTP clock
ptp4l[228.239]: driver changed our HWTSTAMP options
ptp4l[228.239]: tx_type   1 not 1
ptp4l[228.239]: rx_filter 1 not 12
ptp4l[228.239]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[228.239]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[229.995]: port 1: new foreign master 00d012.fffe.13f09d-1
ptp4l[233.995]: selected best master clock 00d012.fffe.13f09d
ptp4l[233.995]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[235.995]: master offset 250446314787536 s0 freq      +0 path delay      3768
ptp4l[236.995]: master offset 250446314782408 s1 freq   -5128 path delay      3768
ptp4l[237.995]: master offset      -1635 s2 freq   -6763 path delay      3768
ptp4l[237.995]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[238.995]: master offset        754 s2 freq   -4864 path delay      2996
ptp4l[239.995]: master offset       1083 s2 freq   -4309 path delay      2404
ptp4l[240.995]: master offset        248 s2 freq   -4819 path delay      2404
ptp4l[241.995]: master offset        -53 s2 freq   -5046 path delay      2372
ptp4l[242.995]: master offset       -129 s2 freq   -5138 path delay      2341

• this was started after the master, so it found the master and became a slave

References:

• ​Introduction to linuxPTP
• ​Linux PTP Project
  • ​Linux PTP code
• ​Linux PTP Documentation
  • ​sysfs API
  • ​userspace test program
• ​Configuring PTP Using ptp4l

Time synchronization via PPS (Pulse-Per-Second) (GPS)

One handy feature of an on-board GPS is that it can deliver Pulse-Per-Second (PPS) signal. Most Gateworks SBCs have the option to load an on-board GPS (see individual product pages for specific model numbers and details). The PPS signal can be used to provide a high-precision time reference that an application can use to adjust system clock time or synchronize boards on a network. Common use is to configure the Network Time Protocol Daemon (NTPD) with a PPS source to obtain a wallclock-time with sub-millisecond synchronization to UTC.

The PPS signal is routed to a processor GPIO that can be configured to generate an interrupt for use by the user application. Additionally the PPS signal is optionally routed to one (or several, depending on model) of the Mini-PCIe sites (Pin 49) for use by a radio/peripheral to provide synchronization. Contact support for more information on each board model.

See the GPS page for more info.