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

Unruh unruh-spam at physics.ubc.ca
Sat Apr 5 18:27:37 UTC 2008


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

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

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

By enourmously more you mean 100 rather than 10 cycles? Ie, I cannot
believe that hwclock run once an hour would even be noticed on a quiet
machine running nothing else, never mind a machine doing something. 

Note that the advantage of recording the rate as well as offset of the rtc 
 may be illusionary. The rate is
determined when the machine is hot. The rate of the rtc is important when
the machine is off (cold) The rate of the rtc crystal as a function of temp
can be attrocious ( one of my machines has an rtc clock that varies from
0PPM to 100PPM with a few degree temp change-- I think the rtc may be
dying.)It is usually much worse than the temp dependence of the computer
crystal. 





>> 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.
>-- 
>Serge point Bets arobase laposte point net




More information about the questions mailing list