# Slow convergence of NTP with GPS/PPS

Show 40 post(s) from this thread on one page
Page 6 of 6 First ... 4 5 6
• 10-25-2008, 11:53 PM
unix
Re: Slow convergence of NTP with GPS/PPS
Unruh wrote:[color=blue]
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>[color=green]
>> Unruh wrote:[color=darkred]
>>> "Richard B. Gilbert" <rgilbert88@comcast.net> 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).[/color][/color]
>[color=green]
>> 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).[/color]
>[color=green]
>> The longer poll intervals allow ntpd to measure small errors very
>> accurately.[/color]
>
> 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[/color]

And if you want both good time AND good frequency? Ideally the system
should provide both.
[color=blue]
> 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
>
> So, if it is your own server which only you use, poll as often as you wish.
> If it is someone elses, don't.
>
>[/color]
• 10-26-2008, 12:13 AM
unix
Re: Slow convergence of NTP with GPS/PPS
"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
[color=blue]
>Unruh wrote:[color=green]
>> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>[color=darkred]
>>> Unruh wrote:
>>>> "Richard B. Gilbert" <rgilbert88@comcast.net> 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).[/color]
>>[color=darkred]
>>> 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).[/color]
>>[color=darkred]
>>> The longer poll intervals allow ntpd to measure small errors very
>>> accurately.[/color]
>>
>> 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[/color][/color]
[color=blue]
>And if you want both good time AND good frequency? Ideally the system
>should provide both.[/color]

There is a tradeoff, and you have to decide where in that tradeoff you want
to be. For most people, when they ask for the time, they want the minimum
error in that time. for some they want time spans (eg measuring 100 sec
they want the least error in thet 100 s) Some want that if their
connectivity goes down for a day, the time on their machine during that day
is as small as possible. All demand different strategies. And by "good"
what do you mean?

In general in measuring anything the more measurements you have the better
it is. Unfortunately it also depends on how those measurements are used.
ntp uses ONLY the latest measurements to adjust the clock. Old measurements
are thrown away. That is valuable data.

[color=blue][color=green]
>> 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
>>
>> So, if it is your own server which only you use, poll as often as you wish.
>> If it is someone elses, don't.
>>
>>[/color][/color]
• 10-26-2008, 05:09 PM
unix
Re: Slow convergence of NTP with GPS/PPS
On Sat, Oct 25, 2008 at 4:51 AM, David Woolley
<david@ex.djwhome.demon.co.uk.invalid> wrote:[color=blue][color=green]
>> 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.
>>[/color]
> I think there have been reports that the 1 microsecond is actually a
> conservative figure.[/color]

Wouldn't the serial port itself prevent anything better than b 104 B5s
because of the commonly used 9600 baud rate on the serial line? Even
at the max possible (according to Garmin) baud rate of 38400, 26 B5s
would seem to be the best possible. Or does the PPS signal not depend
on the serial baud rate?

I have just acquired a GPS18LVC and am starting to wade into
configuring on FreeBSD, but I am not expecting anything better than
100 B5s at 9600 baud.
--
RPM
• 10-26-2008, 05:40 PM
unix
Re: Slow convergence of NTP with GPS/PPS
Ryan Malayter wrote:
[color=blue]
> would seem to be the best possible. Or does the PPS signal not depend
> on the serial baud rate?[/color]

PPS doesn't depend on the baud rate.

Also, asynchronous interfaces generally sample at 16 times the baud
rate, so a 9600 baud transmission could be resolved to 6.61
microseconds, even without PPS.
• 10-26-2008, 07:48 PM
unix
Re: Slow convergence of NTP with GPS/PPS
[email]malayter@gmail.com[/email] (Ryan Malayter) writes:
[color=blue]
>On Sat, Oct 25, 2008 at 4:51 AM, David Woolley
><david@ex.djwhome.demon.co.uk.invalid> wrote:[color=green][color=darkred]
>>> 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.
>>>[/color]
>> I think there have been reports that the 1 microsecond is actually a
>> conservative figure.[/color][/color]
[color=blue]
>Wouldn't the serial port itself prevent anything better than b 104 B5s
>because of the commonly used 9600 baud rate on the serial line? Even
>at the max possible (according to Garmin) baud rate of 38400, 26 B5s
>would seem to be the best possible. Or does the PPS signal not depend
>on the serial baud rate?[/color]

The PPS is on a separate line. It is NOT on the serial port.
[color=blue]
>I have just acquired a GPS18LVC and am starting to wade into
>configuring on FreeBSD, but I am not expecting anything better than
>100 B5s at 9600 baud.[/color]

That may be what you expect, but you can get it 1usec (1 micro second).

• 10-26-2008, 09:51 PM
unix
Re: Slow convergence of NTP with GPS/PPS
"Ryan Malayter" <malayter@gmail.com> wrote in message
news:5d7f07420810261009i23334bc8q7c8c2cfaf7f47ec0@mail.gmail.com...
[color=blue]
> [...] Or does the PPS signal not depend
> on the serial baud rate?[/color]

It's generally rigged to trigger an interrupt in the receiving
machine.

Groetjes,
Maarten Wiltink

• 10-27-2008, 05:13 PM
unix
Re: Slow convergence of NTP with GPS/PPS
[color=blue]
>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).[/color]

I think the worst case drift error is 2*500 PPM. You can have -500 in the
drift file when the value should be +500.

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

• 11-06-2008, 10:17 AM
unix
Re: Slow convergence of NTP with GPS/PPS
Hal Murray wrote:[color=blue]
>[color=green]
>>It isn't NTP which is the limit, but the GPS receiver acquiring lock from
>>scratch after an indeterminate period of being switched off. The GPS
>>could take minutes to lock and declare that it has valid time.[/color]
>
> From the spec sheet for the Garmin GPS 18x:
>
> Reacquisition: Less than 2 seconds
> Hot: Approx. 1 second (all data known)
> Warm: Approx. 38 seconds (initial position, time, and
> almanac known; ephemeris unknown)
> Cold: Approx. 45 seconds
>
> I believe that's typical of modern GPS receivers.[/color]

If "Cold" means there are no satellite data stored in the receiver then this
can not be true unless some assumptions are made which may or may not be
correct.

The GPS timing frames are using GPS time, not UTC.

GPS receivers can compute UTC from GPS time if they have received the UTC
parameter set from the satellites, which contains the current UTC offset in
seconds, plus a possible leap second announcement, plus some coefficients
for a polynomial required to compute small offsets in a
nanosecond/microsecond range.

This UTC data set is part of the satellite's navigational messages which is
repeated once every 12 minutes, so it may take up to 12 minutes after
powering up the GPS receiver in cold mode until those parameters are
available and thus the correct UTC time can be computed.

Martin
--
Martin Burnicki

Meinberg Funkuhren