[ntp:questions] Reasons of NTP not to use GPS source

[David Lord]

Igor Pavlov wrote:
> Sorry, didn't see the first part of your answer.
> I thought that offset - it's offset of current system time from NMEA-based
> info.
> But if system time would be set to this NMEA-based time, than offset would
> not be so great. Isn't it?
> But NTP prefer to sync to other sources - Why?
> 

1. PPS is usually very accurate, better than 1 us and better
than most pcs can use.

2. GPS using NMEA data streams of variable length can't be
very precise. Some models of GPS have option of binary output
and can be much better. My Sure GPS output has a mean offset
near to 0 ms but range is around +/- 80 ms.

There are some variables you may need to set for your GPS
make + model + firmware version.

Easiest is to set a nearby internet source as prefered peer
and gps as noselect. Enable peerstats and use peer_summary.

eg. last time I did this

########################
# ntp.conf

statistics loopstats peerstats sysstats
filegen loopstats file loopstats type day link enable
filegen peerstats file peerstats type day link enable
filegen sysstats  file sysstats  type day link enable

tos  minsane 3
tos  orphan 10
tos  mindist 0.4

server 127.127.20.2  mode 18  noselect
# this is custom mode for my Sure gps
fudge 127.127.20.2 time2 0.407  flag1 0  refid GPSb

server 127.127.22.2  minpoll  4  maxpoll  4
fudge  127.127.22.2  flag2 0 flag3 0  refid PPSb

server -4 ntp0.lordynet.org.uk  minpoll  6  maxpoll 10  iburst  prefer
server ....
server ....
server ....

###############

peer_summary has lines such as:

ident         cnt  mean    rms     max ....
127.127.22.2 1350 0.000  0.014   0.068 ....
127.127.20.2 1350 1.820 19.894  77.191 ....

When you have a reasonable estimate for fudge time2 you can
remove the noselect directive.


David


> 
> 2013/9/16 Igor Pavlov <pavlov.ig at gmail.com>
> 
>> I already tryed to use PPS from my GPS receiver connected to DCD-pin of
>> the same RS-232.
>> But I had PPS also marked as "x", that is why I tryed first to fix
>> problems with NMEA-based GPS data separate from PPS.
>> I will try to connect PPS again.
>>
>> But I can't understand why it is marked "x"? What is wrong with it?
>>
>>
>> 2013/9/16 Rob <nomail at example.com>
>>
>>> Igor Pavlov <pavlov.ig at gmail.com> wrote:
>>>> Hi!
>>>>
>>>> I am using GPS-receiver based on Geos-1m chip (
>>>> http://www.geostar-navigation.com/en/navigation_05.html)
>>>>
>>>> I connected it to serial port and configured NTP.
>>>> It becomes unused by NTP: when do ntpq -p reuest ti puts "x" near
>>>> "GPS_NMEA(1)" record.
>>>>
>>>> What reasons can be for this?
>>> A GPS with NMEA protocol is usually a very lousy time source.
>>> You can see this in your output: the time offset relative to
>>> the internet sources is very large:
>>>
>>>>      remote           refid      st t when poll reach   delay   offset
>>>>  jitter
>>>>
>>> ==============================================================================
>>>> xGPS_NMEA(1)     .GPS.            0 l   14   16  377    0.000  -303.07
>>>> 4.292
>>>> *stratum1.net    .PPS.            1 u   62   64  377   62.800  -68.052
>>>>  43.693
>>>> +dl120g7.naviteh 194.190.168.1    2 u   58   64  377   30.151  -100.04
>>>>  52.432
>>>> +89.221.207.113  192.36.133.25    2 u    -   64  377   10.006  -105.88
>>>>  64.279
>>> That is why ntpd declares the time as invalid and attempts to use the
>>> 3 other sources instead.
>>>
>>> When you want to fix this, you should use PPS with the receiver,
>>> when possible.
>>>
>>> _______________________________________________
>>> questions mailing list
>>> questions at lists.ntp.org
>>> http://lists.ntp.org/listinfo/questions
>>>
>>
>>
>> --
>> éÇÏÒØ ðÁ×ÌÏ×
>>
> 
> 
>