Speed of ntp convergence - NTP

This is a discussion on Speed of ntp convergence - NTP ; Hal Murray wrote: >>Note, if you are running gps, why have a poll level 6? The recommendation >>for ref- clocks is poll level 4? > > Where/who does that recommendation come from? I don't have seen this recommendation on the ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 43 of 43

Thread: Speed of ntp convergence

  1. Re: Speed of ntp convergence

    Hal Murray wrote:
    >>Note, if you are running gps, why have a poll level 6? The recommendation
    >>for ref- clocks is poll level 4?

    >
    > Where/who does that recommendation come from?


    I don't have seen this recommendation on the internet, but from our
    experience with the devices we sell initial convergence against a built-in
    refclock is indeed very much faster if the poll intervall is clamped down
    to 4.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  2. Re: Speed of ntp convergence

    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


  3. Re: Speed of ntp convergence

    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





+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3