[ntp:questions] no ntp synchronisation: 2s to 6s time shift !

Serge Bets serge.bets at NOSPAM.laposte.invalid
Wed Feb 20 16:32:48 UTC 2008


 On Tuesday, February 19, 2008 at 17:45:59 +0100, Thierry MARTIN wrote:

> The system I have is a (trans)portable machine. I wonder wether these
> parameters will be ok, wherever I place it (what is the influnce of
> temperature differences or things like that)?

Of course the temperature influences the drift of the clocks. When you
run ntpd continuously and graph the kernel frequency, you clearly see
night and day cycles, seasonal cycles, "accidents" like the heater
stopped during 2 hours, periods where the computer is iddle or does
heavy work, and days where the sun shines. Ntpd compensates those
variations continuously, correcting the frequency to stay in phase with
The Real UTC Thing.

The frequency difference between a winter night and a summer day depends
on the machine and various conditions, but I seem to typically see
around 2 PPMs. When ntpd is not there to compensate in real time, your
goal is to calculate a mean frequency, that will suit your own usage of
the machine. On a 24/7 server, pick the mean over 24 hours. On a
workstation, pick mean of work hours. And so on.


The temperature influences also the RTC drift rate. And there is there
a major additional source of temperature variation: is the machine on,
or off? One also has to calculate a mean drift, but more to suit the
*non-usage* of the machine. Let me explain:

An accurate RTC is important at one occasion: The boot sequence, when
hwclock --hctosys reads the RTC, applies the drift correction, and
initialises the system clock. The RTC has then drifted since the last
time hwclock --systohc had set it. Typically, this happend during the
previous shutdown. In those conditions, to have a good correction factor
to apply at boot, one should evaluate the drift during power-off time.
This could be schematically:

|	at the end of the day:
| # ntpdate -b ntp.cines.fr
| # hwclock --systohc --nodrift
| # shutdown -h now
|	wait next morning, then restart the machine, and soon after:
| # ntpdate -b ntp.cines.fr
| # hwclock --systohc

This is important, as bad procedures evaluating the RTC drift wrongly
during runtime are a major source of error, maybe a dozen PPMs, one
entire second/day, resulting in several hundreds of milliseconds offset
on the next morning.

Note that the default setup of many Linux distributions doesn't do that
well. They evaluate the RTC drift from shutdown to shutdown, over mixed
periods of half runtime and half poweroff. I fear the difference to be
so big that such a compromise can suit nearly noone.

I wonder how Chrony behaves with the RTC?


Cordialement, Serge.
-- 
Serge point Bets arobase laposte point net




More information about the questions mailing list