Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Brian Inglis]

On 2017-01-24 14:47, juergen perlinger wrote:
>> I'm using this GPS module with a MTK3339 chipset. Bought from here:
>> https://www.adafruit.com/product/790
>> And I'm using ntpd with have PPS support compiled-in.
>> Juergen, thanks for pointing out the documentation. I've understood more
>> about NMEA receivers now.
>> I've tried Brian's and Juergen's server and fudge configuration, using
>> time2 to align with the NMEA data-stream and now getting better results.
>> I don't have a scope, so how do you suggest I determine the correct values
>> to use for time2 ?
> It's a bit of a chicken-egg problem. An easy way would be to have some
> decent time servers (you seem to have that) and mark you cklock to
> calibrate as 'noselect'. Take a note of the offset every hour or every
> other hour, and after some time (1/2 day or so -- the longer, the
> better) you have enough samples to get a decent correction for your
> initial estimate. (don't forget to remove the noselect statement after
> setting the final fudge value ;)
> There are also some more hints about fudge calibration in the ntp docs,
> but that needs some digging. I guess there are more elaborate ways, but
> this worked for me.
> Note that the serial timing (time2) is only critical if there is no PPS
> signal. Fine tuning of the PPS delay (time1) needs more equipment, I'm
> afraid. I never went into that -- for my purposes 50usec is definitely
> close enough. (That's a guesstimate, of course. Most of it will be
> caused by interrupt latency.)

Garmin gives the values 18.2ns for their cable delay per metre and 122.2ns 
for antenna plus receiver delay for their 18x-LVC, to which you need to 
add the port delay for the serial hardware interrupt, plus interrupt delay 
for the system hardware and software, which probably swamps the rest.
You could calibrate the port and system delay with a series of loopback 
interrupt timing tests on a system supporting an accurate hardware 
counter like x64 constant/invariant TSC.

There's nothing like that available for Adafruit/GlobalTop MKT-3339.
The discussion below may be helpful to the OP:
 
http://lists.ntp.org/pipermail/questions/2013-September/036165.html

as may:

http://open.konspyre.org/blog/2012/10/18/raspberry-flavored-time-a-ntp-server-on-your-pi-tethered-to-a-gps-unit/

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[juergen perlinger]

Hi Lloyd,

> Hi all.
> I'm using this GPS module with a MTK3339 chipset. Bought from here:
> https://www.adafruit.com/product/790
> And I'm using ntpd with have PPS support compiled-in.
> 
> Juergen, thanks for pointing out the documentation. I've understood more
> about NMEA receivers now.
> 
> I've tried Brian's and Juergen's server and fudge configuration, using
> time2 to align with the NMEA data-stream and now getting better results.
> I don't have a scope, so how do you suggest I determine the correct values
> to use for time2 ?

It's a bit of a chicken-egg problem. An easy way would be to have some
decent time servers (you seem to have that) and mark you cklock to
calibrate as 'noselect'. Take a note of the offset every hour or every
other hour, and after some time (1/2 day or so -- the longer, the
better) you have enough samples to get a decent correction for your
initial estimate. (don't forget to remove the noselect statement after
setting the final fudge value ;)

There are also some more hints about fudge calibration in the ntp docs,
but that needs some digging. I guess there are more elaborate ways, but
this worked for me.

Note that the serial timing (time2) is only critical if there is no PPS
signal. Fine tuning of the PPS delay (time1) needs more equipment, I'm
afraid. I never went into that -- for my purposes 50usec is definitely
close enough. (That's a guesstimate, of course. Most of it will be
caused by interrupt latency.)

> 
> server 127.127.20.0 mode 17 prefer minpoll 4 maxpoll 4
> fudge  127.127.20.0 flag1 1 flag3 1 time2 0.500 # pps kernel msg offset .5s
> 
> 
>  remote   refid  st t when poll reach   delay   offset
> jitter
> ==
> *GPS_NMEA(0) .GPS.0 l   15   16  3770.000  -49.176
> 25.007
> +time.sunrise.ne 195.141.230.78   2 u   22   64  3778.357  114.864
> 17.534
> +192.33.214.47   129.194.21.195   2 u   23   64  377   13.382  115.777
> 18.286
> +ntp0.as34288.ne 85.158.25.74 2 u   32   64  3776.914  113.929
> 17.013
> +eudyptula.init7 217.147.223.78   3 u   26   64  3779.683  115.067
> 17.673
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Brian Inglis]

