Ethernet for synchronization: It's about time

Story

October 17, 2017

Andrew McCoubrey

Curtiss-Wright

Today's embedded systems often include several counters and clocks that keep track of time, and ensuring that they are accurate - and synchronized across multiple devices - can be critical. For example, synchronized clocks can be used to partition shared resources (such as network links) in distributed systems with critical real-time requirements.

Today’s embedded systems often include several counters and clocks that keep track of time, and ensuring that they are accurate – and synchronized across multiple devices – can be critical. For example, synchronized clocks can be used to partition shared resources (such as network links) in distributed systems with critical real-time requirements.

Most computers connected to the Internet use the Network Time Protocol (NTP) to set their clocks, obtaining the time of day from a remote server. NTP servers on the Internet get their time source from one of the authoritative servers connected to an atomic clock. In turn, these servers can relay time data to other NTP servers or clients.

To synchronize with an NTP server, a client first sends a request, then waits for the reply; both the request and reply may need to traverse several hops in the network, suffering delays caused by switches and routers in the path. These delays can add up: When a client receives a time of day response from an NTP server, it may already be hundreds of milliseconds old. While a millisecond may prove trivial in many everyday applications, that delay can be a matter of life and death in deployed command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) systems.

GPS receivers, with a highly accurate time of day provided by atomic clocks via satellite, can also serve as a useful reference clock. Because many GPS receivers output time of day over a serial port, they are typically only useful for synchronization to within a few milliseconds. To enable high-precision synchronization, many GPS receivers require a so-called 1PPS (one pulse per second) output. This interface produces a pulse once per second, at the top of the second. Using this approach, a clock can be synchronized with an error of as little as one nanosecond (ns), or a billionth of a second.

One downside for embedded systems, however, is that dedicated hardware must be provided to process the 1PPS signal. In addition, the serial port and 1PPS must be routed to each client device. In larger systems, this can involve significant complexity and cabling. The IEEE 1588 Precision Time Protocol (PTP) – which addresses the limitations of NTP and GPS for synchronization of systems on a local network – can provide submicrosecond synchronization. When all devices in the network provide full hardware support for the latest PTP standard, synchronization within a few ns is possible.

PTP was first promulgated as PTPv1 (1588-2002) in 2002; a major update in 2008 resulted in PTPv2 (1588-2008). The 2008 standard redefined the format of the PTP messages, so the two versions are incompatible.

Since PTP is typically deployed on local networks, any delay is generally smaller and more predictable than when synchronizing using NTP over a wide area network (WAN). However, variable delays due to queueing and processing are present even on high-performance Ethernet switches. To address this situation, PTPv2 introduced the new concept of a “transparent clock.” A switch with transparent clock support notes the time that it receives a PTP packet on an ingress interface, and notes it again when the packet is transmitted on an egress interface. The switch can then inform the PTP message recipient of the delay introduced by the switch. In this way, network delay can be fully eliminated as a source of synchronization error.

Although implementing PTP in embedded systems can be as simple as installing a software client, to achieve the highest levels of synchronization, designers need more than just software. PTP packet processing in hardware is a common feature in most of the latest PHY devices and Ethernet adapters. When combined with an appropriate driver, support for PTP in networking devices provides application software with access to a high-precision clock that is synchronized to other modules in a system.

Applications that require data to be time-stamped with high precision may call for specialized hardware (for example, in a field-programmable gate array [FPGA]) that can sync with the PTP clock directly. For this reason, many PTP-capable adapters and physical layers (PHYs) will output a hardware signal (similar to the GPS 1PPS) that can be used to drive timing-aware hardware. (Figure 1.)

Figure 1: Curtiss-Wright’s VPX3-652 Ethernet switch is an example of an IEEE 1588-2008 PTP implementation. When configured as a transparent clock, it uses integrated timing hardware to measure and report packet transit time, enabling submicrosecond sync across the network.

Maintaining accurate time is critical for many embedded computing applications. With components that feature support for IEEE 1588 PTP, synchronization can be as simple as connecting to the network.

Andrew McCoubrey is the product marketing manager, switching and routing solutions, for Curtiss-Wright Defense Solutions.

www.curtisswrightds.com