Slow convergence of NTP with GPS/PPS - NTP

This is a discussion on Slow convergence of NTP with GPS/PPS - NTP ; Unruh schrieb: > nb@komeda-berlin.de (Nicola Berndt) writes: > >> Richard B. Gilbert schrieb: >>> David Woolley wrote: >>>> Richard B. Gilbert wrote: >>>> >>>>> To turn your equipment on after months of downtime and expect it to >>>>> lock on ...

+ Reply to Thread
Page 5 of 6 FirstFirst ... 3 4 5 6 LastLast
Results 81 to 100 of 108

Thread: Slow convergence of NTP with GPS/PPS

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

    Unruh schrieb:
    > nb@komeda-berlin.de (Nicola Berndt) writes:
    >
    >> Richard B. Gilbert schrieb:
    >>> David Woolley wrote:
    >>>> Richard B. Gilbert wrote:
    >>>>
    >>>>> To turn your equipment on after months of downtime and expect it to
    >>>>> lock on to the correct time with millisecond accuracy within seconds
    >>>>> is asking for a hell of a lot.
    >>>> Not really. He's starting a GPS receiver at the same time and that has
    >>>> to lock to 50ns.
    >>>>
    >>>> Doing it on a general purpose computer is more difficult, but not
    >>>> particularly impossible.
    >>> Even with GPS and a full four satellite fix, ten seconds to synchronize
    >>> is extremely ambitious!! You can set the time to within whatever
    >>> precision the hardware and software support but that is only half the
    >>> problem. You also need to set the correct clock frequency. On a cold
    >>> start, the clock frequency is a moving target as the hardware warms up.
    >>>
    >>> I would expect to wait at least thirty minutes for the system to
    >>> stabilize with both the correct phase (time) and frequency.

    >
    >> To transfer the full almanac of GPS it takes roughly 12 minutes from a
    >> cold start. Then the receiver knows everything there is for it to know.
    >> Some receivers (like mine) you can tell it's location, wich gets you in
    >> the 10 s range for precise time. Then again, who claimed, it has to be
    >> 10 s? I would be very happy with these 12 mins..

    >
    > For some receivers if they know their position, they can get the time
    > virutally instantly from "cold start". All you need is one sattelite. If the receiver has no idea where it is, it can take much longer.
    > Whether or not the receiver the OP has has that
    > capability I do not know.
    >
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions



    Hi,

    U-Blox state on page 24 of this -
    http://www.u-blox.com/customersuppor...S-X-02007).pdf
    - document a rate of 50 bits/second sent out by the satellites and a
    time of 12.5 mins to transmit the full almanach. I don't know, if really
    the entire almanac is needed for precise time, but I'd actually suspect
    that.

    Regards,
    .../nico

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

    Nicola Berndt wrote:

    > time of 12.5 mins to transmit the full almanach. I don't know, if really
    > the entire almanac is needed for precise time, but I'd actually suspect
    > that.


    I don't think the almanac is strictly necessary. What you need is the
    detailed ephemeris for each satellite you are using. That takes 30
    seconds to transmit.

    My old GPS receiver takes a long time to acquire from cold because it
    can only read data from one satellite (one spreading code) at a time.
    It starts at satellite 1 and tries each one for some time (I suspect it
    is trying different frequency offsets and different phases) until it
    finds one. It might speed up a bit then, as it will have an approximate
    frequency, but it still continues stepping one at a time until it has
    enough for a 2D fix. At that point, I think it does use the almanac,
    although it may use an old one, to decide which other satellites should
    be in view.

    A modern, high performance, device, may be able to decode data for the
    whole constellation at once, and therefore cold start much faster.

    If you know your position, you can get a time lock within 30 seconds of
    finding the first satellite.

    According to the June 1995 GPS SPS Signal Specification document, the
    almanac repeats every 24 "pages". So it will take 12 minutes to
    transmit. I presume the extra half minute is to find the start of a
    page. 15 of the 45 seconds quoted for cold starts one one receiver may
    well be to find a safe starting point for decoding.

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

    David J Taylor wrote:
    >
    > "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)."
    >
    > I would have thought that a GPS and NTP would have been able to achieve
    > that, at least with a current drift file.


    Assuming default parameters and worst case initial error, and no PPS, it
    will start with an error of 128ms and take about 40 minutes before it
    crosses zero. It will then overshoot, so, might take several cycles to
    settle within 5ms. Using minpoll 4 may get it to cross zero within the
    15 minutes, but the overshoot may still violate the criteria.

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

    Nicola Berndt wrote:

    >
    > To transfer the full almanac of GPS it takes roughly 12 minutes from a
    > cold start. Then the receiver knows everything there is for it to know.


    It needs more like 6 hours for that, as it can only get the detailed
    ephemeris when a satellite is above the horizon. Of course, it doesn't
    really need to know the details of satellites until they actually come
    into view.

    > Some receivers (like mine) you can tell it's location, wich gets you in
    > the 10 s range for precise time. Then again, who claimed, it has to be
    > 10 s? I would be very happy with these 12 mins..


    You will need at least 30 seconds for full accuracy, for a warm start,
    but I can imagine that you could be well within 10 microseconds in 10
    seconds, if your almanac wasn't too out of date.

    (Incidentally, it is possible to preload the current almanac data.)

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

    Hal Murray wrote:
    > My DSL line has 100 ms of queueing delays.


    That "feels" about right if one assumes the goal is to enable
    link-rate on a transcontinental (US at least) path.

    rick jones
    http://www.netperf.org/
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

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

    Unruh wrote:
    > nb@komeda-berlin.de (Nicola Berndt) writes:
    >
    >> Richard B. Gilbert schrieb:
    >>> David Woolley wrote:
    >>>> Richard B. Gilbert wrote:
    >>>>
    >>>>> To turn your equipment on after months of downtime and expect it to
    >>>>> lock on to the correct time with millisecond accuracy within seconds
    >>>>> is asking for a hell of a lot.
    >>>> Not really. He's starting a GPS receiver at the same time and that has
    >>>> to lock to 50ns.
    >>>>
    >>>> Doing it on a general purpose computer is more difficult, but not
    >>>> particularly impossible.
    >>> Even with GPS and a full four satellite fix, ten seconds to synchronize
    >>> is extremely ambitious!! You can set the time to within whatever
    >>> precision the hardware and software support but that is only half the
    >>> problem. You also need to set the correct clock frequency. On a cold
    >>> start, the clock frequency is a moving target as the hardware warms up.
    >>>
    >>> I would expect to wait at least thirty minutes for the system to
    >>> stabilize with both the correct phase (time) and frequency.

    >
    >> To transfer the full almanac of GPS it takes roughly 12 minutes from a
    >> cold start. Then the receiver knows everything there is for it to know.
    >> Some receivers (like mine) you can tell it's location, wich gets you in
    >> the 10 s range for precise time. Then again, who claimed, it has to be
    >> 10 s? I would be very happy with these 12 mins..

    >
    > For some receivers if they know their position, they can get the time
    > virutally instantly from "cold start". All you need is one sattelite. If the receiver has no idea where it is, it can take much longer.
    > Whether or not the receiver the OP has has that
    > capability I do not know.
    >
    >


    There is a subtle difference between *getting* the correct time and
    *keeping* the correct time! A GPS receiver can generate a Pulse Per
    Second (PPS) signal accurate to within about 50 nanoseconds. This does
    not mean that you can get the same accuracy out of your computer!


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

    Hal Murray wrote:
    >> It's the poll interval of ntpd. Ntpq does not poll! The poll interval
    >> varies between 2^MINPOLL and 2^MAXPOLL. You have set MINPOLL=MAXPOLL=4
    >> giving a poll interval of 2^4 or 16 seconds. This is usually the
    >> correct choice for a GPS receiver.

    >
    > Why do you say that?


    Because the GPS time signal is extremely accurate!

    > Or let me ask it another way, how would you
    > decide what the right polling interval is?
    >


    NTPD uses much longer poll intervals over the internet or even over a
    local network because of the variable delays introduced by the network.
    No two packets are guaranteed the same path between two points unless
    there IS only one path. In addition to the variations in travel time
    due to differing paths, there are also variable queuing delays!

    Ntpd does not know how long any particular packet was delayed, it only
    knows what the typical delay is. The longer polling intervals smooth
    out the errors caused by variable delays.

    See Dave's book for a rigorous mathematical explanation. Or, if your
    math is as poor as mine, you'll just have to take Dave's word for it.

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

    "Richard B. Gilbert" writes:

    >Unruh wrote:
    >> nb@komeda-berlin.de (Nicola Berndt) writes:
    >>
    >>> Richard B. Gilbert schrieb:
    >>>> David Woolley wrote:
    >>>>> Richard B. Gilbert wrote:
    >>>>>
    >>>>>> To turn your equipment on after months of downtime and expect it to
    >>>>>> lock on to the correct time with millisecond accuracy within seconds
    >>>>>> is asking for a hell of a lot.
    >>>>> Not really. He's starting a GPS receiver at the same time and that has
    >>>>> to lock to 50ns.
    >>>>>
    >>>>> Doing it on a general purpose computer is more difficult, but not
    >>>>> particularly impossible.
    >>>> Even with GPS and a full four satellite fix, ten seconds to synchronize
    >>>> is extremely ambitious!! You can set the time to within whatever
    >>>> precision the hardware and software support but that is only half the
    >>>> problem. You also need to set the correct clock frequency. On a cold
    >>>> start, the clock frequency is a moving target as the hardware warms up.
    >>>>
    >>>> I would expect to wait at least thirty minutes for the system to
    >>>> stabilize with both the correct phase (time) and frequency.

    >>
    >>> To transfer the full almanac of GPS it takes roughly 12 minutes from a
    >>> cold start. Then the receiver knows everything there is for it to know.
    >>> Some receivers (like mine) you can tell it's location, wich gets you in
    >>> the 10 s range for precise time. Then again, who claimed, it has to be
    >>> 10 s? I would be very happy with these 12 mins..

    >>
    >> For some receivers if they know their position, they can get the time
    >> virutally instantly from "cold start". All you need is one sattelite. If the receiver has no idea where it is, it can take much longer.
    >> Whether or not the receiver the OP has has that
    >> capability I do not know.
    >>
    >>


    >There is a subtle difference between *getting* the correct time and
    >*keeping* the correct time! A GPS receiver can generate a Pulse Per
    >Second (PPS) signal accurate to within about 50 nanoseconds. This does
    >not mean that you can get the same accuracy out of your computer!


    Of course not ( and the GPS18 only gives 1us accuracy anyway) but the OP
    wanted accuracy to 1ms, which is trivial for both the computer and the gps.


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

    David Woolley wrote:
    > David J Taylor wrote:
    >>
    >> "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)."
    >>
    >> I would have thought that a GPS and NTP would have been able to
    >> achieve that, at least with a current drift file.

    >
    > Assuming default parameters and worst case initial error, and no PPS,
    > it will start with an error of 128ms and take about 40 minutes before
    > it crosses zero. It will then overshoot, so, might take several
    > cycles to settle within 5ms. Using minpoll 4 may get it to cross
    > zero within the 15 minutes, but the overshoot may still violate the
    > criteria.


    OK, David, so having a GPS/PPS source and distributing that to the clients
    should be far better? How much better?

    Isn't the 128ms a worst-case estimate, because NTP would set the time by
    stepping initially if the appropriate parameter is specified? Wouldn't
    the initial offset then be near zero?

    Thanks,
    David



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

    "Richard B. Gilbert" writes:

    >Hal Murray wrote:
    >>> It's the poll interval of ntpd. Ntpq does not poll! The poll interval
    >>> varies between 2^MINPOLL and 2^MAXPOLL. You have set MINPOLL=MAXPOLL=4
    >>> giving a poll interval of 2^4 or 16 seconds. This is usually the
    >>> correct choice for a GPS receiver.

    >>
    >> Why do you say that?


    >Because the GPS time signal is extremely accurate!


    >> Or let me ask it another way, how would you
    >> decide what the right polling interval is?
    >>


    >NTPD uses much longer poll intervals over the internet or even over a
    >local network because of the variable delays introduced by the network.
    > No two packets are guaranteed the same path between two points unless
    >there IS only one path. In addition to the variations in travel time
    >due to differing paths, there are also variable queuing delays!


    No. The longer poll intervals are mainly about keeping packets off the servers. In
    principle it is always better to poll more. (in practice with the ntp
    model, this is only partially true-- you want the 8 times the poll interval
    to be close tothe Allan minimum if the noise model really is exponential
    phase and 1/f drift noise. ( on most modern networks not the greatest
    assumption-- day to night temp variations are probably more important for
    the frequency noise).

    >Ntpd does not know how long any particular packet was delayed, it only
    >knows what the typical delay is. The longer polling intervals smooth
    >out the errors caused by variable delays.


    No, it knows exactly now long the delay is. It just does not know if that
    delay occured outbound, inbound or both. (I think you are thinking about
    the broadcast model)



    >See Dave's book for a rigorous mathematical explanation. Or, if your
    >math is as poor as mine, you'll just have to take Dave's word for it.




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

    Unruh wrote:
    []
    > Of course not ( and the GPS18 only gives 1us accuracy anyway) but the
    > OP wanted accuracy to 1ms, which is trivial for both the computer and
    > the gps.


    The OP wanted 5ms.

    David



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

    David J Taylor wrote:

    > Isn't the 128ms a worst-case estimate, because NTP would set the time by
    > stepping initially if the appropriate parameter is specified? Wouldn't
    > the initial offset then be near zero?


    I meant the largest representable value less than 128ms, which for the
    purposes of looking at startup transients can be approximated to 128ms.




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

    Unruh wrote:

    >
    > Of course not ( and the GPS18 only gives 1us accuracy anyway) but the OP
    > wanted accuracy to 1ms, which is trivial for both the computer and the gps.
    >

    I think there have been reports that the 1 microsecond is actually a
    conservative figure.

    Also, especially for a relatively basic device, like that, I doubt that
    it will indicate the time to be valid before it has accurate ephemeris
    data (and, in that case, a 2D position).

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

    David Woolley wrote:
    > David J Taylor wrote:
    >
    >> Isn't the 128ms a worst-case estimate, because NTP would set the
    >> time by stepping initially if the appropriate parameter is
    >> specified? Wouldn't the initial offset then be near zero?

    >
    > I meant the largest representable value less than 128ms, which for the
    > purposes of looking at startup transients can be approximated to
    > 128ms.


    OK, but isn't it likely that the initial setting is much closer than
    128ms, after the first step has been made?

    David



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

    David J Taylor wrote:

    > OK, but isn't it likely that the initial setting is much closer than
    > 128ms, after the first step has been made?


    There won't be a first step if the time is within 128ms. The example I
    was giving was the worst case initial error, which is just less than 128ms.

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

    "Unruh" wrote in message
    news:UJyMk.3986$fF3.1213@edtnps83...

    > [...] The longer poll intervals are mainly about keeping packets off
    > the servers. In principle it is always better to poll more. ...


    Yes, but. One of the given reasons for polling less often is to let
    the host clock accrue more error so that it becomes better measureable
    amid other error sources, for example jitter from random network delays.

    But you can poll every second and still correct very small frequency
    errors, if only you don't _forget_ polls from very long ago. Keeping
    a simple FIFO queue of poll results is too simple.

    Groetjes,
    Maarten Wiltink



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

    "David J Taylor" writes:

    >David Woolley wrote:
    >> David J Taylor wrote:
    >>>
    >>> "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)."
    >>>
    >>> I would have thought that a GPS and NTP would have been able to
    >>> achieve that, at least with a current drift file.

    >>
    >> Assuming default parameters and worst case initial error, and no PPS,
    >> it will start with an error of 128ms and take about 40 minutes before
    >> it crosses zero. It will then overshoot, so, might take several
    >> cycles to settle within 5ms. Using minpoll 4 may get it to cross
    >> zero within the 15 minutes, but the overshoot may still violate the
    >> criteria.


    >OK, David, so having a GPS/PPS source and distributing that to the clients
    >should be far better? How much better?


    That is his minpoll 4 case. refclocks are almost always run at minpoll 4.
    They could be run at minpoll 2 but ntp will not allow it.


    >Isn't the 128ms a worst-case estimate, because NTP would set the time by
    >stepping initially if the appropriate parameter is specified? Wouldn't
    >the initial offset then be near zero?


    That was what he said "worst case initial error" He should have said
    127.999msec though I think:-)

    Actually it is NOT the worst case scenario. Try a drift which is seriously
    off instead. That takes much longer to settle down. First ntp has to notice
    that the drift is off, and then has to start correcting it. Thus a drift of
    say 200PPM (500 would be a worst case, but ntp cannot correct a 500PPM
    drift so there is no point in going there) will take quite a bit longer to
    correct (should take about twice as long to first go through zero).



    >Thanks,
    >David




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

    "Maarten Wiltink" writes:

    >"Unruh" wrote in message
    >news:UJyMk.3986$fF3.1213@edtnps83...


    >> [...] The longer poll intervals are mainly about keeping packets off
    >> the servers. In principle it is always better to poll more. ...


    >Yes, but. One of the given reasons for polling less often is to let
    >the host clock accrue more error so that it becomes better measureable
    >amid other error sources, for example jitter from random network delays.


    >But you can poll every second and still correct very small frequency
    >errors, if only you don't _forget_ polls from very long ago. Keeping
    >a simple FIFO queue of poll results is too simple.


    Agreed. But even a simply fifo is ok, if you keep a long enough train of
    values. If you keep none, as ntp does, then it is tougher, and more
    frequent polling does degrade the frequency accuracy in the presence of
    noise. (but increases the phase accuracy).




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

    Unruh wrote:
    > "Richard B. Gilbert" writes:
    >
    >> Hal Murray wrote:
    >>>> It's the poll interval of ntpd. Ntpq does not poll! The poll interval
    >>>> varies between 2^MINPOLL and 2^MAXPOLL. You have set MINPOLL=MAXPOLL=4
    >>>> giving a poll interval of 2^4 or 16 seconds. This is usually the
    >>>> correct choice for a GPS receiver.
    >>> Why do you say that?

    >
    >> Because the GPS time signal is extremely accurate!

    >
    >>> Or let me ask it another way, how would you
    >>> decide what the right polling interval is?
    >>>

    >
    >> NTPD uses much longer poll intervals over the internet or even over a
    >> local network because of the variable delays introduced by the network.
    >> No two packets are guaranteed the same path between two points unless
    >> there IS only one path. In addition to the variations in travel time
    >> due to differing paths, there are also variable queuing delays!

    >
    > No. The longer poll intervals are mainly about keeping packets off the servers. In
    > principle it is always better to poll more. (in practice with the ntp
    > model, this is only partially true-- you want the 8 times the poll interval
    > to be close tothe Allan minimum if the noise model really is exponential
    > phase and 1/f drift noise. ( on most modern networks not the greatest
    > assumption-- day to night temp variations are probably more important for
    > the frequency noise).


    ntp presents a very light load on the servers unless you have some
    idiots polling at two second intervals (other than an initial burst at
    startup).

    The longer poll intervals allow ntpd to measure small errors very
    accurately.

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

    "Richard B. Gilbert" writes:

    >Unruh wrote:
    >> "Richard B. Gilbert" writes:
    >>
    >>> Hal Murray wrote:
    >>>>> It's the poll interval of ntpd. Ntpq does not poll! The poll interval
    >>>>> varies between 2^MINPOLL and 2^MAXPOLL. You have set MINPOLL=MAXPOLL=4
    >>>>> giving a poll interval of 2^4 or 16 seconds. This is usually the
    >>>>> correct choice for a GPS receiver.
    >>>> Why do you say that?

    >>
    >>> Because the GPS time signal is extremely accurate!

    >>
    >>>> Or let me ask it another way, how would you
    >>>> decide what the right polling interval is?
    >>>>

    >>
    >>> NTPD uses much longer poll intervals over the internet or even over a
    >>> local network because of the variable delays introduced by the network.
    >>> No two packets are guaranteed the same path between two points unless
    >>> there IS only one path. In addition to the variations in travel time
    >>> due to differing paths, there are also variable queuing delays!

    >>
    >> No. The longer poll intervals are mainly about keeping packets off the servers. In
    >> principle it is always better to poll more. (in practice with the ntp
    >> model, this is only partially true-- you want the 8 times the poll interval
    >> to be close tothe Allan minimum if the noise model really is exponential
    >> phase and 1/f drift noise. ( on most modern networks not the greatest
    >> assumption-- day to night temp variations are probably more important for
    >> the frequency noise).


    >ntp presents a very light load on the servers unless you have some
    >idiots polling at two second intervals (other than an initial burst at
    >startup).


    >The longer poll intervals allow ntpd to measure small errors very
    >accurately.


    If you want good time, use short polls. If you want good frequency, use
    long polls. ntp tries to strike a balance by having the poll interval be
    roughly the minimum of the Allan variance. But since it assumes, rathr than
    measures the location of that minimum, it is pretty useless for any real
    life situation. Thus, If you have continuous connectivity to the server,
    short poll intervals will give you the best time ( but not the best
    frequency) If you occasionally loose connectivity for some period, then the
    lack of good freq will hurt you as the time will drift off too fast.
    Longer poll intervals thus allow you to measure frequency drifts more
    accurately, but if you have continuous connectivity, why do you care if you
    know the drift rate accurately?

    The primary reason for long poll intervals is not to swamp the public
    servers. -- while one packet is not too bad, 10^6 packets pers second
    because of for example a very badly designed router which has your server's
    address hardwired in totally swamps your connction.

    So, if it is your own server which only you use, poll as often as you wish.
    If it is someone elses, don't.



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