On 2017-01-24 13:19, Lloyd Dizon wrote:
> Hi all.
> I'm using this GPS module with a MTK3339 chipset. Bought from here:
> https://www.adafruit.com/product/790
> And I'm using ntpd with have PPS support compiled-in.

Should have bought the HAT:
https://www.adafruit.com/products/2324
which has instructions:
https://learn.adafruit.com/adafruit-ultimate-gps-hat-for-raspberry-pi
which you should follow anyway, as it uses the same chip, delta any 
differences between your chip connection and the HAT GPIO 14/TXD, 
15/RXD, 4/PPS, your RPi model, Debian release, and Linux kernel.

See also:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
http://www.satsignal.eu/ntp/Raspberry_Time%20-%20Broadband%20Ham%20Net.pdf
https://forums.adafruit.com/viewtopic.php?f=50=70133=60#p359668
and elsewhere from searching "RPi NTP stratum 1".

> Juergen, thanks for pointing out the documentation. I've understood
> more about NMEA receivers now.
> I've tried Brian's and Juergen's server and fudge configuration,
> using time2 to align with the NMEA data-stream and now getting better
> results.
> I don't have a scope, so how do you suggest I determine the correct
> values to use for time2?

If you follow the above instructions for setting up PPS, and ensure 
that the chip only generates $GPRMC messages, you won't need to, as the 
PPS timestamp replaces the NMEA timestamp if the message is received 
within about .4s of time2 fudge of PPS, and the tally code will change 
to "o", indicating it is synced to kernel PPS.

> server 127.127.20.0 mode 17 prefer minpoll 4 maxpoll 4
> fudge  127.127.20.0 flag1 1 flag3 1 time2 0.500 # pps kernel msg offset .5s
>  remote   refid  st t when poll reach   delay   offset  jitter
> ==
> *GPS_NMEA(0) .GPS.0 l   15   16  3770.000  -49.176  25.007
> +time.sunrise.ne 195.141.230.78   2 u   22   64  3778.357  114.864  17.534
> +192.33.214.47   129.194.21.195   2 u   23   64  377   13.382  115.777  18.286
> +ntp0.as34288.ne 85.158.25.74 2 u   32   64  3776.914  113.929  17.013
> +eudyptula.init7 217.147.223.78   3 u   26   64  3779.683  115.067  17.673

With a bit more tweaking, you'll do better by three or four orders of 
magnitude.

My logarithmic human rating scale for servers by offset MSD goes 
(units ms as from ntpq; ntpd resets by stepping time if offset > 128ms): 

128 100101.1 .01.001ms
unsynced   available   poor  fair good  great   besttime-nut

[time-nuts are a group interested in time measurement from us down to fs].

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Lloyd Dizon]

Hi all.
I'm using this GPS module with a MTK3339 chipset. Bought from here:
https://www.adafruit.com/product/790
And I'm using ntpd with have PPS support compiled-in.

Juergen, thanks for pointing out the documentation. I've understood more
about NMEA receivers now.

I've tried Brian's and Juergen's server and fudge configuration, using
time2 to align with the NMEA data-stream and now getting better results.
I don't have a scope, so how do you suggest I determine the correct values
to use for time2 ?

server 127.127.20.0 mode 17 prefer minpoll 4 maxpoll 4
fudge  127.127.20.0 flag1 1 flag3 1 time2 0.500 # pps kernel msg offset .5s


 remote   refid  st t when poll reach   delay   offset
jitter
==
*GPS_NMEA(0) .GPS.0 l   15   16  3770.000  -49.176
25.007
+time.sunrise.ne 195.141.230.78   2 u   22   64  3778.357  114.864
17.534
+192.33.214.47   129.194.21.195   2 u   23   64  377   13.382  115.777
18.286
+ntp0.as34288.ne 85.158.25.74 2 u   32   64  3776.914  113.929
17.013
+eudyptula.init7 217.147.223.78   3 u   26   64  3779.683  115.067
17.673




