nmea refclock not locking to the pps

[Tony Hain]

Gary E. Miller wrote:
> Yo Hal!
> 
> On Sat, 11 Mar 2017 09:19:39 -0800
> Hal Murray <hmurray at megapathdsl.net> wrote:
> 
> > >> 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.
> >
> > I don't know of any mechanism to compensate for asymmetry on the
> > network.

There is bandwidth asymmetry, and topology asymmetry that can create even greater offsets. 

> 
> Hmm, I thought you could put a fudge on a server, but I can't see how.

I believe the presumption is that you can't know the variations in network topology over any length of time, so you can't determine an applicable offset. Local refclock's are generally fixed configurations, so managing known delays is appropriate.

> 
> That should get added.  My internet conenction is symmetric, but a friend of
> mine just tested his link: 19Mbps down, 0.9 Mbps up.  That has to add serious
> asymmetry.

Depends on traffic-load/queue-depth as well as bit rate. With no other traffic that would result in ~50us down, ~1ms up. That should result in all 'servers' showing ~425us offset from a gps derived pps. At this point it is not clear to me of 'peers' are able to mitigate that offset by sharing their views of each other, but 10 years ago I thought that was part of the difference between server and peer. Would have to go digging to see what really happens.

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