Slow convergence of NTP with GPS/PPS - NTP

This is a discussion on Slow convergence of NTP with GPS/PPS - NTP ; Terje Mathisen wrote: > 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 ...

+ Reply to Thread
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 108

Thread: Slow convergence of NTP with GPS/PPS

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

    Terje Mathisen wrote:
    > 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.


    Yes it is, and you can tinker it down (but not up) without disabling
    other features (according to the documentation). You would probably
    want to put it out at several standard deviations, to avoid bogus steps.

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

    eugenemil@sbcglobal.net wrote:
    > 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).


    I suspect this would work.

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


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


    How stable is your temperature? Are you rebooting a happy system?
    (If so why?) Or are you powering up a system that has been off
    for the night?

    If your drift file is off, I would expect things like this:
    > 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.


    If your temperature is unstable, I think you are going to have troubles
    getting started cleanly. (Note that CPU activity may influence your
    temperature.)


    Since you seem willing to hack the sources, I would suggest finding
    the code where it does the once-only big step and making that do
    small steps too, even if it wouldn't normally do a step.

    That may not work, but it's what I would try first.


    --
    These are my opinions, not necessarily my employer's. I hate spam.

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

    David,

    Your mission is seriously in jeopardy.

    The NTP discipline loop has hard constraints on maximum sample rate
    (minimum poll interval) and loop dynamics. If you force the sample rate
    greater than one in 8 s, you violate the loop delay requirement and the
    loop WILL become unstable. There is no magic tinker that does what you
    want. The allan intercept tinker depends on the individual oscillator
    characteristics, not what you want it to do. See the briefings on the
    NPT project page.

    You can redesign the loop for faster convergence, but that requires
    changing the seconds timer, which is a major overhaul of the timer
    facility. The loop constants in ntp_loopfilter.c would have to scale in
    the proper mathematical ratio. The equations are in my book. You will
    find the exponential term in the impulse responce equation will be your
    worst enemy.

    Your "pretty much perfect" makes sense only if you have the same initial
    conditions, especially the frequency. If you just change the offset, the
    loop dynamics will induce a transient as you observed. The only true
    test is to let the daemon settle, then stop are restart it. It should be
    well within 5 ms for most modern systems.

    It appears what you need to conform to a specifcation within a given
    offset within a given time. The NTP discipline can do that just fine as
    long as the initial conditions for the feedback loop are precisely
    known. If you change the offset outside the loop, you must recompute the
    frequency. However, when started for the first time or after a long
    period of absence, the loop has to relearn these conditions and that
    takes time. You can reduce this time be redesigning the loop, but then
    the loop becomes increasingly vulnerable to frequency instability.

    From your description I seriously doubt NTP in its present form is
    appropriate for your application.

    Dave

    David McConnell wrote:
    > 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
    >>


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

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

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


    That sounds like your drift rate in /etc/drift is way out, or that you do
    not have such a file.



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


    Yup it could do. This seems to be a problem.


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


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

    Based on the replies, we have (regretfully) decided that ntpd does not suit
    our particular need.

    Instead we have written some software to read GPS sentences + handle PPS
    pulse interrupts and manage the system time ourselves.
    Somewhat crude, but seems to work OK so far....

    Thanks again for all the help.

    David


    > -----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 L. Mills
    > Sent: 02 October 2008 20:12
    > To: questions@lists.ntp.org
    > Subject: Re: [ntp:questions] Slow convergence of NTP with GPS/PPS
    >
    >
    > David,
    >
    > Your mission is seriously in jeopardy.
    >
    > The NTP discipline loop has hard constraints on maximum sample rate
    > (minimum poll interval) and loop dynamics. If you force the
    > sample rate
    > greater than one in 8 s, you violate the loop delay
    > requirement and the
    > loop WILL become unstable. There is no magic tinker that does
    > what you
    > want. The allan intercept tinker depends on the individual oscillator
    > characteristics, not what you want it to do. See the briefings on the
    > NPT project page.
    >
    > You can redesign the loop for faster convergence, but that requires
    > changing the seconds timer, which is a major overhaul of the timer
    > facility. The loop constants in ntp_loopfilter.c would have
    > to scale in
    > the proper mathematical ratio. The equations are in my book. You will
    > find the exponential term in the impulse responce equation
    > will be your
    > worst enemy.
    >
    > Your "pretty much perfect" makes sense only if you have the
    > same initial
    > conditions, especially the frequency. If you just change the
    > offset, the
    > loop dynamics will induce a transient as you observed. The only true
    > test is to let the daemon settle, then stop are restart it.
    > It should be
    > well within 5 ms for most modern systems.
    >
    > It appears what you need to conform to a specifcation within a given
    > offset within a given time. The NTP discipline can do that
    > just fine as
    > long as the initial conditions for the feedback loop are precisely
    > known. If you change the offset outside the loop, you must
    > recompute the
    > frequency. However, when started for the first time or after a long
    > period of absence, the loop has to relearn these conditions and that
    > takes time. You can reduce this time be redesigning the loop,
    > but then
    > the loop becomes increasingly vulnerable to frequency instability.
    >
    > From your description I seriously doubt NTP in its present form is
    > appropriate for your application.
    >
    > Dave
    >
    > David McConnell wrote:
    > > 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
    > >>

    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


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

    Hi,

    just found this thread, after having not studied the list for quite a
    while. I have the exact same problem (have to be ready within minutes)
    and I also have an accurate (and meanwhile excellently working) PPS signal.

    I understand that ntp is not designed for wild and fast changes, but to
    my understanding these are not always necessary, given pretty well
    defined startup-conditions like a reboot. Well, when I reboot my VIA
    epia 12000EG I experience right the phenomenon David described: ntpd
    sets the time pretty fast initially using the -g switch but then
    increases the offset a lot, turns around, shoots over 0 again and after
    a long time finally reaches a very high precision. This happens with and
    without a driftfile.

    My plan was (well, IS - I just ordered it today..) to get a Soekris net
    4501 and maybe even an ovenized oscilator on an external board, since we
    have some tasks that simply depend on very precise time.

    The option to just use an application that simply reads NMEA and PPS is
    of no use for me anymore (I had that plan in the very beginning), since
    we have to sync several devices to the GPS/PPS equipped unit.

    So my question actually is: Is this initial variance part of the plan or
    do I have a chance to get around it with the Soekris board?

    Best regards,
    ../nico berndt

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

    nb@komeda-berlin.de (Nicola Berndt) writes:

    >Hi,


    >just found this thread, after having not studied the list for quite a
    >while. I have the exact same problem (have to be ready within minutes)
    >and I also have an accurate (and meanwhile excellently working) PPS signal.




    >I understand that ntp is not designed for wild and fast changes, but to
    >my understanding these are not always necessary, given pretty well
    >defined startup-conditions like a reboot. Well, when I reboot my VIA
    >epia 12000EG I experience right the phenomenon David described: ntpd
    >sets the time pretty fast initially using the -g switch but then
    >increases the offset a lot, turns around, shoots over 0 again and after
    >a long time finally reaches a very high precision. This happens with and
    >without a driftfile.


    Your frequency is off. But for a PPS signal you should set the poll
    interval to the lowest possible 4.
    The convergence time is related to the poll interval.
    Anyway, what your behaviour indicates is that your system is starting with
    the wrong notion of what the correct frequency is, and is hunting around to
    find it. This is the fault of the ntp memoryless algorithm, since the first
    three readings of the clock should give it a pretty good notion of what the
    clock rate is. But ntp does not use that information in an efficient manner
    at all.



    >My plan was (well, IS - I just ordered it today..) to get a Soekris net
    >4501 and maybe even an ovenized oscilator on an external board, since we
    >have some tasks that simply depend on very precise time.


    ??? This just means that that system is on all the time. Just leave your
    pps attached computer on all the time and it will deliver times with an
    accuracy of a few microseconds. Why you would want to pay for that
    expensive device I do not know, unless you really need sub-microsecond
    resolution. But then any of the clients will not get that anyway. Network
    delays give you 10's of usec fluctuations.


    >The option to just use an application that simply reads NMEA and PPS is
    >of no use for me anymore (I had that plan in the very beginning), since
    >we have to sync several devices to the GPS/PPS equipped unit.


    Why not? Just sync several devices to that GPS/PPS equipped unit. Go ahead.


    >So my question actually is: Is this initial variance part of the plan or
    >do I have a chance to get around it with the Soekris board?


    That board will do you absolutely no good at all if you then use it as the
    time source for your server, unless you need ns long term resolution. NTP's
    design, which David Mills strenuously sticks to, has the design feature
    that it is slow to converge. It is not necessary, but it was his design
    decision. Chrony made a different design decision and converges far far
    faster. Unfortunately, it works only on Linux and does not have any ability
    to read atomic clocks (like PPS). But it is certainly proof of concept that
    fast convergence is possible while disciplining the computer clock to a
    higher degree of accuracy than does ntp.






    >Best regards,
    >./nico berndt


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

    Unruh schrieb:
    >> I understand that ntp is not designed for wild and fast changes, but to
    >> my understanding these are not always necessary, given pretty well
    >> defined startup-conditions like a reboot. Well, when I reboot my VIA
    >> epia 12000EG I experience right the phenomenon David described: ntpd
    >> sets the time pretty fast initially using the -g switch but then
    >> increases the offset a lot, turns around, shoots over 0 again and after
    >> a long time finally reaches a very high precision. This happens with and
    >> without a driftfile.
    >>

    >
    > Your frequency is off. But for a PPS signal you should set the poll
    > interval to the lowest possible 4.
    > The convergence time is related to the poll interval.
    > Anyway, what your behaviour indicates is that your system is starting with
    > the wrong notion of what the correct frequency is, and is hunting around to
    > find it. This is the fault of the ntp memoryless algorithm, since the first
    > three readings of the clock should give it a pretty good notion of what the
    > clock rate is. But ntp does not use that information in an efficient manner
    > at all.
    >
    >

    I see, that's too bad then.. I am already using minpoll 4 maxpoll 4
    >
    >> My plan was (well, IS - I just ordered it today..) to get a Soekris net
    >> 4501 and maybe even an ovenized oscilator on an external board, since we
    >> have some tasks that simply depend on very precise time.
    >>

    >
    > ??? This just means that that system is on all the time. Just leave your
    > pps attached computer on all the time and it will deliver times with an
    > accuracy of a few microseconds. Why you would want to pay for that
    > expensive device I do not know, unless you really need sub-microsecond
    > resolution. But then any of the clients will not get that anyway. Network
    > delays give you 10's of usec fluctuations.
    >
    >
    >

    No, the Soekris will run linux an d ntpd and the oscillator will just be
    on an external little board. The computer is residing in an airport
    hangar for MONTH sometimes with no powersource at all! There is
    absolutely no way to leavi it on, especially since it is a part of the
    airplane, wich has to be cut of even it's battery when unattended for a
    longer period.
    >> The option to just use an application that simply reads NMEA and PPS is
    >> of no use for me anymore (I had that plan in the very beginning), since
    >> we have to sync several devices to the GPS/PPS equipped unit.
    >>

    >
    > Why not? Just sync several devices to that GPS/PPS equipped unit. Go ahead.
    >
    >
    >

    Yes, one could do that, right. I must think about it. It takes away
    quite some freedom, though, meaning a bunch more cables that have to be
    attached to every unit OR writing something like gps that can sync to
    another computer. I am no programmer so I guess I will try hard not to
    do that.
    >> So my question actually is: Is this initial variance part of the plan or
    >> do I have a chance to get around it with the Soekris board?
    >>

    >
    > That board will do you absolutely no good at all if you then use it as the
    > time source for your server, unless you need ns long term resolution. NTP's
    > design, which David Mills strenuously sticks to, has the design feature
    > that it is slow to converge. It is not necessary, but it was his design
    > decision. Chrony made a different design decision and converges far far
    > faster. Unfortunately, it works only on Linux and does not have any ability
    > to read atomic clocks (like PPS). But it is certainly proof of concept that
    > fast convergence is possible while disciplining the computer clock to a
    > higher degree of accuracy than does ntp.
    >
    >
    >

    Well, all in all rather bad news for me. I must sit down and think of a
    good way out...

    Thx for the hints and regards,
    .../nico

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

    nb@komeda-berlin.de (Nicola Berndt) writes:

    >Unruh schrieb:
    >>> I understand that ntp is not designed for wild and fast changes, but to
    >>> my understanding these are not always necessary, given pretty well
    >>> defined startup-conditions like a reboot. Well, when I reboot my VIA
    >>> epia 12000EG I experience right the phenomenon David described: ntpd
    >>> sets the time pretty fast initially using the -g switch but then
    >>> increases the offset a lot, turns around, shoots over 0 again and after
    >>> a long time finally reaches a very high precision. This happens with and
    >>> without a driftfile.
    >>>

    >>
    >> Your frequency is off. But for a PPS signal you should set the poll
    >> interval to the lowest possible 4.
    >> The convergence time is related to the poll interval.
    >> Anyway, what your behaviour indicates is that your system is starting with
    >> the wrong notion of what the correct frequency is, and is hunting around to
    >> find it. This is the fault of the ntp memoryless algorithm, since the first
    >> three readings of the clock should give it a pretty good notion of what the
    >> clock rate is. But ntp does not use that information in an efficient manner
    >> at all.
    >>
    >>

    >I see, that's too bad then.. I am already using minpoll 4 maxpoll 4


    OK, But that should have a convergence of minutes not hours. Mind you NTPs
    habit of throwing away 7 out of 8 queries of the clock does not help.
    (clock filter). Especially for a pps that is pretty extreme.

    >>
    >>> My plan was (well, IS - I just ordered it today..) to get a Soekris net
    >>> 4501 and maybe even an ovenized oscilator on an external board, since we
    >>> have some tasks that simply depend on very precise time.
    >>>

    >>
    >> ??? This just means that that system is on all the time. Just leave your
    >> pps attached computer on all the time and it will deliver times with an
    >> accuracy of a few microseconds. Why you would want to pay for that
    >> expensive device I do not know, unless you really need sub-microsecond
    >> resolution. But then any of the clients will not get that anyway. Network
    >> delays give you 10's of usec fluctuations.
    >>
    >>
    >>

    >No, the Soekris will run linux an d ntpd and the oscillator will just be
    >on an external little board. The computer is residing in an airport
    >hangar for MONTH sometimes with no powersource at all! There is


    Hard for it to be on all the time then. Or for it to have anthing like an
    accurate time. And that ovenized oscillator will also be pretty useless (
    much worse than the GPS) since it will have no power either and the crystal
    will not be oscillating nor the oven keeping the temp constant.


    >absolutely no way to leavi it on, especially since it is a part of the
    >airplane, wich has to be cut of even it's battery when unattended for a
    >longer period.
    >>> The option to just use an application that simply reads NMEA and PPS is
    >>> of no use for me anymore (I had that plan in the very beginning), since
    >>> we have to sync several devices to the GPS/PPS equipped unit.
    >>>

    >>
    >> Why not? Just sync several devices to that GPS/PPS equipped unit. Go ahead.
    >>
    >>
    >>

    >Yes, one could do that, right. I must think about it. It takes away
    >quite some freedom, though, meaning a bunch more cables that have to be
    >attached to every unit OR writing something like gps that can sync to
    >another computer. I am no programmer so I guess I will try hard not to
    >do that.



    >>> So my question actually is: Is this initial variance part of the plan or
    >>> do I have a chance to get around it with the Soekris board?
    >>>

    >>
    >> That board will do you absolutely no good at all if you then use it as the
    >> time source for your server, unless you need ns long term resolution. NTP's
    >> design, which David Mills strenuously sticks to, has the design feature
    >> that it is slow to converge. It is not necessary, but it was his design
    >> decision. Chrony made a different design decision and converges far far
    >> faster. Unfortunately, it works only on Linux and does not have any ability
    >> to read atomic clocks (like PPS). But it is certainly proof of concept that
    >> fast convergence is possible while disciplining the computer clock to a
    >> higher degree of accuracy than does ntp.
    >>
    >>
    >>

    >Well, all in all rather bad news for me. I must sit down and think of a
    >good way out...


    So, what you have is a free standing computer which must come out of a cold
    shutdown (ie the oscillator frequency on startup will be way off its
    frequency in steady state because it is cold) so will be far from
    equilibrium. What is your time error requirement? Seconds, milliseconds,
    microseconds? In such a situation ntp would probably give you a few
    milliseconds. But it certainly is NOT designed to give you good accuracy in
    such a situation during startup. What are you finding?







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

    Unruh schrieb:

    >>>
    >>>

    >> I see, that's too bad then.. I am already using minpoll 4 maxpoll 4

    >
    > OK, But that should have a convergence of minutes not hours. Mind you NTPs
    > habit of throwing away 7 out of 8 queries of the clock does not help.
    > (clock filter). Especially for a pps that is pretty extreme.


    Today I moved the computer to a different location to work there and I
    found it to set its clock right after start and keep it within ms-range!
    I didn't change anything, just shut down, drove there and turned it on,
    so I am really confused about that. Both locations are normal rooms with
    normal room-temerature. Well, I duplicated the system (that was why I
    was there..) and came back home with mine and tomorrow I will see if it
    behaves different again. Very very weird! It looks as if all of a sudden
    the driftfile was used and before not! This is also very strange, since
    the driftfile was (re)written yesterday, so ntp knew about it yesterday.
    My ntp.conf also includes the driftfile location.

    >> No, the Soekris will run linux an d ntpd and the oscillator will just be
    >> on an external little board. The computer is residing in an airport
    >> hangar for MONTH sometimes with no powersource at all! There is

    >
    > Hard for it to be on all the time then. Or for it to have anthing like an
    > accurate time. And that ovenized oscillator will also be pretty useless (
    > much worse than the GPS) since it will have no power either and the crystal
    > will not be oscillating nor the oven keeping the temp constant.


    Oh, so I got the word ovenized wrong: I understood it to be very immune
    against varying temperature. Ok, so if it needs an heater and all, it's
    useless in my case.

    >
    > So, what you have is a free standing computer which must come out of a cold
    > shutdown (ie the oscillator frequency on startup will be way off its
    > frequency in steady state because it is cold) so will be far from
    > equilibrium. What is your time error requirement? Seconds, milliseconds,
    > microseconds? In such a situation ntp would probably give you a few
    > milliseconds. But it certainly is NOT designed to give you good accuracy in
    > such a situation during startup. What are you finding?


    Well, one thing I can of course always do is to boot hte machine, let it
    run for a flittle while and reboot it, so it boots with a warmed up
    oscillator. This would give trouble with the driftfile, though..

    We target for millisecond accuracy. As I understand, the oscillators on
    standard PCs are mostly cheapest crap and there are way better
    oscillators I could use to replace the original. Is that correct?

    What I saw today was pretty much, what I was looking for: No running
    away and stable within minutes. We also took a fan and heated up the
    oscillator. We could watch a slow drift with ntpq -p, but nothing too
    bad. It went away for a few ms and came back within minutes again.

    I'll look into that tomorrow..

    Regards,
    .../nico

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

    nb@komeda-berlin.de (Nicola Berndt) writes:

    >Unruh schrieb:


    >>>>
    >>>>
    >>> I see, that's too bad then.. I am already using minpoll 4 maxpoll 4

    >>
    >> OK, But that should have a convergence of minutes not hours. Mind you NTPs
    >> habit of throwing away 7 out of 8 queries of the clock does not help.
    >> (clock filter). Especially for a pps that is pretty extreme.


    >Today I moved the computer to a different location to work there and I
    >found it to set its clock right after start and keep it within ms-range!
    >I didn't change anything, just shut down, drove there and turned it on,
    >so I am really confused about that. Both locations are normal rooms with
    >normal room-temerature. Well, I duplicated the system (that was why I
    >was there..) and came back home with mine and tomorrow I will see if it
    >behaves different again. Very very weird! It looks as if all of a sudden
    >the driftfile was used and before not! This is also very strange, since
    >the driftfile was (re)written yesterday, so ntp knew about it yesterday.
    >My ntp.conf also includes the driftfile location.


    Sounds like the drift file was closer to being accurate.


    >>> No, the Soekris will run linux an d ntpd and the oscillator will just be
    >>> on an external little board. The computer is residing in an airport
    >>> hangar for MONTH sometimes with no powersource at all! There is

    >>
    >> Hard for it to be on all the time then. Or for it to have anthing like an
    >> accurate time. And that ovenized oscillator will also be pretty useless (
    >> much worse than the GPS) since it will have no power either and the crystal
    >> will not be oscillating nor the oven keeping the temp constant.


    >Oh, so I got the word ovenized wrong: I understood it to be very immune
    >against varying temperature. Ok, so if it needs an heater and all, it's
    >useless in my case.


    >>
    >> So, what you have is a free standing computer which must come out of a cold
    >> shutdown (ie the oscillator frequency on startup will be way off its
    >> frequency in steady state because it is cold) so will be far from
    >> equilibrium. What is your time error requirement? Seconds, milliseconds,
    >> microseconds? In such a situation ntp would probably give you a few
    >> milliseconds. But it certainly is NOT designed to give you good accuracy in
    >> such a situation during startup. What are you finding?


    >Well, one thing I can of course always do is to boot hte machine, let it
    >run for a flittle while and reboot it, so it boots with a warmed up
    >oscillator. This would give trouble with the driftfile, though..


    >We target for millisecond accuracy. As I understand, the oscillators on
    >standard PCs are mostly cheapest crap and there are way better
    >oscillators I could use to replace the original. Is that correct?


    But those cheap oscillators are actually pretty good. They have drifts of
    the order of 10s of PPM (or paerhps up to 100PPM) and those are temp
    sensitive. That is their main problem AFAIK. The temp sensitivity is
    usually less than 1PPM/degree C.
    The "way better oscillators" I think is primarily oscillators which are
    temp controlled (yes heaters) and selected/adjusted.


    >What I saw today was pretty much, what I was looking for: No running
    >away and stable within minutes. We also took a fan and heated up the
    >oscillator. We could watch a slow drift with ntpq -p, but nothing too
    >bad. It went away for a few ms and came back within minutes again.


    >I'll look into that tomorrow..


    >Regards,
    >../nico


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


    >We target for millisecond accuracy. As I understand, the oscillators on
    >standard PCs are mostly cheapest crap and there are way better
    >oscillators I could use to replace the original. Is that correct?


    There are two parts to that "crap".

    One is that the actual frequency doesn't match the number printed
    on the can. That's not a problem because the drift file corrects
    for that type of error.

    The other is that it may be highly temperature sensitive while
    a more expensive crystal may be less so. You can probably measure
    that be heating up the box, perhaps by just running soem compute
    intensive task rather than letting it sit mostly idle.

    The suggestion for an external ovenized (OCXO) crystal/oscillator
    was a way to avoid the temperature shifts. The basic idea
    is that you run the crystal in an oven and have a mechanism to
    keep it at a constant temperature. (Warmer than normal is
    easier to implement than keeping it at room temperature. All
    you need is a heater, no refrigerator.)

    --
    These are my opinions, not necessarily my employer's. I hate spam.


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

    Unruh wrote:

    > The "way better oscillators" I think is primarily oscillators which are
    > temp controlled (yes heaters) and selected/adjusted.
    >

    Nowadays they are as likely to be TCXO's, temperature compensated
    crystal oscillators, in which the temperature is measured and used to
    drive a varicap diode, across the crystal, to compensate. I think
    portable GPS receivers tend to use that approach.

    In principle, you can also apply that compensation in software; you just
    need access to a thermistor that is thermally bonded to the crystal.

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

    On Wed, 1 Oct 2008 10:24:22 GMT, David McConnell wrote:
    >
    > The driftfile also sometimes seems to do more harm than good - especially
    > after a reboot.

    Some kernels do a calibration of clock against RTC clock. This will make
    driftfile misleading.
    /hjj

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


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

    >Some kernels do a calibration of clock against RTC clock. This will make
    >driftfile misleading.


    There is a bug in the Linux calibration routine for the TSC mode
    clock. It doesn't get a consistent answer. I hacked the code
    to loop and print the answer. It was a splatter. None were far
    off unless you are a time keeping geek. It's easy to see the
    different drift results and startup transients are "interesting".

    clocksource=acpi_pm on the boot command line might help.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


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

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


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

    >>Some kernels do a calibration of clock against RTC clock. This will make
    >>driftfile misleading.


    >There is a bug in the Linux calibration routine for the TSC mode
    >clock. It doesn't get a consistent answer. I hacked the code
    >to loop and print the answer. It was a splatter. None were far
    >off unless you are a time keeping geek. It's easy to see the
    >different drift results and startup transients are "interesting".


    >clocksource=acpi_pm on the boot command line might help.


    The recent kernels, especially if you have HPET enabled-- not used, just
    enabled, are a complete disaster as far as the rtc is concerned. They poll
    the rtc with something like a 16ms poll interval, since the second
    transition interrupt is then grabbed by the HPET bios routing and not
    delivered anywhere. This does not affect the system clock, but does affect
    the rtc reading and setting. In fact at present, the rtc on a linux system
    is essentially useless for any kind of time keeping or time setting.


    >--
    >These are my opinions, not necessarily my employer's. I hate spam.



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



    >A termistor on the crystal on the other hand might be useful to compensate
    >the temperature ( there is an alteration of ntp which also calculates the
    >temp compensation of the crystal and uses that to calculate the required
    >drift rate.-- unfortunately I do not remember its name of location on the
    >web)


    NTP temperature compensation
    Mark Martinec, 2001-01-08
    http://www.ijs.si/time/temp-compensation/

    A wonderful read.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


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

    Richard B. Gilbert wrote:

    > The clock in a PC is basically the guts of a cheap "Quartz" watch. It
    > wouldn't surprise me if the manufacturers bought the crystals rejected
    > by the watch makers. I suspect that the clock exists MOSTLY so the
    > machine will have the correct date for things like letters and checks.


    That describes the RTC, and may not even be valid for HPET systems. The
    clock that ntpd disciplines is not based on a 32kHz watch crystal, but
    on a much higher frequency crystal. Historically, the primary purpose
    of the latter crystal is to provide a logic clock for the processor and
    memory, not for time keeping.

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

    Richard B. Gilbert wrote:
    > I don't recall the model of the Meinberg board but I'm sure that their
    > representative, who hangs out here, can supply it.


    There are in fact several models, for PCI or PCI Express bus, and for
    different time sources. See "Slot cards":
    http://www.meinberg.de/english/produ....htm#slot_card

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

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