nmea refclock not locking to the pps

[Gary E. Miller]

Yo Tony!

On Tue, 7 Mar 2017 13:31:14 -0800
"Tony Hain" <tony at tndh.net> wrote:

> Gary E. Miller wrote:
> > Yo Tony!
> > 
> > On Sat, 4 Mar 2017 17:29:56 -0800
> > "Tony Hain" <tony at tndh.net> wrote:
> >   
> > > > 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.  
> > >
> > > Flakey doesn't even begin to describe it:
> > > # gpsmon
> > > gpsmon:ERROR: SER: device open of tcp://localhost:2947 failed: No
> > > such file or directory - retrying read-only  
> > 
> > Odd, something wrong with your setup.  My gpsd is working fine on
> > IPv6:  
> 
> I didn't do anything to specify it should build IPv6, so if the
> default is to build without it, that is what I am running. I was just
> following the instructions on catb, so I will look at the ports
> makefile when I get a chance to see if there is something that I
> should have specified before the make.

The default is to build with IPv6.

> scons didn't build cgps.

cgps has never been an option.  It is always built.


> With the 3.14 port there was a cgps, but it
> fails on a lib error if used with the 3.17 gpsd.

Of course, the shared lib of 3.14 is not compatible with that of 3.17.

> Fresh installing the
> ports 3.14 build, cpgs worked and showed the pps was turned off
> consistent with the log file stating it was being shutdown due to
> lack of a serial data stream.

Uh, no, the log file output you sent me said no KPPS.  That is a compile
time problem.

You have a LOT of compile time problems.  Very odd.


> > > So, yes the SHM driver is the one I have been testing and it is
> > > not playing well with ntpd.  
> > 
> > Odd, I have been using that on large numbers of hosts for well over
> > a decade with no issues.  Many others as well.  Care to elaborate?  
> 
> I am aware lots of people run it without issue.

So once again, pointing to an issue about your host.

> -- Ok, so part of the issue with gpsd is that ppsthread.c assumes
> that "non-linux" -- systems always have the pps on the primary serial
> port control pins.

Yes, by default, Just override on the command line.  But pointless
until you fix KPPS.

> getting the
> maintainer to move from 3.14 to something current needs to happen.

Yes, disappointing to dfix bugs and add features and not have them go
downstream.

> > Lost me, range of what?  You mean poll?  It is documented as one to
> > I think 2048.  Anything past 8 is just wrong for PPS.  
> 
> Yes poll, but the min range of 2 doesn't result in a poll of 4. It
> polls at 8 which is identical to minpoll = 3.

No.  minpoll is 1. Not 2.  Your best minpoll is 2, or maybe 3, depending on
the result you want.

> > Im pretty sure the RasPi is not that old.  minpoll is very host
> > specific.  
> 
> The ntp documentation has never discussed poll in a host specific way
> that I recall. Look back at all the ntp4 documentation you can find,
> and the minimum number discussed is 4.

If you can point me to a specific doc error I can fix it.  And remember,
the doc is not the place for discussion, that belongs in howto's, faq's
and blogs.

> > I did a series of experiments, documented on devel at ntpsec.org list.
> > They showed poll =1 or poll =2 is clearly better, depending on what
> > you are optimizing.  Check the list archives.  
> 
> That must be an ntpsec specific fix, because when you first said that
> I set minpoll=2 maxpoll=2 in 4.2.8p9 which was running at the time
> and the period was locked at 8 sec, just as it always has. When I set
> that on the ntpsec config  for the run below it does poll at 4.

I don't keep track of what NTP Classic does.  This is the NTPsec list.

> > > I understand that. The pps driver says it is disabled unless
> > > there is a preferred server in the surviving set, or when another
> > > driver is tracking pps. When I make the nmea driver the only
> > > preferred option, the pps driver drops out because when the nmea
> > > driver is flag1 0, its offset is so large that it becomes a false
> > > ticker so there are no preferred survivors, and with flag1 1 the
> > > nmea driver takes over the pps tracking.  
> > 
> > Right, so don't do that!  
> 
> Don't do what? Setting flag1 1 works ~fine on 4.2.8p9, and tracks the
> pps as it should.

