[ntp:questions] false ticker after GPS coldreset

William Unruh unruh at invalid.ca
Tue Oct 31 17:17:54 UTC 2017


On 2017-10-31, valizadeh65 at gmail.com <valizadeh65 at gmail.com> wrote:
> i have a ntp server based on Raspberry Pi3 with PPS (from u-blox6 ). i have also added a hardware clock to this system.
>
>
> SOME times there is a large offset(3-18 sec) on the SHM (ntp driver 28).

What program is delivering the time to the SHM? gpsd?

> i did some experiments and figured out it is related to "leap seconds". 

No idea how it could be related to leap seconds. Leap seconds are only one
second and that almost never happens. Is your gps broken?

> when i COLD-RESET the ublox(via USB through u-center) this offset appears on the ntp and both PPS and SHM become false-tickers.
>
>
> i wait for over 12.5 minutes so that the UTC time become accurate (Almanac data reception period) some times it works and SHM/PPS become truechimers and some times even after 24 hrs they still are falsetickers with "3 seconds" offset!

It really sounds like a broken gps to me. 

>
> here is what i think: 
> 1- system is tured on 
> 2- utc time is not accurate(leap seconds) but ntp dosent care and do iburst 
> 3- system time become updated
> 4- 12.5 min is passed
> 5- GPS time is changed (3-18 sec)
> 6- ntp is not able to handle this 
>
>
>
> i also used leap-second list file but there was no change
> http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14.
>
>
> *****************system power on:***************
> Every 1.0s: ntpq -p                           PI3: Tue Oct 31 07:18:25 2017
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> oPPS(0)          .kPPS.           0 l    1    8   17    0.000   -5.553   2.806
> *SHM(0)          .GPSD.           1 l    1    8   37    0.000    4.468   5.104
>  LOCAL(1)        .LOCL.           3 l   39    8   20    0.000    0.000   0.002

a) why do you have LOCAL as one of your clocks. That should basically never be
used.  It is useless except in very particular situations where it is a server
which has to keep serving time even if its time is completely useless, because
all clocks in an organisation have to on the same time, even if that is wrong.
b) Do you have some other source of time? 


>
> *****************after ~20 min:*****************
> Every 1.0s: ntpq -p                           PI3: Tue Oct 31 07:39:28 2017
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> oPPS(0)          .kPPS.           0 l    -   16  377    0.000   -4.023   0.355
> *SHM(0)          .GPSD.           1 l    -    8  377    0.000    1.894   1.650
>  LOCAL(1)        .LOCL.           3 l 1302    8    0    0.000    0.000   0.000
>
> ***************** COLDSTART *****************
> Every 1.0s: ntpq -p                            PI3: Tue Oct 31 07:44:09 2017
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> oPPS(0)          .kPPS.           0 l   17    8  374    0.000   -2.423   0.661
> *SHM(0)          .GPSD.           1 l   17    8  374    0.000   -0.057   0.652
>  LOCAL(1)        .LOCL.           3 l 1583    8    0    0.000    0.000   0.000
>
> *****************after COLDSTART *****************
> Every 1.0s: ntpq -p                            PI3: Tue Oct 31 07:44:17 2017
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> +PPS(0)          .kPPS.           0 l   25    8  370    0.000   -2.423   0.661
> *SHM(0)          .GPSD.           1 l    1    8  371    0.000  3044.83 3045.01
>  LOCAL(1)        .LOCL.           3 l 1591    8    0    0.000    0.000   0.000
>  
> *****************after COLDSTART *****************
> Every 1.0s: ntpq -p                                          PI3: Tue Oct 31 07:44:37 2017
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> xPPS(0)          .kPPS.           0 l   45    8  340    0.000   -2.423   0.590
> xSHM(0)          .GPSD.           1 l    5    8  347    0.000  3044.73 2573.41
>  LOCAL(1)        .LOCL.           3 l    3    8    1    0.000    0.000   0.002
>
>
>
>
> ntp.conf:
>
> tos maxdist 16
> tos mindist 0.400
>
>
> server 127.127.22.0 minpoll 3 maxpoll 4
> fudge 127.127.22.0 refid kPPS flag3 1 flag2 0
>
> server 127.127.28.0 minpoll 3 maxpoll 4 iburst prefer
> fudge 127.127.28.0 time1 +0.145 flag1 1 refid GPSD stratum 1
>
> server 127.127.1.1 minpoll 3 maxpoll 4 #hwcloak
> fudge 127.127.1.1 stratum 3

That is not the hardware clock. It is the system clock. It is completely
useless.

At present there is no evidence of anything. You do not have any independent
source of time, so you have no idea what the time actually is. 
Put in some network time sources, so you at least have a small idea of UTC
actually is. Eg pool.ntp.org


>



More information about the questions mailing list