regards.
Lloyd
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[juergen perlinger]

Hi all,

On 01/23/2017 05:43 PM, Lloyd Dizon wrote:
> Hi.
> See below.
> 
> On Mon, Jan 23, 2017 at 4:54 PM, Jan Ceuleers 
> wrote:
> 
>> On 23/01/17 12:25, Lloyd Dizon wrote:
>>> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
>>> offsets between the GPS readings and network NTPs.
>>
>> Could you show us the relevant extracts from your ntp.conf file related
>> to the GPS source? That is: at least the server line and any fudge lines?
>>
> 
> enable mode7
> 
> # Local
> #server 127.127.1.0
> #fudge 127.127.1.0 stratum 10
> 
> # GPS with PPS enabled
> server 127.127.20.0 mode 17 minpoll 6 maxpoll 6 iburst true prefer
> fudge 127.127.20.0 time1 1 flag1 1 refid GPS

Why do you add one full second time correction to the time PPS stamp?

I admit that having the output of ntpq in millisecs and the config vaues
in seconds is confusing, but 'time1 1' adds a full second to the PPS
time stamp. This shouldn't be needed -- PPS delay correction is in the
sub-millisecond range if it's used at all.

If you have problems with a huge delay between PPS and your first NMEA
sentence of a new burst, use fudge time2 (!!) to compensate for that.
This can just lead to assigning a wrong second to the PPS value, see

http://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks
https://support.ntp.org/bin/view/Support/ConfiguringGarminRefclocks
http://doc.ntp.org/current-stable/drivers/driver20.html

I'm using a GPS18x-LVC with the following settings:

server 127.127.20.0 mode 33 noselect minpoll 4 maxpoll 8
fudge 127.127.20.0 flag1 1 time2 0.51 refid GPSc

Note the time2 offset of 510msec that I need to get the NMEA data stream
aligned with the PPS signal. If I don't do this, I end up with the wrong
second assigned to the PPS signal, too.

> 
> # Internet time servers for sanity
> server 0.ch.pool.ntp.org iburst prefer
> server 1.ch.pool.ntp.org iburst
> server 2.ch.pool.ntp.org iburst
> server 3.ch.pool.ntp.org iburst
> 
> # By default, exchange time with everybody, but don't allow configuration.
> restrict default kod limited nomodify notrap nopeer noquery
> restrict -6 default kod limited nomodify notrap nopeer noquery
> 
> # Local users may interrogate the ntp server more closely.
> restrict 127.0.0.1
> restrict -6 ::1
> 
> # Drift file etc.
> driftfile /var/lib/ntp/ntp.drift
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Brian Inglis]

On 2017-01-23 09:43, Lloyd Dizon wrote:
> On Mon, Jan 23, 2017 at 4:54 PM, Jan Ceuleers wrote:
>> On 23/01/17 12:25, Lloyd Dizon wrote:
>>> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
>>> offsets between the GPS readings and network NTPs.
>> Could you show us the relevant extracts from your ntp.conf file related
>> to the GPS source? That is: at least the server line and any fudge lines?
> # GPS with PPS enabled
> server 127.127.20.0 mode 17 minpoll 6 maxpoll 6 iburst true prefer
> fudge 127.127.20.0 time1 1 flag1 1 refid GPS

NMEA drivers need about 4.-.6s time2 fudge split the difference; 
if you have PPS enabled in the kernel, try: 

server 127.127.20.0 mode 17 prefer minpoll 4 maxpoll 4
fudge  127.127.20.0 flag1 1 flag3 1 time2 0.500 # pps kernel msg offset .5s

without PPS enabled, GPS is only good for navigation.
Give it 15 minutes to load the almanac and leap seconds count, and start 
providing UTC instead of GPS time.
If your GPS provider provides almanac data and a utility to preload it, 
you have to add that to the startup script.
Setting the CPU governor to performance in there also helps frequency 
stability.
I'm keeping low us time even over wifi network:

$ ntpq -p -c rl -c cl
 remote   refid  st t when poll reach   delay   offset  jitter
