nmea refclock not locking to the pps

Tony Hain tony at tndh.net
Fri Mar 10 20:32:59 UTC 2017


Gary E. Miller wrote:

> Yo Tony!
> 
> On Fri, 10 Mar 2017 10:54:55 -0800
> "Tony Hain" <tony at tndh.net> wrote:
> 
> > Gary E. Miller wrote:
> > > Yo Tony!
> > >
> > > I'm baffled, I have been running gpsd on IPv6 hosts for almost a
> > > decade, and I have never had to ask for the ipv6 option.
> > >
> > > Can you dig into this some more?  Something else is going on.
> >
> > IPv6 is default-on, UNLESS you follow the instructions at
> > http://www.catb.org/gpsd/gpsd-time-service-howto.html
> > because as soon as you say  timeservice=yes  SConstruct stops building
> > it (and the clients) as shown in the script block I pasted in below.
> 
> I passed that on the Eric, the author of the timeservice option.  He confirmed
> what you saw.  Which I think is a bad thing.
> 
> I'll beat on him to fix that.  He went overboard on minimalism.

Understandable, just took awhile to find it.

> 
> > > Also, you are mixing gpsd problems, which belong on the gpsd list.
> > > And ntpsec problems which belong here.  Can you split off you gpsd
> > > comment and send that to gpsd-users?
> >
> > I thought about that, but we got here because you wanted me to run
> > gpsd instead of nmea.
> 
> Well, that was before you told me you were on FreeBSD.  But once you are
> on gpsd, that becomes a gpsd problem.  So belongs on there list where their
> maintainters see it.
> 
> The gpsd people knew there were issues with PPS on FreeBSD.  I hope you
> submit your patches to them so progress can be made on them.
> 
> > I
> > know people use it, but if the interface is not as crisply defined as
> > people think it is,
> 
> We can't change it, too many projects use it.  And it makes sense to me, but I
> am too close to it.  If you have any doc suggestions send them on.

Haven't looked at the spec, just questioning it since ntpshmmon shows activity while ntpsec & 4.2.8p9 SHM drivers do not see the pps events. Clearly they are looking at different things.

> 
> > there may be an oversight which allows ntpshmmon to show events while
> > the ntpsec SHM driver fails.
> 
> I know of no such thing.  Details?

> > # ntpshmmon
> > ntpshmmon version 1
> > #      Name Seen@                Clock
> > Real                 L Prec 
> > sample NTP0 1489124430.611470658 1489124430.412209171
> > 1489124430.000000000 0 -20
> > sample NTP2 1489124430.611553695 1489124428.000033371
> > 1489124428.000000000 0 -30
> > sample NTP0 1489124431.412239685 1489124431.411282520
> > 1489124431.000000000 0 -20
> > sample NTP2 1489124432.001544155 1489124432.000033265
> > 1489124432.000000000 0 -30
> > sample NTP0 1489124432.415040281 1489124432.413955830
> > 1489124432.000000000 0 -20
> > sample NTP2 1489124433.002155059 1489124433.000033281
> > 1489124433.000000000 0 -30
> > sample NTP0 1489124433.411896022 1489124433.411793694
> > 1489124433.000000000 0 -20
> > sample NTP2 1489124434.002308776 1489124434.000033212
> > 1489124434.000000000 0 -30
> > 

Shows pps events, but both the ntpsec & 4.2.8p9 SHM drivers do not see them. Since the ntp SHM driver is significantly older than ntpshmmon, I assume its interpretation is definitive, but something is amiss.

> 
> > I can resend that under a different subject if that is necessary.
> 
> Please do, best to have on bug per thread.
> 
> > At this point I believe my original issue with the offset is more
> > readily explained by an asymmetry in the stack. OWAMP
> > (http://software.internet2.edu/owamp/) shows a consistent difference
> > in ping times between systems on the same switch, or 1-2 local router
> > hops away in packets originating from vs. echo'd by the FreeBSD-12
> > stack.
> 
> Which is pretty much what I was trying to tell you.  Easily seen with ntpviz.
> Fix your prefers and that goes away.  Yu got a local GPS, make sure it is being
> used as primary time source.

I was not sure I could trust it since the only 2 ntpsec instances I have are both reporting offsets from the rest of the world. Since those are both on FreeBSD-12 arm, and OWAMP shows an asymmetry in that stack, it is easier to trust ntpsec.  ;)

> 
> > That indicates the original concern is not likely to be an ntpsec
> > issue, though there were still differences between it and
> > 4.2.8p9 which I will get back to if the asymmetry can be resolved.
> 
> If you figure out a solution a ton of people would be interested.  That has
> been bothering people a long time, and the reason why local GPS are so
> popular.
> 

General asymmetry problem I am not going to take on. Getting the FreeBSD-12 arm stack fixed will be enough trouble. There is a catch-22 issue here because OWAMP requires "accurate ntp", which you can't get if the stack is not symmetric, so the tool is operating outside its design point to demonstrate the stack problem. The best I can do is show that echo's originating on the FreeBSD-12 arm side consistently take 200us longer than those originating from the other side. NTP assumes symmetry, so it will always report an offset in that case.

Tony






More information about the bugs mailing list