There was a bug in the start up of NTP that caused it to set the
frequency before setting the first offset. This meant that the kernel
PLL treated the first offset correction as a "drift" in time since the
time the frequency was set (seconds before) which introduced a sudden
jerk to the loop, which, depending on the circumstances, might send it
careening off the mark.
I reported this as bug 1044. I believe that the fix for bug 1981 may
have fixed this, but I have not verified it yet.
On 5/31/2013 11:49 AM, Rob wrote:
[email protected] <[email protected]> wrote:
On Thursday, May 30, 2013 2:21:15 PM UTC-5, Rob wrote:
I have a server running NTP 4.2.2 (as part of the RedHat 5.7 release). Last night I
changed it's /etc/ntp.conf file, specifically the "server xyz" line to point to
a new NTP server.
After doing this, the clock's offset was *increasing* after an hour. Offset is measured
by "ntpdate -q peer".
This is a wellknown problem.
When you do a couple of ntpd shutdown/restarts e.g. because you
a experimenting with different server configurations, the combination
of ntpd and the kernel goes haywire and it will actually steer the time
the wrong way.
Just wait a day or so, and it will have solved itself.
Would it be possible to provide a link or point me to some reference material
where I can read more about this issue?
I think the issue is never acknowledged by the author. He believes
his system is proven to be stable. It is only in practice that we
see this happen, it cannot happen in theory.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
