[ntp:questions] Speed of ntp convergence

Unruh unruh-spam at physics.ubc.ca
Sat Nov 1 03:17:15 UTC 2008




Just another data point on the behaviour of ntp. My ntp went down ( due to
something removing the ntp user from the password file). When I brought it
back up again, the time  was out and I think the drift file was out. 
I have three sources-- a stratum 2 nearby server, a distant stratum 1 server and
a gps refclock with a PPS. The PPS is setup to drive the refclock_shm driver. 
The refclock has a poll of 4 (pollinterval of 16), and both the other are
default ( minref 6 maxref 10) 
I brought the system back up at 54770 78683.101 (the ntp log file date and
time) The way the PPS works is that it waits about 5 min until it is sure
that ntp has the time from the other servers to within 250ms. It then
switches on the shm driver. The refclock started out with an offset of
about 150ms , which increased to 280ms and  was eventually (about 6 min later) reset to zero offset
because I was running with the -g for ntp. 

This was also the point at which the PPS shm kicked in.
However the drift rate was clearly off, because the offset then gradually
increased until at 82555 (3878 sec after the start or about 1hr)  it was 52ms off (the 
maximum offset) . By the end of the day ( 86400
or about 7700sec or 2 hrs) it was still 19ms offset from the PPS zero time. 

An hour later, it was still 7ms off, another hour, 2.6ms and another hour
later, still 1.2 ms off. Ie, only after about 6 hours was it within a ms of
the correct time. Now, usually this PPS controls the time to within about
2us (not ms, usec) but it is apparently going to take over 10 hours to get
there. That is of course completely rediculous. 

The shm poll interval is 16 sec and even if ntp throws away 7/8 that would
give a max time between data points of about 128sec or 2 min. Thus ntp should
have a time constant of about 4 min. Instead the time constant is about an
hour. It would seem that the time constant is selected as far longer than
the longest poll inteval. ( the poll interval during this time on the other
two source was 64 sec, or poll interval of 6).

 Within the first minute, I could by hand
determine the offset and slope of the CPU clock to withing a few usec not
msec or tens  of msec. and the slope to better than 1PPM. 

But never mind my concern about the markovian system feedback system ntp
uses. That argument I am sure everyone is tired of. What concerns me is
the long (1hr) time constant of the feedback loop, about 200 times longer
than the poll interval. Ie, it does not seem to me that ntp is fulfilling
its design criteria.


Here after 5.5 hours after startup is the ouput of ntpq -p

string[root]>ntpq -p
     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
+tick.usask.ca   .GPS.            1 u   18   64  377   44.925    1.455 4.252
+ntp.ubc.ca      140.142.16.34    2 u   44   64  343    0.672    0.260 0.767
*SHM(0)          .PPS.            0 l    1   16  377    0.000    1.136 0.023






More information about the questions mailing list