[ntp:questions] Speed of ntp convergence

Bill Unruh unruh at physics.ubc.ca
Sat Nov 8 01:53:26 UTC 2008


The key seems to be the lines:

       etemp = min(mu, (u_long)ULOGTOD(sys_poll));
       dtemp = 4 * CLOCK_PLL * ULOGTOD(sys_poll);
       plladj = fp_offset * etemp / (dtemp * dtemp);

Ie if we assume that the etemp is determined by the poll interval, we have
plladj=fp_offset /(16*CLOCK_PLL^2*(Sys poll time)

That is a huge time scale. Surely CLOCK_PLL should only come in there to
the first power (at most), not squared.

 




Unruh <unruh-spam at physics.ubc.ca> writes:

>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