Slow convergence of NTP with GPS/PPS - NTP

This is a discussion on Slow convergence of NTP with GPS/PPS - NTP ; Hi We are using Linux ntpd with GPS/PPS reference clock to discipline the time on our systems. Our application requires good time accuracy (better than 5ms) but it also needs to get there quickly (as quickly as possible, but ideally ...

+ Reply to Thread
Page 1 of 6 1 2 3 ... LastLast
Results 1 to 20 of 108

Thread: Slow convergence of NTP with GPS/PPS

  1. Slow convergence of NTP with GPS/PPS

    Hi

    We are using Linux ntpd with GPS/PPS reference clock to discipline the time
    on our systems.

    Our application requires good time accuracy (better than 5ms) but it also
    needs to get there quickly (as quickly as possible, but ideally taking no
    more than about 15 minutes).
    (The Linux/ntpd is running on a remote embedded device that is frequently
    restarted - possibly once a day or so - so we cant wait hours for
    convergence).

    Currently ntpd can take hours to achieve the desired acuracy.

    So, the question is simple - is there any way to significantly speedup the
    convergence of ntpd (using GPS/PPS reference clock)?

    We would be prepared to compromise somewhat on accuracy and jitter.
    (Currently accuracy and jitter values are excellent with jitter as low as 1
    microsecond and accuracy better than 10 uS but it can take a day or two to
    get there).

    It does not seem unreasonable to expect that the ntpd could achieve the
    required accuracy within 15 minutes or so - but nothing we have tried seems
    to work.
    Have tried modifying some of the tinker values, but we dont really
    understand what they all do - and have not really had any success.

    So to summarise:

    1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
    clock)?
    2) If so, how - and what are the tradeoffs?

    Any help appreciated
    David

  2. Re: Slow convergence of NTP with GPS/PPS

    David McConnell wrote:
    > Hi
    >
    > We are using Linux ntpd with GPS/PPS reference clock to discipline the time
    > on our systems.
    >
    > Our application requires good time accuracy (better than 5ms) but it also
    > needs to get there quickly (as quickly as possible, but ideally taking no
    > more than about 15 minutes).
    > (The Linux/ntpd is running on a remote embedded device that is frequently
    > restarted - possibly once a day or so - so we cant wait hours for
    > convergence).
    >
    > Currently ntpd can take hours to achieve the desired acuracy.
    >
    > So, the question is simple - is there any way to significantly speedup the
    > convergence of ntpd (using GPS/PPS reference clock)?


    If you are using a recent version of ntpd, start it with the "-g"
    switch. That will cause it to set the clock to the correct time once
    only! If you have a good drift file, you should be synchronized in
    thirty seconds or so and be within ten milliseconds, or less, of the
    correct time.

    Try not to reboot unless absolutely necessary. I realize that some
    versions of Windows need fairly frequent reboots but there are are
    versions that should run for many days or weeks between reboots. My
    desktop system is W/XP SP2 and has been up for at least a couple of
    months and may stay up for another couple of months.



  3. Re: Slow convergence of NTP with GPS/PPS

    Richard B. Gilbert wrote:

    >
    > If you are using a recent version of ntpd, start it with the "-g"
    > switch. That will cause it to set the clock to the correct time once
    > only! If you have a good drift file, you should be synchronized in
    > thirty seconds or so and be within ten milliseconds, or less, of the
    > correct time.


    My understanding was that -g turns off the 1000 second check for the
    first step, but still leaves the time within +/- 128ms, which will still
    take an unacceptable time to converge to +/- 5ms. Certainly the 4.2.4p4
    documentation makes no claims for it beyond once only disabling the 1000
    second check.

    >
    > Try not to reboot unless absolutely necessary. I realize that some
    > versions of Windows need fairly frequent reboots but there are are


    I imagine this is some sort of embedded system, which he can't control,
    but might be switched off outside office hours, in part because that is
    the socially responsible thing to do.

  4. Re: Slow convergence of NTP with GPS/PPS


    [demime 1.01d removed an attachment of type multipart/signed]

  5. Re: Slow convergence of NTP with GPS/PPS

    Kevin Oberman wrote:
    > [demime 1.01d removed an attachment of type multipart/signed]


    This has failed to reach the newsgroup.

  6. Re: Slow convergence of NTP with GPS/PPS

    David Woolley wrote:
    > Richard B. Gilbert wrote:
    >
    >>
    >> If you are using a recent version of ntpd, start it with the "-g"
    >> switch. That will cause it to set the clock to the correct time once
    >> only! If you have a good drift file, you should be synchronized in
    >> thirty seconds or so and be within ten milliseconds, or less, of the
    >> correct time.

    >
    > My understanding was that -g turns off the 1000 second check for the
    > first step, but still leaves the time within +/- 128ms, which will still
    > take an unacceptable time to converge to +/- 5ms. Certainly the 4.2.4p4
    > documentation makes no claims for it beyond once only disabling the 1000
    > second check.


    I don't recall that +/- 128ms is specified anywhere. If ntpd gets it's
    initial time from a hardware reference clock, the time SHOULD be very
    close. This will, off course, depend on the latencies in the reference
    clock's response and the resolution of the time supplied.


  7. Re: Slow convergence of NTP with GPS/PPS

    davidm@pipstechnology.co.uk (David McConnell) writes:

    >Hi


    >We are using Linux ntpd with GPS/PPS reference clock to discipline the time
    >on our systems.


    >Our application requires good time accuracy (better than 5ms) but it also
    >needs to get there quickly (as quickly as possible, but ideally taking no
    >more than about 15 minutes).
    >(The Linux/ntpd is running on a remote embedded device that is frequently
    >restarted - possibly once a day or so - so we cant wait hours for
    >convergence).


    >Currently ntpd can take hours to achieve the desired acuracy.


    Are you using the -g option? What is the poll interval for your gps clock?
    (Use 4 whcih I think is the default for gps clocks.)

    ntp is NOT designed for rapid convergence, but on a gps clock with poll
    interval 4 and -g it sure should be better than hours.


    >So, the question is simple - is there any way to significantly speedup the
    >convergence of ntpd (using GPS/PPS reference clock)?


    >We would be prepared to compromise somewhat on accuracy and jitter.
    >(Currently accuracy and jitter values are excellent with jitter as low as 1
    >microsecond and accuracy better than 10 uS but it can take a day or two to
    >get there).


    >It does not seem unreasonable to expect that the ntpd could achieve the
    >required accuracy within 15 minutes or so - but nothing we have tried seems
    >to work.
    >Have tried modifying some of the tinker values, but we dont really
    >understand what they all do - and have not really had any success.


    >So to summarise:


    >1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
    >clock)?
    >2) If so, how - and what are the tradeoffs?


    >Any help appreciated
    >David


  8. Re: Slow convergence of NTP with GPS/PPS

    Richard B. Gilbert wrote:

    >
    > I don't recall that +/- 128ms is specified anywhere. If ntpd gets it's
    > initial time from a hardware reference clock, the time SHOULD be very
    > close. This will, off course, depend on the latencies in the reference
    > clock's response and the resolution of the time supplied.
    >



    This is where it is documented in the source code for 4.2.4p4
    (ntpd/loopfilter.c):

    * State < step > step Comments
    * ================================================== ==
    * NSET FREQ step, FREQ no ntp.drift
    *
    * FSET SYNC step, SYNC ntp.drift
    *

    NSET is the initial state for a cold start. FSET is the initial state
    for a warm start (ntp.drift) present. For a fast start you don't want
    NSET. Note that FSET goes to fully synchronised on one reading, but
    only steps the time if the offset is greater than the step limit, which
    normally 128ms.

    Furthermore, in the branch that is conditioned thus:

    if (fabs(fp_offset) > clock_max && clock_max > 0) {

    there is this comment:

    * In S_FSET state the initial frequency has been set
    * from the frequency file. Since the time is outside
    * the step threshold, the clock is stepped immediately,
    * rather than after the stepout interval. Guys get
    * nervous if it takes 17 minutes to set the clock for
    * the first time.
    *

    immediately followed by:

    step_systime(fp_offset);

    There is no step_systime in the else branch. clock_max is the tinkered
    value of the parameter that defaults to 128ms.

  9. Re: Slow convergence of NTP with GPS/PPS

    David Woolley writes:

    >Richard B. Gilbert wrote:


    >>
    >> If you are using a recent version of ntpd, start it with the "-g"
    >> switch. That will cause it to set the clock to the correct time once
    >> only! If you have a good drift file, you should be synchronized in
    >> thirty seconds or so and be within ten milliseconds, or less, of the
    >> correct time.


    >My understanding was that -g turns off the 1000 second check for the
    >first step, but still leaves the time within +/- 128ms, which will still
    >take an unacceptable time to converge to +/- 5ms. Certainly the 4.2.4p4
    >documentation makes no claims for it beyond once only disabling the 1000
    >second check.


    128ms at 500PPM is 250sec or 4 min. It will take longer than that since the
    rate will not peg out, but it should not be hours.
    Maybe it is best to set the clock initiallly so that it is out by by more
    than 128ms (Eg advance it by 10 sec) and then use -g.



    >>
    >> Try not to reboot unless absolutely necessary. I realize that some
    >> versions of Windows need fairly frequent reboots but there are are


    >I imagine this is some sort of embedded system, which he can't control,
    >but might be switched off outside office hours, in part because that is
    >the socially responsible thing to do.


  10. Re: Slow convergence of NTP with GPS/PPS

    "Richard B. Gilbert" writes:

    >David Woolley wrote:
    >> Richard B. Gilbert wrote:
    >>
    >>>
    >>> If you are using a recent version of ntpd, start it with the "-g"
    >>> switch. That will cause it to set the clock to the correct time once
    >>> only! If you have a good drift file, you should be synchronized in
    >>> thirty seconds or so and be within ten milliseconds, or less, of the
    >>> correct time.

    >>
    >> My understanding was that -g turns off the 1000 second check for the
    >> first step, but still leaves the time within +/- 128ms, which will still
    >> take an unacceptable time to converge to +/- 5ms. Certainly the 4.2.4p4
    >> documentation makes no claims for it beyond once only disabling the 1000
    >> second check.


    >I don't recall that +/- 128ms is specified anywhere. If ntpd gets it's
    >initial time from a hardware reference clock, the time SHOULD be very
    >close. This will, off course, depend on the latencies in the reference
    >clock's response and the resolution of the time supplied.
    >


    ntp steps if the time is out by more than 128ms. If it is out by more than
    1000 seconds it aborts. -g stops that abort once, presumably at intial
    startup. Thus if at initial startup th etime is out by >128ms, it will step
    the time ( to the correct time) and if the drift file is right, will then
    run with that correct drift and the correct time. If it is out by <128ms it
    will adjust the frequency to try to reduce that offset via the feedback
    loop. Since the max rate is 500PPM if it is out by 128ms it will take min 4
    min to adjust, but likely much longer. The max adjust depends on the poll
    interval. Now for the refclocks I know, that is 4 (16s) so the time
    constants in that feedback loop are about 4 min. if I recall correctly.
    (It is such that it is longer than the max time between data which is
    via the filter algorithm is one data point per 8 poll intervals.
    That is the time to reduce the error by about 1/e so it will take about 5
    of those intervals or 20min. (Yes, I know it is not a simple exponential
    falloff).
    This is a design decision. And David will defend this "slow convergence"
    "to the death". chrony is much faster, but does not do refclocks at all so
    that is a useless option here.




  11. Re: Slow convergence of NTP with GPS/PPS

    Unruh wrote:

    >
    > 128ms at 500PPM is 250sec or 4 min. It will take longer than that since the
    > rate will not peg out, but it should not be hours.


    It will follow the normal transient response, which has a first zero
    crossing which I believe is at about 39 minutes for phase (RFC 1305) and
    rather longer for frequency). I'm not sure, but it may well overshoot
    by more than 5ms, in which it could take rather longer to be acceptable
    to the OP.

    It should get nowhere near being slew rate limited, so the 500ppm limit
    is academic.


    > Maybe it is best to set the clock initiallly so that it is out by by more
    > than 128ms (Eg advance it by 10 sec) and then use -g.


    That would be my best trick, but if you have to use -g, you probably
    don't know the time well enough to be sure that adding 10 seconds won't
    actually put it in the 128ms band!

  12. Re: Slow convergence of NTP with GPS/PPS

    David Woolley wrote:

    >
    > It will follow the normal transient response, which has a first zero
    > crossing which I believe is at about 39 minutes for phase (RFC 1305) and
    > rather longer for frequency). I'm not sure, but it may well overshoot


    I think those figures are based on minpoll = 6. If the reference clock
    accepts a shorter minpoll, the times may be correspondingly shorter.

  13. Re: Slow convergence of NTP with GPS/PPS

    Unruh wrote:
    []
    > This is a design decision. And David will defend this "slow
    > convergence" "to the death". chrony is much faster, but does not do
    > refclocks at all so that is a useless option here.


    chrony is also useless on Windows.

    David



  14. Re: Slow convergence of NTP with GPS/PPS

    Thanks for the responses.

    We have tried -g and minpoll/maxpoll are by default 4 for the GPS reference
    clock.
    We even recompiled ntpd with source modified to allow poll at 2sec intervals
    (minpoll=1) but this did not seem to make much difference.

    We have also tried fiddling some of the "tinker" settings (step and stepout)
    but this just seems to lead to instability.

    Also, even if we set the time pretty much perfect (within 5ms offset), ntpd
    appears to first *increase* the offset to well out of our spec, then correct
    through zero offset - overshooting the other way (again well out of our
    spec) and then typically crawls back in after which it is stable - and
    ultimately wonderfully accurate and stable.

    I was hoping that some of the other tinker parameters ("allan" or
    "dispersion" for e.g.) might have an effect - but what are sensible values
    to use?
    I realise that this will compromise ntpd's performance in other ways, but,
    we could tolerate worse final accuracey and jitter in exchange for getting
    to within 5ms "quickly".

    The driftfile also sometimes seems to do more harm than good - especially
    after a reboot.

    > -----Original Message-----
    > From: questions-bounces+davidm=pipstechnology.co.uk@lists.ntp.org
    > [mailto:questions-bounces+davidm=pipstechnology.co.uk@lists.ntp.org]On
    > Behalf Of David McConnell
    > Sent: 30 September 2008 14:04
    > To: questions@lists.ntp.org; linuxpps@ml.enneenne.com
    > Subject: [ntp:questions] Slow convergence of NTP with GPS/PPS
    >
    >
    > Hi
    >
    > We are using Linux ntpd with GPS/PPS reference clock to
    > discipline the time
    > on our systems.
    >
    > Our application requires good time accuracy (better than 5ms)
    > but it also
    > needs to get there quickly (as quickly as possible, but
    > ideally taking no
    > more than about 15 minutes).
    > (The Linux/ntpd is running on a remote embedded device that
    > is frequently
    > restarted - possibly once a day or so - so we cant wait hours for
    > convergence).
    >
    > Currently ntpd can take hours to achieve the desired acuracy.
    >
    > So, the question is simple - is there any way to
    > significantly speedup the
    > convergence of ntpd (using GPS/PPS reference clock)?
    >
    > We would be prepared to compromise somewhat on accuracy and jitter.
    > (Currently accuracy and jitter values are excellent with
    > jitter as low as 1
    > microsecond and accuracy better than 10 uS but it can take a
    > day or two to
    > get there).
    >
    > It does not seem unreasonable to expect that the ntpd could
    > achieve the
    > required accuracy within 15 minutes or so - but nothing we
    > have tried seems
    > to work.
    > Have tried modifying some of the tinker values, but we dont really
    > understand what they all do - and have not really had any success.
    >
    > So to summarise:
    >
    > 1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
    > clock)?
    > 2) If so, how - and what are the tradeoffs?
    >
    > Any help appreciated
    > David
    >
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


  15. Re: Slow convergence of NTP with GPS/PPS

    Would the following work with a reference clock?

    Step 1. Force an initial step adjustment by running ntpd in "one-shot"
    mode with -gq options and "tinker step 0.001" in the config file to
    get below the 128ms step threshold.

    Step 2. Restart ntpd in "normal mode" (without -gq and without "tinker
    step 0.001" in the config file).

  16. Re: Slow convergence of NTP with GPS/PPS

    Unruh wrote:
    > David Woolley writes:
    >> My understanding was that -g turns off the 1000 second check for the
    >> first step, but still leaves the time within +/- 128ms, which will still
    >> take an unacceptable time to converge to +/- 5ms. Certainly the 4.2.4p4
    >> documentation makes no claims for it beyond once only disabling the 1000
    >> second check.

    >
    > 128ms at 500PPM is 250sec or 4 min. It will take longer than that since the
    > rate will not peg out, but it should not be hours.
    > Maybe it is best to set the clock initiallly so that it is out by by more
    > than 128ms (Eg advance it by 10 sec) and then use -g.


    Afair the 128 ms is also a 'tinker' configuration parameter, i.e. it
    should be possible to reduce it to 10 or 15 ms, at the cost of getting a
    few more steps during runtime.

    Terje

    --
    -
    "almost all programming can be viewed as an exercise in caching"

  17. Re: Slow convergence of NTP with GPS/PPS

    Unruh wrote:
    > davidm@pipstechnology.co.uk (David McConnell) writes:
    >
    >> Hi

    >
    >> We are using Linux ntpd with GPS/PPS reference clock to discipline the time
    >> on our systems.

    >
    >> Our application requires good time accuracy (better than 5ms) but it also
    >> needs to get there quickly (as quickly as possible, but ideally taking no
    >> more than about 15 minutes).
    >> (The Linux/ntpd is running on a remote embedded device that is frequently
    >> restarted - possibly once a day or so - so we cant wait hours for
    >> convergence).

    >
    >> Currently ntpd can take hours to achieve the desired acuracy.

    >
    > Are you using the -g option? What is the poll interval for your gps clock?
    > (Use 4 whcih I think is the default for gps clocks.)
    >
    > ntp is NOT designed for rapid convergence, but on a gps clock with poll
    > interval 4 and -g it sure should be better than hours.
    >
    >
    >> So, the question is simple - is there any way to significantly speedup the
    >> convergence of ntpd (using GPS/PPS reference clock)?

    >
    >> We would be prepared to compromise somewhat on accuracy and jitter.
    >> (Currently accuracy and jitter values are excellent with jitter as low as 1
    >> microsecond and accuracy better than 10 uS but it can take a day or two to
    >> get there).

    >
    >> It does not seem unreasonable to expect that the ntpd could achieve the
    >> required accuracy within 15 minutes or so - but nothing we have tried seems
    >> to work.
    >> Have tried modifying some of the tinker values, but we dont really
    >> understand what they all do - and have not really had any success.

    >
    >> So to summarise:

    >
    >> 1) Is it possible to speedup ntpd convergence (using GPS/PPS reference
    >> clock)?
    >> 2) If so, how - and what are the tradeoffs?

    >
    >> Any help appreciated
    >> David


    On a COLD START, I would expect to have to wait for something like
    thirty minutes to get really TIGHT synchronization (5 milliseconds or
    less). Once you have it, you should be able to hold it until you have a
    power failure or a hardware failure.

    If you can't wait for synchronization, get a good UPS, a generator to
    back it up and NEVER shut down or reboot!

  18. Re: Slow convergence of NTP with GPS/PPS

    David Woolley wrote:
    > Richard B. Gilbert wrote:
    >
    >>
    >> I don't recall that +/- 128ms is specified anywhere. If ntpd gets
    >> it's initial time from a hardware reference clock, the time SHOULD be
    >> very close. This will, off course, depend on the latencies in the
    >> reference clock's response and the resolution of the time supplied.
    >>

    >
    >
    > This is where it is documented in the source code for 4.2.4p4
    > (ntpd/loopfilter.c):
    >
    > * State < step > step Comments
    > * ================================================== ==
    > * NSET FREQ step, FREQ no ntp.drift
    > *
    > * FSET SYNC step, SYNC ntp.drift
    > *
    >
    > NSET is the initial state for a cold start. FSET is the initial state
    > for a warm start (ntp.drift) present. For a fast start you don't want
    > NSET. Note that FSET goes to fully synchronised on one reading, but
    > only steps the time if the offset is greater than the step limit, which
    > normally 128ms.
    >
    > Furthermore, in the branch that is conditioned thus:
    >
    > if (fabs(fp_offset) > clock_max && clock_max > 0) {
    >
    > there is this comment:
    >
    > * In S_FSET state the initial frequency has been set
    > * from the frequency file. Since the time is outside
    > * the step threshold, the clock is stepped immediately,
    > * rather than after the stepout interval. Guys get
    > * nervous if it takes 17 minutes to set the clock for
    > * the first time.
    > *
    >
    > immediately followed by:
    >
    > step_systime(fp_offset);
    >
    > There is no step_systime in the else branch. clock_max is the tinkered
    > value of the parameter that defaults to 128ms.


    The above may mean something to YOU! Sorry but I don't see it!



  19. Re: Slow convergence of NTP with GPS/PPS

    David Woolley writes:

    >Unruh wrote:


    >>
    >> 128ms at 500PPM is 250sec or 4 min. It will take longer than that since the
    >> rate will not peg out, but it should not be hours.


    >It will follow the normal transient response, which has a first zero
    >crossing which I believe is at about 39 minutes for phase (RFC 1305) and
    >rather longer for frequency). I'm not sure, but it may well overshoot
    >by more than 5ms, in which it could take rather longer to be acceptable
    >to the OP.


    >It should get nowhere near being slew rate limited, so the 500ppm limit
    >is academic.



    >> Maybe it is best to set the clock initiallly so that it is out by by more
    >> than 128ms (Eg advance it by 10 sec) and then use -g.


    >That would be my best trick, but if you have to use -g, you probably
    >don't know the time well enough to be sure that adding 10 seconds won't
    >actually put it in the 128ms band!


    It could but the chances are small if he has an rtc which is not completely
    broken. If 10 sec is no good, use 10 years. That will make the chance of
    being within 128ms of 10 years vanishngly small.


  20. Re: Slow convergence of NTP with GPS/PPS

    "David J Taylor" writes:

    >Unruh wrote:
    >[]
    >> This is a design decision. And David will defend this "slow
    >> convergence" "to the death". chrony is much faster, but does not do
    >> refclocks at all so that is a useless option here.


    >chrony is also useless on Windows.


    >David


    Agreed. It is AFAIK only useful on Linux.
    It is an example however of a system which has faster response than ntp,
    and has better clock control than ntp, without, afaik sacrificing
    stability or anything else.


+ Reply to Thread
Page 1 of 6 1 2 3 ... LastLast