==
oGPS_NMEA(0) .GPS.0 l   12   16  3770.0000.003   0.001
*W10 .GPS.1 s7   16  3771.8890.542  43.149
+nist-time-serve .ACTS.   1 u   22   64  377   76.064  -14.426 102.263
+utcnist2.colora .NIST.   1 u   35   64  377   89.428   -8.613  68.220
+nisttime.edzone .ACTS.   1 u   50   64  377  102.386  -22.114  82.215
+montpelier.ilan .GPS.1 u4   64  377  110.528   -8.813  86.635
+tock.usnogps.na .PTP.1 u   31   64  377  127.9910.042  87.657
-ns2.cs.ucalgary 136.159.2.2492 u   35   64  377   13.4112.875   2.666
+SUE.CC.UREGINA. 142.3.100.2  2 u-   64  377   30.631   -1.914  75.804
associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
version="ntpd 4.2.6p5@1.2349-o Mon Sep 19 21:57:11 UTC 2016 (1)",
processor="armv7l", system="Linux/4.4.38-v7+", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdisp=0.417, refid=GPS,
reftime=dc30ee85.86d31d83  Mon, Jan 23 2017 21:05:09.526,
clock=dc30ee92.d5162ac9  Mon, Jan 23 2017 21:05:22.832, peer=14553, tc=4,
mintc=3, offset=0.003, frequency=-4.292, sys_jitter=0.001,
clk_jitter=0.000, clk_wander=0.001, tai=37, leapsec=20170101,
expire=20170628
associd=0 status=00f2 15 events, clk_bad_format,
device="NMEA GPS Clock",
timecode="$GPRMC,210521.000,A,5108.3564,N,11411.5671,W,0.62,342.03,230117,,,D*71",
poll=64009, noreply=0, badformat=30, baddata=0, fudgetime1=0.000,
stratum=0, refid=GPS, flags=5

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Jan Ceuleers]

On 23/01/17 17:43, Lloyd Dizon wrote:
>
> On Mon, Jan 23, 2017 at 4:54 PM, Jan Ceuleers
> > wrote:
>
> Could you show us the relevant extracts from your ntp.conf file
> related
> to the GPS source? That is: at least the server line and any fudge
> lines?
>
>
> enable mode7
> (etc)

Okay, your offset isn't caused by a fudge factor. I'm out.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Mike Cook]

Harlen’s idea may be right. If your GPS is seeing a lot of SVs then the NMEA 
stream can overrun the second. The time used is that of the end of the the 
first recognized NMEA sentence containing the time field in the cycle.
If you are able to send the commands necessary, you can limit the data stream 
length by selecting just $GPRMC which is often the first sent.
The NMEA command to do that depends on the receiver. What make/model do you 
have?

To check on what your device is sending, cat your NMEA device.

$ sudo cat /dev/gps0  #  that will get the whole stream 

You can check the UTC date from one sentence against another source to see if 
the seconds field is right. It could be that the receiver isn’t counting in 
leap seconds correctly. I had that with one receiver. 

Does your GPS have PPS output? If you have a scope you can check if the data is 
running into the following second. 

Have fun

> Le 23 janv. 2017 à 13:03, Harlan Stenn  a écrit :
> 
> Lloyd Dizon writes:
>> Hi.
>> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
>> offsets between the GPS readings and network NTPs.
>> 
>> lloyd@jadzia:~ $ ntpq -p
>> remote   refid  st t when poll reach   delay   offset
>> jitter
>> =
>> =
>> LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
>> 0.001
> 
> Why are you using the LOCAL refclock?
> 
>> xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
>> 142.320
> 
> Is your NMEA source identifying the wrong second?
> 
>> *ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
>> 1.687
>> +246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
>> 1.376
>> +ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
>> 3.299
>> -khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
>> 4.474
> 
> Your NMEA source is sending ntpd samples every 16 seconds.  It's filling
> the sample buffer, and the the other sources (are you using iburst on
> these?  You should be...) are taking a while to provide enough samples
> to detect that your NMEA source is "off" by a second.
> 
>> Sometimes it will be the GPS which will have 1000ms offset and the NTP
>> serveurs will have 4-6ms instead.
>> 
>> Anybody has a clue what is going on?
> 
> I think your NMEA signal is identifying the wrong second.
> -- 
> Harlan Stenn 
> http://networktimefoundation.org - be a member!
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

