Linux Time Syncrhronization

Many applications in factory automation, test and measurement, and telecommunications require very close time synchronization. The use case for this for our customers is often scenarios where they have multiple boards transmitting on the same RF channel and they want to synchronize the system clocks to a precision that allows the boards to Time Division Multiplex (TDM) the use of the transmitters so they are not producing collisions and thus maximizing RF throughput as this is the most efficient way of utilizing available bandwidth.

There are two common solutions to this problem:

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

The purpose of the IEEE 1588 Precision Time Protocol (PTP) is to synchronize the time between different nodes on an Ethernet network.

The Linux kernel has IEEE 1588 PTP support for a handful of ethernet devices that offer this feature including the Freescale IMX6 FEC which is used as eth0 on the majority of the Gateworks Ventana boards including the GW51xx, GW52xx, GW53xx, and GW54xx (Note GW5520 does not use the IMX6 FEC and instead provides 2x full GigE capable PCIe based MAC/PHY devices so it lacks IEEE 1588 hardware support).

In hardware PTP the ethernet MAC is responsible for getting and setting the timestamps to remove latency of the queuing and network stack which provides the best accuracy.

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

  • Supports hardware and software time stamping via the Linux SO_TIMESTAMPING socket option.
  • 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.

The linuxptp package is install on the Gateworks Ventana Yocto v1.8 BSP.

Example usage on a GW54xx:

  • 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.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:
    ptp4l[228.234]: 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


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. This signal can be used to get a high-precision time reference that an application can use to adjust system clock time. 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.

See the GPS page for more info

Last modified 2 years ago Last modified on 08/27/15 16:41:56
Last modified 8 months ago Last modified on 10/31/2017 02:31:08 PM