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.
RTT
Host R TT
800
R TT [ms]
600
400
200
0
3
6
9
12
15
18
21 24
Hours
27
30
33
36
39