"The power of accurate observation is commonly called cynicism by those who 
have not got it. »
George Bernard Shaw

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Lloyd Dizon]

Hi.
See below.

On Mon, Jan 23, 2017 at 4:54 PM, Jan Ceuleers 
wrote:

> On 23/01/17 12:25, Lloyd Dizon wrote:
> > I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
> > offsets between the GPS readings and network NTPs.
>
> Could you show us the relevant extracts from your ntp.conf file related
> to the GPS source? That is: at least the server line and any fudge lines?
>

enable mode7

# Local
#server 127.127.1.0
#fudge 127.127.1.0 stratum 10

# GPS with PPS enabled
server 127.127.20.0 mode 17 minpoll 6 maxpoll 6 iburst true prefer
fudge 127.127.20.0 time1 1 flag1 1 refid GPS

# Internet time servers for sanity
server 0.ch.pool.ntp.org iburst prefer
server 1.ch.pool.ntp.org iburst
server 2.ch.pool.ntp.org iburst
server 3.ch.pool.ntp.org iburst

# By default, exchange time with everybody, but don't allow configuration.
restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict -6 ::1

# Drift file etc.
driftfile /var/lib/ntp/ntp.drift
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Jan Ceuleers]

On 23/01/17 12:25, Lloyd Dizon wrote:
> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
> offsets between the GPS readings and network NTPs.

Could you show us the relevant extracts from your ntp.conf file related
to the GPS source? That is: at least the server line and any fudge lines?
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Lloyd Dizon]

On Mon, Jan 23, 2017 at 1:03 PM, Harlan Stenn  wrote:

> Lloyd Dizon writes:
> > Hi.
> > I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
> > offsets between the GPS readings and network NTPs.
> >
> > lloyd@jadzia:~ $ ntpq -p
> >  remote   refid  st t when poll reach   delay   offset
> > jitter
> > 
> =
> > =
> >  LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
> > 0.001
>
> Why are you using the LOCAL refclock?
>

I shouldn't. I removed it now.


> xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
> > 142.320
>
> Is your NMEA source identifying the wrong second?
>
> > *ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
> > 1.687
> > +246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
> > 1.376
> > +ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
> > 3.299
> > -khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
> > 4.474
>
> Your NMEA source is sending ntpd samples every 16 seconds.  It's filling
> the sample buffer, and the the other sources (are you using iburst on
> these?  You should be...) are taking a while to provide enough samples
> to detect that your NMEA source is "off" by a second.
>

I changed the min and maxpoll to 6 to be consistent with the network
servers.
I'm still getting a 1000ms offset though.


> Anybody has a clue what is going on?
>
> I think your NMEA signal is identifying the wrong second.
>

So my NMEA device is broken then. Is there a way to compensate manually if
the device is systematically adding (or subtracting) 1000ms. Is is correct
to compensate manually.
I looked at the time1 argument to fudge but I only had 300ms removed from
the offset.

Before using "time1 1":

Every 1.0s: ntpq
-pn
Mon Jan 23 15:27:46 2017

 remote   refid  st t when poll reach   delay   offset
jitter
==
x127.127.20.0.GPS.0 l   48   64   170.000   10.095
6.428
*178.209.53.202  166.171.80.133 u   31   64   37   11.298  1015.56
9.837
+81.94.123.1685.158.25.74 2 u   30   64   379.788  1013.30
9.577
+212.51.144.44   .PPS.1 u   28   64   379.864  1013.35
9.723
+82.197.188.130  195.186.1.1003 u   32   64   379.832  1013.75
9.664


After using time1 1:
Every 1.0s: ntpq
-pn
Mon Jan 23 15:28:27 2017

 remote   refid  st t when poll reach   delay   offset
jitter
==
 127.127.20.0.GPS.0 l   16   6400.0000.000
0.001
*192.33.96.102   .PPS.1 u4   641   13.617  721.727
0.112
+5.148.175.134   131.188.3.2222 u4   6419.377  720.615
0.436
+81.94.123.1785.158.25.74 2 u3   6419.659  720.234
0.552
-46.22.26.12 162.23.41.56 2 u2   641   15.923  722.333
0.171
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[François Meyer]

