[ntp:questions] Linux 11-minute mode (RTC update)

Serge Bets serge.bets at NOSPAM.laposte.invalid
Sat Apr 5 15:25:31 UTC 2008

 On Friday, April 4, 2008 at 14:25:12 +0200, Noob wrote:

> If I don't want the kernel to update the RTC, I can always undef

Ah thanks! I wasn't aware of this new switch. I hope Dean is reading, he
was after an easy solution.

> Do you believe that running hwclock --systohc periodically is better
> than using the kernel's 11-minute mode?

There is a cost: eleven-minutes mode is extra-light on processor cycles.
Depending on the mode of operation, hwclock consumes either much more,
or enormously more cycles. OTOH its drift compensation allows sparser
usage. And the accuracy is way better, and well worth the cost IMHO.

> I use http://giraffe-data.com/software/about_hwclock.html

Good: that's the best version.

> If I use hwclock to update the RTC, how often should I do it?

It depends on your expectations. As Hal said, once per hour or once per
day seem quite sufficient. I used to use a daily cron job, with
excellent results. Stopped it only because I don't manage any 24/7
machine anymore.

Let's compare: The eleven-minutes mode needs to write the RTC every
11 minutes because its drift is not compensated, and will very quickly
degrade future reads. Example an RTC with a 100 PPM drift rate. After
10 minutes there is already a 60 ms offset. Just then happen 20 minutes
of power outage. When power comes back, the RTC has accumulated 180 ms
of drift. During bootup the kernel clock initialises with this offset,
that ntpd will have to step.

During bootup, hwclock --hctosys compensates the drift since the last
write by hwclock --systohc. This last write happened either during a
clean shutdown, or in a cron job some hours before a power failure.
Example: same 100 PPM rate, same 20 minutes of outage, but happening
23 hours after the daily cron job. At restart, the RTC has accumulated
8.4 seconds of drift. But during bootup hwclock compensates this
entirely, and the kernel clock is hopefully initialised "perfect", or
rather at some low milliseconds of the One True Time.

Conclusion: an hwclock once per day is already better that an
eleven-minutes mode 130 times per day.

> What do you think about the following script?

 - Sleep 55 minutes minimum (otherwise drift rate is not reevaluated).
 - Call hwclock only when the kernel clock is synced.
 - Better resist to system load with --cpupriority=99

| while true
| do
|   sleep 86398
|   if adjtimex --print | grep -q " return value = 5"
|   then
|     honk --db=130 --cucaracha
|   else
|     hwclock --utc --systohc --cpupriority=99
|   fi
| done

> Is the crystal of the RTC supposed to be more stable than the crystal
> of the CPU?

No. And the RTC has to run in a much wider temperature range. Typical
kernel clock can vary by one or two PPM. Typical RTC by 12 PPM. Unless
in an always-on machine, where the RTC variation may stay similar, one
or two PPM.

In the 24/7 situation, with power outage of maximum 20 minutes, the
bootup hwclock needs to compensate the RTC drift accumulated during
a mixed period of 0 to 24 hours of power-on plus 0 to 20 minutes of
power-off. Those 20 minutes are barely sufficient for a complete
cooling. So let's pretend it's all power-on drift, and let hwclock
evaluate it. Just what happens every day with the above script.

If the expected power outages can reach 2 hours, or 2 days, then it's
another story.

Serge point Bets arobase laposte point net

More information about the questions mailing list