Yes, sometimes, not always.  IMHO you are seeing experimeter error.  You
can't judge NTP Classic or NTPsec until your setup has run untouched for
24 hours.  You have been violating that rule.

> It looks like the offset I am seeing from the local
> reference systems in the 4.2.8p9 case might be explained by an
> asymmetry in the stack.

ntpviz should help you see that.


> > If your offset is really 442 milli Sec than that is a really bad
> > time1.  
> 
> I can see on the scope that the serial stream starts around 350 ms
> after the pps, but can't get a good clean mark because it apparently
> varies based on the time to process the number of satellites in view.
> The vendor manual says it starts 'several hundered ms ...', so it
> appears to be expected behavior.

Once again, you do not want the NMEA offset set correctly, you want it
set WRONG!  ntpviz will rivially calculate for you the optimum
offset, then use something very different.


> As I said in the conf comments,
> experimentation shows that adding 370ms to the sentence time results
> in +/- 50ms offset from the pps mark over the course of the
> observations.

And as I said in previous emails, that means NOT to use 370!  Use something
very wrong, like 500.

> In any case, as I said earlier the 4.2.8p9 nmea driver in pps enable
> mode compensates for that, so the offset is: --- ZDA standard
> includes timezone offset fields not sent by sirf3, and number of
> characters may vary by offset ---     the printed char length here is
> always 33 # Time2 -- end of ZDA incl chksum/crlf:   35 char
> @4800bps(480cps) 0.072916667

You think it compensates, but it does so badly.

> > Where is your 3rd chimer?  Having just 2 is bad.  
> 
> I normally run with 3 internal and 2 different external's on each.
> For the purposes of focus here,

And then you wonder why you don't get the results you have before?
Just change on thing during testing!

> > Not useful until you say how long it has been running.  
> 
> That was just the first sample from a truncated list, simply to show
> that the ppspai is 'functional' even if it is only tracking the
> leading edge. 

I know what you did and why, don't do that!

> The fact that gpsd can't find it is most likely
> explained by the "non-linux" code blocks.

As I has told you in previsou emails, the missing KPPS is game over.

Fix that or give up now.

> > 
> > really better if you present an ntpviz URL.  
> 
> Haven't been able to run ntpviz yet. It is only installed on the BBB
> system without gnuplot.

No one says ntpviz has to run on the BBB.  Few do, they run it
remotely.

> > > Starting gpsd -D 5 shows :::  
> > 
> > Whoa!  Huge red flag!
> > 
> > Mar  4 16:52:22 tic gpsd[31863]: gpsd:WARN: KPPS:/dev/pps0 kernel
> > PPS unavailable, PPS accuracy will suffer
> > 
> > No point continuing until that is fixed.  
> 
> It is not clear if that is because /dev/gps0 device does not have a
> corresponding pps (because the code appears to assume that the pps
> will be on the control lines of a /dev/gpsN device), or if it was
> from the explicit second entry of /dev/pps0 timing out its serial
> stream.

Makes no difference.

> > NTPsec runs on way more than FreeBSD, and Linux.  And even on Linux
> > the ntp.conf file has at least 10 different locations that I can
> > name off the top of my head.  And no preferred order of searching!
> > For example Gentoo supplies a large number configs in a config
> > directory and starts ntpd using one that matches the local
> > configuration.  
> 
> Prior to linux emerging and splitting / moving the file(s) all over
> the place, the "most likely" place was /etc/rc.conf. Standards being
> what they are, even that was not always true. Unfortunately the
> FreeBSD team has recently been infected by the concept that 1000's of
> files in random places is better than a concise sequential file.

And now you have perfectly described why we can never assume which ntp.conf
is being used.

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: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/bugs/attachments/20170307/d9ce50cd/attachment.bin>