|
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: ntpmon: On 2019-04-05 14:33, Gary E. Miller
wrote:
I'm not sure what you referred to precisely, but I did change the time refs order. See below.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. Any benefit to go slower?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. 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?--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.0001Yeah, bad placement in the ntp.conf. Also, poll of 1 is not good. 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.And where is NTP2 coming from? You never mentioned that before. 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.--ntp.conf extract:Which of course destroyed the context. Done, removed minpoll/maxpoll. Awaiting your reply to select a better one, if desirable.# 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 preferPut these at the bottom, with a reasonable poll. minpoll 0 is not reasonable. # Government NTP reference servers - Stratum 2: server time.nrc.ca iburst prefer server time.chu.nrc.ca iburst preferYou 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. 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 Thanks for your help, |
[Prev in Thread] | Current Thread | [Next in Thread] |