[ntp:questions] Linux 11-minute mode (RTC update)
unruh-spam at physics.ubc.ca
Mon Apr 7 17:46:21 UTC 2008
Serge Bets <serge.bets at NOSPAM.laposte.invalid> writes:
> On Sunday, April 6, 2008 at 19:36:40 +0000, Unruh wrote:
>> Serge Bets <serge.bets at NOSPAM.laposte.invalid> writes:
>>> The eleven-minutes write takes some tens of microseconds; normal
>>> hwclock some tens of milliseconds; hwclock --nointerrupt some plain
>> To write the rtc properly takes at least a second.
>I was talking about processor time consumed. As for wall clock time
>elapsed, indeed a background cron job mostly sleeping or waiting for an
>interrupt during one or two seconds is rather harmless.
>> In the case the machine comes up again in a few seconds, the rate
>> correction is irrelevant anyway.
>Drift compensation is important even for a stop and go: maybe the stop
>was a crash, and the RTC was last written hours ago. But the point was
>more that as long as the downtime stays short, the temperature of the
>RTC, and thus its instant drift rate, does not vary too much from the
>mean runtime values. Therefore it makes sense to pick the runtime rate
>for compensation. Only in this specific 24/7 case.
We are discussing the hwclock vs the 11 min rule. Thus the last time the
rtc was corrected ( perhaps badly if the rtc correction in the kernel is
badly implimented) was a max of 11 min ago. Even at 100PPM drift that is
Thus, if it is true that the hwclock routine sets/reads the system clock
better than does the kernel, and if your drift rate is that high, then it
is probably better to do the hwclock route.
Note as I pointed out, the temp dependence of the rtc can be huge ( and is
typically much larger than the temp dependence of the cpu crystal.) The
insides cool off rapidly if the system shuts down. The temp sensitivity of
a bunch of computers I run have a 4-20 x more sensitivity for the rtc than
for the onboard clock. Thus if the cpu is say .5PPM/deg, the RTC will be up
to 10PPM/deg. Since the computer cools of by at least 10 deg very rapidly,
that is up to 100PPM difference in the RTC between on and off.
If the server goes off for 10-30 min ( not unusual for example with a disk
failure, or with response time of the person) that is 100s of msec.
It would I admit be interesting to actually do some experiments to see how
much worst the rtc is cooled than warm.
And also whether or not the Linux kernel actually does a decent job of
setting the rtc.
>> And if the system reads the clock badly it will be out by about a
>> second anyway.
>This never happens on a proper setup: hwclock --hctosys syncs on the RTC
>down to a few microseconds.
>Serge point Bets arobase laposte point net
More information about the questions