gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] U-Blox M8, PPS and NTPsec - GPSd logic enhancement


From: Martin Boissonneault
Subject: Re: [gpsd-dev] U-Blox M8, PPS and NTPsec - GPSd logic enhancement
Date: Fri, 5 Apr 2019 17:48:14 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Hi Gary,

While writing this reply and applying your recommendations, my issues  with GPSd being offset by one second continued. I found that adding NAV-TIMEGPS was fixing the 1 second offset. I've tried it many times,  and disabling NAV-TIMEGPS and stop/start GPSd gets SHM(2) off by one second. Enabling back the message and stop/start GPSd and time is good! Odd...

I wrote the following reply to reflect the state of my configuration after testing. GPSd + NTPsec are currently working properly.

The currently enabled messages + sequence:
21:16:31  R -> UBX NAV-SOL,  Size  60,  'Navigation Solution'
21:16:31  R -> UBX NAV-TIMEGPS,  Size  24,  'GPS System Time'
21:16:32  R -> UBX NAV-SOL,  Size  60,  'Navigation Solution'
21:16:32  R -> UBX NAV-SAT,  Size 388,  'Satellite Status and Information' EVERY 5 SECONDS
21:16:32  R -> UBX NAV-TIMEGPS,  Size  24,  'GPS System Time'
21:16:33  R -> UBX NAV-SOL,  Size  60,  'Navigation Solution'
21:16:33  R -> UBX NAV-TIMEGPS,  Size  24,  'GPS System Time'

ntpmon:
     remote           refid      st t when poll reach   delay   offset   jitter
 win7mbt-lt_eth. .INIT.          16 u    -   32    0      0ns      0ns    954ns
 lenovowin7-pc_e 192.168.10.101   2 u    8   32  377 385.84us -1.121ms 309.22us
+time13.nrc.ca   132.246.11.231   2 u   40   64  377 6.4400ms 104.81us 811.99us
-time1.chu.nrc.c 209.87.233.52    2 u   42   64  377 31.087ms 886.73us 12.609ms
 ca.pool.ntp.org .POOL.          16 p    -  256    0      0ns      0ns    954ns
 us.pool.ntp.org .POOL.          16 p    -  256    0      0ns      0ns    954ns
 north-america.p .POOL.          16 p    -  256    0      0ns      0ns    954ns
 planefinder.poo .POOL.          16 p    -   64    0      0ns      0ns    954ns
 SHM(1)          .gPPS.           0 l    -   64    0      0ns      0ns    954ns
*SHM(2)          .gPPS.           0 l    2   64  377      0ns  5.872us     84ns
+ntp3.torix.ca   .PTP0.           1 u   42   64  377 10.333ms 218.57us 544.68us
ntpd ntpsec-1.1.3+ 2019-04-02T18:41:39Z        Updated: 2019-04-05T17:18:54 (1)
 lstint avgint rstr r m v  count rport remote address
      0  0.060    0 . 6 2  28906 53354 localhost
      8     25    0 . 4 4     70   123 lenovowin7-pc_eth.ve2mrx
     40     57  1c0 . 4 4     31   123 time13.nrc.ca
     42     56  1c0 . 4 4     31   123 time1.chu.nrc.ca
     42     56  1c0 . 4 4     31   123 ntp3.torix.ca
   1054     45  1c0 . 4 4     16   123 69-165-173-93.dsl.teksavvy.com
   1058     45  1c0 . 4 4     16   123 atl0.jane.mattnordhoff.net
   1060     45  1c0 . 4 4     16   123 ns1.baxterit.net
   1062     45  1c0 . 4 4     16   123 207.34.49.172 (vm-baxter.racknine.net)
   1063     45  1c0 . 4 4     16   123 time.no-such-agency.net

On 2019-04-05 14:33, Gary E. Miller wrote:
Yo Martin!

On Fri, 5 Apr 2019 13:34:16 -0400
Martin Boissonneault <address@hidden> wrote:

    From what I observed, sometimes GPSd seems to associate the
