[nSLUG] Clock drifts badly even when machine is up
dflogeras2 at gmail.com
Sat Jul 2 11:17:11 ADT 2016
Just a couple of comments which may or may not be helpful debugging.
First, it seems that ntpdate is known to be problematic. From the 4.2.8_p8
"Disclaimer: This program has known bugs and deficiencies and nobody has
volunteered to fix them in a long time. The good news is the functionality
originally intended for this program is available in the ntpd and sntp
Not sure how buggy, or if this has anything to do with your problem, but it
Second, it is also my understanding that the RTC is consulted at boot, and
in at least my case (Gentoo) written during shutdown. Otherwise, it is
left alone. Other distros may do the writing part differently, or not at
all. I believe I configured my systems to write at shutdown, because since
I am running ntpd, and my systems tend to be on for very long periods, then
the kernels time should be more accurate than the RTC which may drift.
This being said, to attempt to diagnose, you may try the 'hwclock -r'
command to query the rtc in your machine. If the RTC is indeed drifting by
large amounts, and the battery is fresh (and/or drifting while powered)
then there may be some other type of hardware failure like the oscillator,
or the RTC itself.
However, if your system clock (ie the kernel's time) is drifting by that
much while being turned on, then either ntpd is broken (you should be able
to see when and how much it adjusts by in your logs), or (wayyy less
likely) that some other type of hardware failure might be causing the
kernel to miss ticks and lose time.
Last, ntpd does have a default "panic time" which is typically 1000s (just
over the 13m mark you have). It will not adjust the clock more than 1000s
(this can also be overridden with -g). Just know that if your clock is off
by that much, it will throw up its hands and quit.
Sorry nothing specific, but hopefully that helps in your cause.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG