Communications - May 2010

perfect reference clock). In the host, delays arise from the NIC (network interface card) behavior, operating-system process scheduling, and the architecture of the packet timestamping code, and are on the order of several tens of microseconds. In the network, they are caused by queuing in network elements such as IP routers and Layer 2 switches, and vary from a large fraction of a millisecond over a Gigabit Ethernet LAN to possibly hundreds of milliseconds

figure 1. the time according to some simple clocks as a function of true time.

Clock Time

Cs (tk)

Constant
Skew Clock
Perfect Clock

Constant Offset Clock Drifting Clock

Cd (tk)

when network congestion is high and the server more than a few hops away.

In a bidirectional synchronization paradigm, which we focus on here (the alternative is to broadcast from the server only), timing packets are exchanged in both directions (see Figure 2). The OWD (one-way delay) in both the forward (host to server: d�) and backward (server to host: d¯) directions have their own separate host and network components. Adding the OWDs in each direction yields the host®server®host RTT (round-trip time).

Figure 3 provides an example of the RTTs for timing packets when both the host and server are on a LAN, as well as the host component by itself. Each varies well above its minimum value, which translates to the addition of a large “noise” that the sync algorithm must somehow see through.

Cp (tk)

Co (tk)

tk

True Time
the Right clock for the Job

figure 2. Bidirectional exchange of timing packets between host and server. a symmetric route would have A = d ≠ – dØ = 0, but that is not the case here. the Rtt is r = d≠ + dØ.

Server

d�

d¯

Network
Host
time

r

˲ ˲Define a universally comparable
and triggerable event label, the “time
of day.”
A perfect clock is ideally suited for
each of these purposes, but in the real
world, hardware and software limita-
tions mean that the best performance
is achieved by specialist clocks. The
need to choose the right clock for the
job is crucial and is not widely under-
stood.

When one thinks of a clock, it is the third use that typically comes to mind: a clock that tells the absolute time. Synchronizing such a clock, however, is inherently difficult in the face of delay variability. As a result, the accuracy of an absolute clock Ca(t) can be low, highly variable over time, and a slave to network conditions. Absolute clocks must also support the ability to be jump-re-set, including backward. Though this may be rare, it makes them less than ideal for use 1.

A better choice for establishing temporal order is a well-behaved raw counter such as HPET(t), which increases monotonically. Equivalently, one can scale such a counter to form a simple causal clock calibrated in seconds: Cc(t) = p0·HPET(t) where p0 is a constant that is never updated. Such a clock tells the wrong time and drifts, but does an excellent job of use 1 and is completely independent of network conditions, in fact not requiring server timestamps at all!

The errors of an absolute clock Ca(t) also make it unsuitable for use 2. This is best seen through an example: if a counter has a rate error of 0.1 ppm (this is quite typical in a PC under reasonable temperature environments), then over a one-second interval the drift

figure 3. the Rtt of timing packets over a congested Lan, and the host component separated out. each component can be modeled as a minimum value plus a positive noise.