Many applications in factory automation, test and measurement, and telecommunications require very close time synchronization. The usage case for this 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:
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:
The linuxptp package is installed on the Gateworks Ventana Yocto v1.8 BSP.
Example usage on a GW54xx:
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
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
References:
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
= Octeon TX IEEE 1588 From CN80xx refrence 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_PF_PKIND(0..15)_CFG[HDR_SL]). 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. [[Image(cavium-octeon-tx-block-diagram.jpg, width=600)]]