[ntp:questions] Re: Drift handling....
martin.burnicki at meinberg.de
Tue Jan 3 21:35:47 UTC 2006
I've got the feeling that some clarification is required on drift values.
Let's have a look at an example:
Say you have some wristwatches and you want to check whether they are
accurate, or not. On the television there is a clock displayed whenever a
news programme is broadcasted. You trust that clock and see that one
wristwatch goes ahead by 1 minute every day, another one by 20 seconds, and
a 3rd one by just one second.
So the drift values are 1 minute/day, 20 secs/day, and 1 sec/day. If you
just let them freewheeling then the time difference between the clocks will
increase from day to day.
If you apply a daily correction to each of the watches which matches each
watch's individual drift value then obviously the watches will stop
drifting apart from day to day. The amount of correction required per day
depends only on the drift value that can be observed without correction,
i.e. the from tolerances when the wristwatches have been manufactured.
So life could be fine with those drift corrections, which you have
determined by comparing each of the clocks against the TV clock.
However, there are different TV channels. What if the clock displayed on one
channel differs from the clock on another channel?
If you first compare to one TV channel, and after a certain period to
another channel which presents a different time, then you will determine a
wrong offset for your wrist watch, and thus compute a wrong value for the
daily correction. If you switch back to the first channel later then the
effect will be reversed.
So not the *amount* of the required correction is important. It's important
that the *right* correction value is determined and applied. A wrong
correction value could just introduce new errors.
If we relate this example to computer clocks and NTP, we can state the
The computer clocks are derived from some kind of crystal on the
motherboard. That crystal has a certain nominal frequency, but due to
tolerances the real frequency is always more or less off. However, you
don't know how much it is off if you don't have a reliable clock to compare
NTP determines the amount and trend of the time offset between its own
system clock and a reference time source and applies corrections to the
system clock to make both the time difference and the trend of the time
difference (the drift) as small as possible. So the magnitude of the drift
value just tells you how much your computer clock would drift if it would
*not* be disciplined by NTP.
Unfortunately the frequency of cheap crystals varies strongly with the
environmental temperature, which normally changes relatively slow. The NTP
loop filters determine the varying frequency and adjust the required
compensation, the drift value, accordingly. So the order of magnitude of
variation of the drift value depends on the variation of temperature on the
mainboard, and on the quality of the crystal.
Of course this all can work correctly only if the reference time sources are
reliable. If there are several time sources which disagree about the right
time, and maybe drift against each other, then an NTP daemon might
determine a certain drift correction value from one reference time source,
and another value from another one.
If it applies the wrong drift value to its own system clock then its own
system time starts drifting from the right time, which in turn affects the
ongoing computation of the drift values, which might let the daemon discard
one reference time source, and switch to another one, which in turn results
in another drift value, and so on ...
This is basically what seems to have happened on some systems during the
recent leap second, and I hope my example (which should not be too
technical) helps to understand this.
More information about the questions