2

I'm somewhat unsure about the offset value which ntpq is showing me. This is on a Raspberry Pi with PPS support compiled in the kernel.

I just moved that device from location, so ntpd was first fetching the NTP data from the public server for a couple of minutes. After I connected the antenna and it started to pick up a GPS signal, it would show the GPS signal to have an offset of 3 seconds to the public servers.

Actually, the values are fluctuating wildly. The last sample shows that PPS is getting recognized ("o")

I'm able to ping rustime01.rus.uni-stuttgart.de (~15ms ping time) but not the servers from ptb.de, they may have ICMP disabled.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(0)     .GPS.            0 l   12   16  377    0.000  2998.06   0.104
+rustime01.rus.u .PZF.            1 u   41   64  377   14.546   -3.700   5.195
-ptbtime1.ptb.de .PTB.            1 u   46   64  377   23.661    0.162   2.361
-ptbtime2.ptb.de .PTB.            1 u   40   64  377   24.330   -3.517   3.668
+ptbtime3.ptb.de .PTB.            1 u   41   64  377   22.839   -2.710   2.630


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(0)     .GPS.            0 l    9   16   37    0.000   -0.994   0.647
+rustime01.rus.u .PZF.            1 u   18   64    3   16.222  -2997.4   0.456
-ptbtime1.ptb.de .PTB.            1 u   20   64    3   28.564  -2997.0   0.746
+ptbtime2.ptb.de .PTB.            1 u   22   64    3   24.178  -2998.7   1.025
-ptbtime3.ptb.de .PTB.            1 u   13   64    1   24.704  -2998.7   1.149


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l    7   16    3    0.000    9.086   5.324
*rustime01.rus.u .PZF.            1 u   33   64    1   14.844    5.097   1.164
+ptbtime1.ptb.de .PTB.            1 u   32   64    1   24.583    5.164   1.921
-ptbtime2.ptb.de .PTB.            1 u   35   64    1   31.230    7.191   3.878
+ptbtime3.ptb.de .PTB.            1 u   31   64    1   24.379    5.542   0.819


     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l   14   16  377    0.000   29.241   4.327
*rustime01.rus.u .PZF.            1 u   47   64   17   14.235   31.713  15.915
+ptbtime1.ptb.de .PTB.            1 u   48   64   17   24.028   25.617  11.747
-ptbtime2.ptb.de .PTB.            1 u   53   64   17   24.692   19.764   9.333
+ptbtime3.ptb.de .PTB.            1 u   47   64   17   24.221   31.335  15.363

The following is the content of the config file

pi@rpi-ntp ~ $ cat /etc/ntp.conf

driftfile /home/pi/ntp/ntp.drift

statistics loopstats peerstats
statsdir /home/pi/ntp/stats/
filegen loopstats file loops type day enable
filegen peerstats file peers type day enable

server 127.127.20.0 mode 17 minpoll 4 maxpoll 4 iburst true prefer
fudge 127.127.20.0 flag1 1 flag3 0 time2 0.496

server rustime01.rus.uni-stuttgart.de iburst
server ptbtime1.ptb.de iburst
server ptbtime2.ptb.de iburst
server ptbtime3.ptb.de iburst

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

What could be causing this, and which time am I actually using then?

Improve this question
8
  • ntp will work out an average of all the times, and their delays, to give you a 'local time' so you're not using any specific ONE currently. As to why the sync difference between the gps and the ntp servers, I can only suggest that hopefully someone else can answer.
    – djsmiley2kStaysInside
    Apr 8, 2017 at 12:02
  • It would help if you could compare times with a radio-synchronised clock, or the time signal on an FM radio station, so as to confirm whether the GPS or internet time is accurate. From here, the internet-synchronised clock on my laptop is only a fraction of a second behind the radio clock (I'd guess 0.2sec on a side-by-side visual comparison). I have just compared the GPS time on my SatNav and after fixing it's just over two seconds behind the radio clock. You have raised a very interesting issue.
    – AFH
    Apr 8, 2017 at 12:56
  • Maybe it's related to leap seconds? en.wikipedia.org/wiki/Global_Positioning_System#Leap_seconds GPS doesn't account for them, and the initial offset of 2998.06 ms is very suspicious. But the RasPi got set up on 2014-05-09, and has never been touched since then. In the meantime only 2 leap seconds got added. It's running ntpd 4.2.7p442
    – Daniel F
    Apr 8, 2017 at 13:04
  • Yes, it's certainly confusing. According to your reference and this, the difference should be much greater. Maybe the correction was based on the difference when the time interpretation software was created, rather than installed, though this doesn't tie in with my GPS, where I have updated the roadmap navigation, but not the separate 15-year-old terrain navigation package which I used. As for your Pi, have you really not set the clock for 3 years? If so I would have expected a much greater difference: real-time clocks are rarely that accurate.
    – AFH
    Apr 8, 2017 at 13:33
  • 1
    @djsmiley2k, that is incorrect. Ntpd uses the time from the selected reference only (marked with a *). OP, What device did you move and when? I'm having a hard time tracing the order of events in your question. Here are some initial thoughts, no particular order: If you moved the GPS antenna then the timing output of the receiver will be out until the receiver has locked onto satellites and averaged a new timing solution (could be up to an hour or more depending on how it's configured). However, the GPS receiver is only supplying a PPS signal - there is no timecode in a PPS signal cont..
    – Darren
    Apr 8, 2017 at 17:44

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .