[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