nmea refclock not locking to the pps

[Gary E. Miller]

Yo Tony!

On Fri, 3 Mar 2017 17:20:43 -0800
"Tony Hain" <tony at tndh.net> wrote:

> Gary E. Miller wrote:
> > Yo Tony!
> > 
> > On Fri, 3 Mar 2017 01:00:23 -0800
> > "Tony Hain" <tony at tndh.net> wrote:
> >   
> > > Not clear if this is an ntpsec issue, or comes from upstream, but
> > > the pps lock on the nmea stream never converges to a reasonable
> > > offset or apparently itself.  
> > 
> > Fiar warning: I always recommend people not to use that refclok.  
> 
> Well I tried gpsd with no luck, so I switched back, and the nmea
> driver was working up through 4.2.4p5, (which I was using because I
> couldn't get gpsd to work with ntpd back then either). In both cases
> I can get gpsd to show it is getting the correct feed from the gps, I
> just can't make it play well with ntpd. 

Which sounds similar to the problem you now report on the nmea driver.
Just with fewer tools to use.  And by gpsd, I hope you mene the SHM driver,
not the flakey gpsd-ng driver.

> I don't know if the offset shown in 4.2.8p9 is due to changes in that
> driver, or something in the BBB dmtpps driver implementation.

As I said, looks to me like the PPS got out voted.

> I will
> be taking that up on the FreeBSD arm list, but I was less concerned
> about that than the fact that the ntp-sec nmea driver appears to
> behave very differently from 4.2.8p9 nmea driver on the same
> hardware. I assumed that driver would have come down without changes
> other than device identifier, but clearly something is different.

I doubt it is a driver issue, my guess is that it is a dice toss thing.
With your setup NTP, of either flavor will lock onto the wrong source
now and again.

> > That should be a good verion.
> >   
> > > oPPS(0)          .PPS.            0 l    7    8  377   0.0000
> > > 0.0001 0.0001
> > > xNMEA(0)         .GPS.            0 l    6    8  377   0.0000
> > > -52.1062 1.4493
> > > *2001:470:e930:7 .GPS.            1 u   58   64  377   0.8173
> > > -0.9772 1.9614  
> > 
> > Clearly the PPS got outvoted.  
> 
> The behavior in that configuration is what I expected because the
> nmea start time jitter is high. It is the configurations where the
> pps flag is turned on for the nmea interface that are not working as
> expected.	

Your expectations do not match mine.  That looks bad to me and is fixable.

> > You neglected the most important par of a bug report: your
> > ntp.conf.  
> 
> Well it appears from the copy I got back that the message format was
> garbled.

Yeah, email does that.  Still very hard to read.

> # trying different values to see how it shifts
> refclock pps stratum 0 refid PPS minpoll 3 maxpoll 6 prefer time1
> 0.000000337160

Looks fairly good.  My experiments on RasPi 3 shows that
minpoll=maxpoll=2 will give best results.

> #refclock nmea refid GPS baud 4800 mode 8 minpoll 3 maxpoll 6 prefer
> flag1 0 flag4 1 time2 0.442916667 refclock nmea refid GPS baud 4800
> mode 8 minpoll 3 maxpoll 6 prefer flag1 1 flag4 1 time1
> 0.000000337160 time2 0.072916667

hard to tell, I think that is the line being used?  If so, that is part
if your problem.  You either need noselect, of minpoll much greater
than the minpossl of the PPS.  Otherwise, as you see, ntpd flips a coin
and locks onto the wrgon refclock.

> # The following three servers will give you a random set of three
> # NTP servers geographically close to you.
> # See http://www.pool.ntp.org/ for details. Note, the pool encourages
> # users with a static IP and good upstream NTP servers to add a server
> # to the pool. See http://www.pool.ntp.org/join.html if you are
> interested. #
> # The option `iburst' is used for faster initial synchronisation.
> # The option `maxpoll 9' is used to prevent PLL/FLL flipping on
> FreeBSD. #
> server 0.freebsd.pool.ntp.org iburst maxpoll 8

Best not to mix pool servers and specific servers.

> > I'm guessing you do not have prefer set on your PPS?  You'll also
> > want to set the mib- and max-poll on the PPS to much less than the
> > for the nmea driver.  
> 
> Prefer is set on the pps & nmea, as well as the reference i386 system
> which is what it keep locking to.

Well, that is part of the problem.  When ntpd start is it as likely to
choose the nmea and the pps.   You prefer your besst source, not a
flakey source.

> So right now the relevant lines are:
> refclock pps stratum 0 refid PPS minpoll 3 maxpoll 6 prefer time1
> 0.000000337160 refclock nmea refid GPS baud 4800 mode 8 minpoll 3
> maxpoll 6 prefer flag1 1 flag4 1 time1 0.000000337160 time2
> 0.072916667 server ntp2.tndh.net  minpoll 4 prefer

Pretty mushed together, did you actually prefer an internet source?

Don't do that!

> Is it possible that something in the interpretation of refclock nmea
> vs. peer 127.127.20.0 would account for the difference in handling
> the pps event? 

Nope.  The problem is you did not help ntpd select the best refclock.


> If it would be useful I can try switching back to gpsd to show what
> that is doing. It has been awhile so I don't recall exactly off the
> top of my head. 

Is you convert to SHN, but keep your 'prefer's the same way your
will get similar results.  Not every time as ntpd has to copin flip on
start about which of the 3 prefer to believe.

> PS:   a web page for gpsd with ntpsec {can't find it right now} says
> to ensure 3.17+, but the gpsd download page only offers 3.16-.

git head.  We ahave been remiss getting 3.17 released.  Nothing
related to what you see.


> PPS:   tried ntpviz this morning, and it failed due to variance in
> stats path assumption.

Easy to fix, just tell ntpviz where your stats are.

> I see from the command line help that command
> line and a config file is an option, and that is good because I will
> likely post-process these somewhere else because the clock system
> doesn't have gnuplot installed (2nd failure) and my cross-build
> system ran out of disk (3rd failure, done for the day)

So copy the files to a server with space and gnuplot.  Rsync, 
scp, NFS, etc.


>. That said, I
> had expected that ntpviz would read the ntp.conf file for the
> location of the stats dir,

Bad expectation.  Precisely because many people do rsync, scp, nfs
the stat files to unexpected places.

And when you change default one plae you should expect to need to change
defaults other places.  For example, ntpviz has no way of weven know
which ntp.conf you are using.  There really is no standard place for
ntp.conf.



> so maybe have it try its command line
> option, then its config file, then ntp.conf, then the existing
> default, would allow for post-processing while tracking with where
> ntpd has been told to put the stats, if it was told something
> specific.

Ugh.  Once you go off plan, ntpviz could never read you mind and get
back on plan.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/bugs/attachments/20170303/0f7f192f/attachment.bin>