[ntp:questions] ntpd and hw clock
unruh-spam at physics.ubc.ca
Sat Feb 28 00:46:14 UTC 2009
Steve Kostecke <kostecke at ntp.org> writes:
>On 2009-02-27, Unruh <unruh-spam at physics.ubc.ca> wrote:
>> Steve Kostecke <kostecke at ntp.org> writes:
>>>On 2009-02-27, Nero Imhard <nim at pipe.nl> wrote:
>>>> Silly indeed, but rather Linux-specific. No such kludge in FreeBSD
>>>Why do you consider a periodic update of the RTC to be a kludge?
>> Because it does not allow one to determine the frequency offset of
>> the rtc, info which can be used to improve the starup accuracy of the
>> system from the rtc.
>That's a non-issue for virtually all users.
Just as having accurate time on the system is a non-issue for virtually all
users. It is for those people who are actually interested in having
accurate time that this discussion exists surely.
>> This is supported by both chrony and by the new (non-utils) hwclock.
>> The 11 min mode completely destroys that.
>Then disable the 11 minute mode if your application (i.e. the purpose
>your computer is used for) requires it.
It is like running a computer using rdate to update the system clock
periodically or using ntp to update the time and rate periodically.
If you want to use rdate periodically, noone can stop you, but most of the
contributors to this discussion would argue that ntp is a better mechanism.
>> It would be like instituting a procedure by which ntp polled the
>> external sources and simply reset the clock each time it found an
>You're implying that there is some sort of mechanism to discipline the
>RTC. As far as I know on a Linux system the RTC is read at start up,
>periodically updated while the sytem is running and updated during the
>shut down process.
Yes, both chrony and hwclock have a mechanism to "discipline" the HW clock.
They keep a record of the rate difference between UTC and the hardware
clock, and when they read the hwclock they can apply that rate difference
to correct the reading. This is of course almost exactly what ntp does for
the system clock (It adjusts the actual rate by offsetting it instead of
correcting the reading, but that difference is minor. )
Ie, on a Linux system without the 11 min mode, the clock is read by
hwclock/chrony at startup, the rate difference is computed during the
running ( without adjustment of the clock itself) and is recorded at
shutdown. It is not updated at shutdown unless the user/shutdown script
explicitly institute that updating.
More information about the questions