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

Unruh unruh-spam at physics.ubc.ca
Sat Aug 30 16:54:47 UTC 2008


Serge Bets <serge.bets at NOSPAM.laposte.invalid> writes:

>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.

As you know, linux's use of the hwclock/rtc is now seriously damaged with the
hpet stuff. The stadards, probably set by MS, are that when hpet is
enabled, all the interrupts from the rtc are hjacked and never delivered to
the system as rtc interrupts. The Linux munge is to more or less do a poll
with a 16ms ( not microsec) quantization. hwclock can apparently get around
this using the directisa option by polling the rtc ( using up immense
computer resources for a second or two). It is a totally rediculous
harware decision by Intel. 

(And yes, Mandriva uses the util-linux version)

Why does Brian not get his version back into util-linux?





More information about the questions mailing list