Martin Burnicki wrote:
> David J Taylor wrote:
[]
> As mentioned in another reply, AFAIR older versions of the NTP daemon
> did converge quite a bit faster than recent versions.
[]
>> version="ntpd 4.2.0-a Sun May 8 06:01:21 UTC 2005 (1)"
>
> Now the question is how a recent version of ntpd would converge on
> this machine.
>
> Martin

An intersting point, Martin. As it took about 5 hours overnight to
re-compile the kernel on that system, and as I know very little of
FreeBSD, I am unlikely to change it in the near future. Particularly if
it's worse!

What I would actually like to have is a small PC (perhaps even an adapted
router or something like that) which had a serial port and Ethernet port
so that I could retire the Pentium 133MHz system for good. Something like
the ASUS displayless EEE box:

http://www.asus.com/products.aspx?l1...89&modelmenu=1

Cheers,
David

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 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