Re: ntpd stratum 1 funny offset with NetBSD 6 branch

[Frank Kardel <kardel%netbsd.org@localhost>]

Hi Simon !

On 07/21/13 16:47, Simon Burge wrote:
> Frank Kardel wrote:
>
> > The NMEA driver has a section that checks the relation between
> > the time code and the PPS time stamps (refclock_ppsrelate).
> >
> > This code attempts to determine if the last PPS time stamp matches
> > the received timecode within bounds. This code is sensible to
> > time1 (pps offset) and time2 (end of line offset).
> > If the end of line offset (default 0) is far from the true end of line
> > offset
> > this code may come to the wrong conclusions.
> >
> > Maybe a short debugging session can help there - without more
> > information  analysis is a bit elaborate here.
> >
> > ntpd -d -d should shed some light on the actual
> > receive time stamps. These should be compensated by time2.
> >
> > I have not checked whether refclock_ppsrelate is correct.
> I'm not convinced that toying with time2 is the answer, as the offset
> past the second is relatively random.  Eg, 0.650 one time, 0.640 another
> and 0.625 another.  But I'll change my mind by the end of this email. :)
....
> Going back to time2 - is it just a case of "get it close enough that the
> PPS is valid and we'll use the PPS anyway"?  I'm still concerned that
> I don't see the same offset all the time so any value for time2 isn't
> going to be entirely accurate.
The time stamp needs to be in a reasonable range. GPS NMEA sentences are 
known to be
not terribly accurately timed (communication being the task with the 
lowest priority in a GPS engine).
That's why synchronizing on NMEA sentences only is usually  a futile 
mission. So  it just needs to be close enough,
> With "fudge time2 -0.650" I get:
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>   127.127.20.0    .PPS.            0 l   11   16  377    0.000  -1000.0   0.017
> +192.168.0.1     27.50.90.253     3 u   30   64  177    0.491   -1.617   0.059
>   192.168.0.42    192.168.0.1      4 u   28   64  177    0.463   -4.895   0.096
>   128.184.218.53  169.254.0.1      3 u   28   64  177   22.199   -2.344   2.684
> *116.66.160.39   130.234.255.83   2 u   32   64  177   18.926   -0.821  33.310
>   202.127.210.37  118.143.17.82    2 u   32   64  177   20.045   -0.473  30.881
>
> so we went the wrong way, but with "fudge time2 0.650" I get:
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>   127.127.20.0    .PPS.            0 l    7   16  377    0.000   -0.033   0.009
> -192.168.0.1     27.50.90.253     3 u    7   64  377    0.452   -1.649   0.072
> -192.168.0.42    192.168.0.1      4 u    9   64  377    0.461   -4.633   0.145
> +202.191.108.73  47.187.174.51    2 u   12   64  377   26.623   -2.724   5.725
> +202.60.94.15    116.66.160.39    3 u    4   64  377   40.921   -4.530  22.255
> *27.54.95.11     218.100.43.70    2 u    5   64  377   53.308   -4.057  25.255
>
> Aha - we at last seem to be on a winner!
>
> I'll let it run overnight, but things are finally looking sane.
>
> Cheers,
> Simon.
> --
>
> ...
Hope it remains stable - so far it behaves as expected (from 
documentation and code) :-)

Frank