Oops. seems I need some optics upgrade... 
Badly misread, sorry.


On Mon, 23 Jan 2017, François Meyer wrote:


Hi, these are milliseconds, not seconds, so your offset is
1 s, not 1000s.


Anybody has a clue what is going on?


A bogus (out of date) leap second file somewhere on the raspi ?


On Mon, 23 Jan 2017, Lloyd Dizon wrote:


Hi.
I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
offsets between the GPS readings and network NTPs.

lloyd@jadzia:~ $ ntpq -p
remote   refid  st t when poll reach   delay   offset
jitter


==

LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
0.001
xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
142.320
*ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
1.687
+246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
1.376
+ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
3.299
-khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
4.474



Sometimes it will be the GPS which will have 1000ms offset and the NTP
serveurs will have 4-6ms instead.


Anybody has a clue what is going on?


Thank you.
Lloyd
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions



--
François MeyerTel : (+33) 3 81 66 69 27   Mob : 6 27 28 56 83
Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE
Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 ***
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions


--
François MeyerTel : (+33) 3 81 66 69 27   Mob : 6 27 28 56 83
Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE
Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 ***
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[François Meyer]

Hi, these are milliseconds, not seconds, so your offset is
1 s, not 1000s.


Anybody has a clue what is going on?


A bogus (out of date) leap second file somewhere on the raspi ?


On Mon, 23 Jan 2017, Lloyd Dizon wrote:


Hi.
I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
offsets between the GPS readings and network NTPs.

lloyd@jadzia:~ $ ntpq -p
remote   refid  st t when poll reach   delay   offset
jitter
==
LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
0.001
xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
142.320
*ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
1.687
+246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
1.376
+ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
3.299
-khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
4.474



Sometimes it will be the GPS which will have 1000ms offset and the NTP
serveurs will have 4-6ms instead.


Anybody has a clue what is going on?


Thank you.
Lloyd
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions



--
François MeyerTel : (+33) 3 81 66 69 27   Mob : 6 27 28 56 83
Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE
Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 ***
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] 1000s offset between GPS module and NTP servers

[Harlan Stenn]

Lloyd Dizon writes:
> Hi.
> I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
> offsets between the GPS readings and network NTPs.
> 
> lloyd@jadzia:~ $ ntpq -p
>  remote   refid  st t when poll reach   delay   offset
> jitter
> =
> =
>  LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
> 0.001

Why are you using the LOCAL refclock?

> xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
> 142.320

Is your NMEA source identifying the wrong second?

> *ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
> 1.687
> +246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
> 1.376
> +ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
> 3.299
> -khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
> 4.474

Your NMEA source is sending ntpd samples every 16 seconds.  It's filling
the sample buffer, and the the other sources (are you using iburst on
these?  You should be...) are taking a while to provide enough samples
to detect that your NMEA source is "off" by a second.

> Sometimes it will be the GPS which will have 1000ms offset and the NTP
> serveurs will have 4-6ms instead.
> 
> Anybody has a clue what is going on?

I think your NMEA signal is identifying the wrong second.
-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] 1000s offset between GPS module and NTP servers

[Lloyd Dizon]

Hi.
I've installed a GPS module on a Raspberry Pi and I'm getting 1000ms
offsets between the GPS readings and network NTPs.

lloyd@jadzia:~ $ ntpq -p
 remote   refid  st t when poll reach   delay   offset
jitter
==
 LOCAL(0).LOCL.  10 l  447   64  1000.0000.000
0.001
xGPS_NMEA(0) .GPS.0 l-   16  3770.0006.229
142.320
*ntp0.as34288.ne 85.158.25.74 2 u   24   6439.810  1004.83
1.687
+246.11.25.212.f 162.23.41.10 2 u   19   643   10.636  1004.22
1.376
+ch-ntp01.10g.ch 81.94.123.17 3 u   21   643   10.493  1001.79
3.299
-khyber.madduck. 192.33.96.1022 u   20   6438.703  1001.72
4.474



Sometimes it will be the GPS which will have 1000ms offset and the NTP
serveurs will have 4-6ms instead.


Anybody has a clue what is going on?


Thank you.
Lloyd
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions