[ntp:questions] Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

Serge Bets serge.bets at NOSPAM.laposte.invalid
Sat Aug 30 14:23:26 UTC 2008

Hello Steve,

 On Friday, August 29, 2008 at 17:53:30 +0000, Steve Kostecke wrote:

> Why does any of this matter when you have NTP to set the clock at
> start up?

For 3 main reasons:

 -1) hwclock can set the system clock much earlier in the boot sequence
than ntpd.

 -2) ntpd sometimes cannot set the clock at startup. Maybe the ADSL line
is temporarily down, the GPS satellites out of view, or the master
server stopped for maintenance.

 -3) The startup behaviour of ntpd is cleaner when the system clock was
already close. And ntpd -gq slews faster a small initial offset than
a large one.

hwclock --hctosys can be one of the first actions performed by init.
When it is well calibrated, hwclock can set the clock right to some
milliseconds. Then ntpd can quickly slew those few milliseconds
towards perfection. Ntpd practically never has to step the clock.

Hwclock also makes possible some ntpd usage scenarios. Like for example
ntpd syncing on a PPS-only refclock, without other means to number the
pulses than the system clock itself.

All this is possible when hwclock is well used. The problem is that many
distros use hwclock very suboptimally, calibrate drift wrongly, use the
util-linux fork instead of the real thing, call hwclock twice at startup
(just to waste precious time??), or leave eleven-minutes mode enabled.
This braindamage cannot give good results, and leads many people to
wrongly think that an RTC can't be better than the second. When one
should be able to expect some hundreds of microseconds after a reboot,
and some units of milliseconds after a night powered-off.

Serge point Bets arobase laposte point net

More information about the questions mailing list