Basics of real-time measurement, control, and communication using IEEE 1588: Part 4

John C. Eidson, Agilent Technologies

January 23, 2008

John C. Eidson, Agilent Technologies

The effect of path asymmetry on the calculation of clock offset can be seen from the example in Table 3.1, below.

Table 3.1. Example of asymmetric delay on offset computation

In this example, it is assumed that the slave clock is 1 h ahead of the master, and that the master-to-slave propagation delays, and the slave-to-master propagation delays, are 30 and 40 min, respectively. In the table, entries enclosed in parenthesis are not used in the computations but are for reference only.

The example computed values for offset and one way delay of 55 and 35 min, respectively, are in obvious disagreement with the assumed offset of 1 h and the 30 and 40 min delays assumed between master and slave, and slave and master. The disagreement in each case amounts to half of the asymmetry in the assumed delay values.

It is clear that the timestamps associated with sending and receiving Sync and Delay Req messages are critical to the operation of the protocol. Synchronization accuracy will depend in part on the accuracy and repeatability of timing information derived from these timestamps.

Figure 3.10 below illustrates the principal sources of timing impairments for a typical Ethernet-based clock and switch.

Figure 3.10. Timing impairments of system components

Approximate values for the impairments in Figure 3.10 for a 10/100 BaseT Ethernet system are shown in Table 3.2 below. The impairments from operating systems arise from queues in the protocol stack, interrupt service routine timing differences, context switches, and load- and application-specific variation in code execution times.

Table 3.2. Approximate Ethernet timing impairments

Switch impairments arise from input and output queuing and variation in the access patterns to the switch fabric. Switches also have an additional impairment, in that the path taken by the Sync and Delay Req packets may not be the same, thereby introducing asymmetry.

The PHY layer fluctuations and asymmetry arise primarily from the operation of the phase lock loops in the receive path that are used to recover the received clock signal. Cable-induced fluctuations are typically small, and arise from microphonics and similar causes.

Asymmetry in some cables, for example, CAT-5 cable often used in Ethernet, is intentionally introduced to reduce crosstalk between wire pairs. The values for switch impairments, and to some extent operating system impairments, are network traffic-dependent. Similar timing impairments are introduced by the components of all transport technologies.

The magnitudes of the delay, fluctuation, and asymmetry values in Table 3.2 clearly require correction to achieve the goal of sub-microsecond synchronization accuracy. Although not specified in IEEE 1588, the clock architecture shown in Figure 3.11 below is particularly useful in overcoming operating system and protocol stack impairments within an ordinary clock.

Figure 3.11. Architecture of an ordinary clock in master state

Figure 3.11 shows several useful IEEE 1588-specific hardware functions. The key element is the packet recognizer and capture block (PRC block). This block passively observes both transmitted and received packets at a point as close to the network connection as possible.

In an Ethernet environment, the media-independent interface (MII) is the easiest point of access. The PRC block selectively detects all Sync and Delay Req packets. The details shown are typical of an Ethernet-based node, and will be used in this discussion. Similar techniques can be used for other network technologies, although the details of the PRC block will differ.

The PRC block also:

Captures a snapshot of the local hardware clock to generate the appropriate timestamp t₁, t₂, t₃, or t₄ depending on whether the unit is a master or slave, and whether the packet is a Sync or Delay Req packet.

Captures identification fields from these packets. This identification is used by the IEEE 1588 code to properly associate the timestamp with the correct Sync or Delay Req packet.

The timestamp and captured identification information is sent to the IEEE 1588 code via a hardware interface and the operating system. In the case of a clock in the master state (Figure 3.11), this information is included in the Follow Up message.