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.
Clock Error [ ms]
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.