[ntp:questions] time to sync vs ptp?

Brian Utterback brian.utterback at oracle.com
Fri May 31 19:27:52 UTC 2013


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:
> matthew.garman at gmail.com <matthew.garman at gmail.com> 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
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list