PPS to the wrong timestamp and that would  confuse NTPd.  
Now that is unusual.  At least native gpsd.  As long as your RasPi
has other network chimers that should never happen.  It can happen
when you have a voltage mismatch on PPS line, or large CPU load.  
   It just happened on restart of both GPSd and NTPsec. After a
while, it corrected itself without intervention.
Consistent with what I said to fix in your ntp.conf.
I'm not sure what you referred to precisely, but I did change the time refs order. See below.

I will disable the unused messages TIM-TP, NAV-TIMExx in the mean
time...
I would not bother.  At 115,200 you have more than enough bandwidth.
Any benefit to go slower?

--ntpmon while 1s off:
      remote           refid      st t when poll reach delay
offset jitter
  SHM(1)          .gPPS.           0 l    -    1    0   0.0000
0.0000 0.0010
*SHM(2)          .gPPS.           0 l    -    1  377   0.0000
1000.006 0.0001
Yeah, bad placement in the ntp.conf.  Also, poll of 1 is not good.
I removed minpoll/maxpoll from those entries. I thought NTPsec would pick what it wanted, and minpoll gave it "permission" to get below minpoll 4 on the PPS SHM. After removing minpoll/maxpoll, it's polling every 64 seconds the PPS SHM. That is equivalent to minpoll 6, right?

And where is NTP2 coming from?  You never mentioned that before.
In the past while doing tests, the GPSd SHM for PPS would come up as SHM(1). It's normally SHM(2). Whatever happens, it's 1 or 2, never both. I removed the SHM(0) refclock, the one related to GPSd serial time stamp.

--ntp.conf extract:
Which of course destroyed the context.
I don't believe so. All the time servers, pools and refclocks are in the extract in the same order, and that block is the beginning of the ntp.conf file. The logging, restricts and stats entries should not change the results? I can post all of it if you prefer.

# GPS PPS reference (GNSS PPS), only one of two will be present.
refclock shm unit 1 refid gPPS minpoll 0 maxpoll 8 prefer
refclock shm unit 2 refid gPPS minpoll 0 maxpoll 8 prefer
Put these at the bottom, with a reasonable poll.  minpoll 0 is
not reasonable.
Done, removed minpoll/maxpoll. Awaiting your reply to select a better one, if desirable.

# Government NTP reference servers - Stratum 2:
server time.nrc.ca iburst prefer
server time.chu.nrc.ca iburst prefer
You surely do not want to prefer chimers that are far away.

I removed prefers from all but the PPS SHM. I used them to activate the PPS refclock. I meant to prefer everything I trusted, that was everything but the pools.
1- The NRC ntp servers should never be wrong and they are monitored.  Related to the primary Cs or Rb national standard.
2- My GNSS should be good, as long as we have the leap seconds.
3- The pool ones are likely good but not guaranteed.

Of course, it plays with the NTPd selection algorithm, and since I removed the PPS refclock, prefers are no longer needed for the NTP refclocks. I left prefer on PPS SHM however.

The following is an extract because I did not include entries related related to restricts, logging, stats, etc. I paste all that is related to time refs, pool, servers in the order appearing in ntp.conf. It's the top of the file.

----- Partial ntp.conf
# LAN servers:

server 192.168.10.10 iburst maxpoll 5
server 192.168.10.11 iburst maxpoll 5

# Official Canadian gov NTP servers (Stratum 2)
server time.nrc.ca iburst
server time.chu.nrc.ca iburst

# Pool:
pool ca.pool.ntp.org iburst
pool us.pool.ntp.org iburst
pool north-america.pool.ntp.org iburst
pool planefinder.pool.ntp.org iburst


# --- Shared memory reference-clock
# Starting with ntp-4.2.5p138, don't use minpoll 4/maxpoll 4

# GPS PPS reference (Only one will be present)
refclock shm unit 1 refid gPPS prefer
refclock shm unit 2 refid gPPS prefer
-----

Thanks for your help,
Martin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]