figure 4. in-kernel measurement of the one-second gap between pulses from a GPs receiver using a RaDclock difference and RaDclock absolute clock. here the polling period to the server is 256 seconds. a single point per period is shown corresponding to the worst absolute error over the period.

Absolute Clock Difference Clock

Clock Error [ ms]

0 50 100

− 50

− 100

9

12

15

18

21

24

Hours

27

30

33

36

39

 

amounts to an error of only 10–7 · 1 = 0.1 µs. On the other hand, errors in Ca(t), and hence in the duration measurement, could be anything from several µs to several ms to larger than a second in extreme cases, depending on factors such as network congestion and algorithm robustness.

A better choice for the purpose of measuring time differences is to use a difference clock—that is, one that is not corrected for drift. A simple example is:

 

Cd(t) = C0 + pav · HPET(t)

 

where C0 is a constant (never updated), and pav is an estimate of long-term average rate, which we can think of as a constant (we are simplifying here slightly for clarity; see Veitch et al. 4 for details). Such a clock tells only approximately the right time and drifts, but does an excellent job of use 2 provided that pav can be robustly and accurately estimated (which it can). It is reliant on server timestamps, but in a much less sensitive and more robust way than Ca(t), as it takes direct advantage of the high stability (rate constant up to 0.1 ppm) of the local hardware.

Figure 4 compares the error in the
time between pulses entering the se-
rial port of a PC from a GPS receiver
(nominally precisely one second apart)
as measured by both an accurate abso-
lute clock and an accurate difference
clock. They are orders of magnitude
different, even though the server was
close by (minimum RTT of around
1ms). In fact, the operating system/se-
rial port adds a noise of around 2 µs to
these measurements and so actually
swamps the error in Cd(t): the differ-
ence clock is so good at the one-sec-
ond scale that it is a serious challenge
to measure its error!

time to Paradigm:
feedback or feed-forward?

Consider the following approach to synchronizing an absolute clock Ca(t). Timing packets are timestamped in the host using Ca. These timestamps are compared with those taken by the server, and an assessment is made of the clock error. The rate of Ca is then slightly adjusted to bring that error to zero over time. This is an example of a feedback approach, because the previous round of clock corrections feeds directly back as inputs to the algorithm, because it is the clock Ca itself that is used to generate the host timestamps.

An alternative is to use the underly-
ing counter to make raw packet time-
stamps (that is, counter readings) in
the host. The clock error is then esti-
mated based on these and the server
timestamps, and “subtracted out”
when the clock is read. This is a feed-
forward approach, since errors are
corrected based on post-processing
outputs, and these are not themselves
fed back into the next round of inputs.
In other words, the raw timestamps
are independent of clock state. One
could say that the hardware reality is
kept in direct view rather than seeing it
through algorithmic glasses.