nmea refclock not locking to the pps

Gary E. Miller gem at rellim.com
Fri Mar 10 20:42:45 UTC 2017


Yo Tony!

On Fri, 10 Mar 2017 12:32:59 -0800
"Tony Hain" <tony at tndh.net> wrote:

> > 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.

No they are not.  Both are using the same basic method to read the SHM.

It may have something to do with your measurement technique.  ntpshmmon
show every clock tick, but with your high poll the refclock driver is
dowing a lot of averaging.

> > > 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.

You ahve not shown how they do not show.

> Since the ntp SHM driver is significantly older than
> ntpshmmon, I assume its interpretation is definitive, but something
> is amiss.

SHM has been around a LONG time, the people that ode it are in solid
agreement on how it works.  if you want us to look at it you
have to show us something.

> > 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.  ;)

We always want you to trust ntpsec.  But you also have to give
ntpsec good inputs and know what it is telling you.

> General asymmetry problem I am not going to take on. Getting the
> FreeBSD-12 arm stack fixed will be enough trouble.

And the few FreeBSD users will be happy you did.  We'll be happy to
tack patches, on the gpsd-dev list.


> 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.

Which is why you want the GPS.  If you have a GPS on both ends you can
get the RasPi sysclock to agree ot better than 1 microsec.  I have heard
similar results can be had on a BBB.

> NTP assumes symmetry, so it will always report an offset in
> that case.

Which is why it has options for you to override that when you
know the assymetry.

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/20170310/9184bfaa/attachment.bin>


More information about the bugs mailing list