[ntp:questions] time to sync vs ptp?

unruh unruh at invalid.ca
Fri May 31 19:11:59 UTC 2013


On 2013-05-31, Rob <nomail at example.com> 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.

No. He will acknowlege that it can happen in theory (I gave a quick
handwaving explanation). But he is interested in the long term
stability, not the short term behaviour of the system. that kind of
behaviour will occur in any feedback system like ntpd uses. 

Assme that initially the offset is zero, but the rate is wrong by 10PPM.
The system will assume initially that everything is fine. It is only
when the rate error causes an offset to develop, that ntpd will begin to
alter the rate of the clock to correct that offset. It only does this
adjustment slowly so it will be a while ( while the offset has wandered
even further from zero) for the rate error to have been eliminated., By
then the offset is large, so the system will overcorrect to rate to
bring the rate back down to zero. If you handle the time factors and the
correction magnitude, the resulting system will be almost critially
damped so that there is not an oscillation. And if it is close to
critical damping then it also does not take too long. to reach that
state. 

It is not unexpected. With memory ( ie knowing what the past offsets
were and the rate corrections were) one can much more raplidly approach
the stable euqilibrium.  That is what chrony does. Tests that both I and
Lichvar have done indicate that chrony not only does it much more rapidly approach 
stability, but also creates a smaller average offset spread than does
ntpd in many situations (the spread of offsets are between a factor of 2
to 20 times better than with ntpd). Certainly more tests, under a wider variety 
of conditions are needed.



More information about the questions mailing list