Re: ntpd stratum 1 funny offset with NetBSD 6 branch

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

Hi Simon  !

Two observations:
NetBSD 5 has 4.2.4p6.

NetBSD 6+current have 4.2.6p5.

Also note that the PPS samples seems to be ~two seconds apart and there is
also a difference of ~2 seconds between now and the asser time stamp.
The ATOM driver should be just using the difference between the fictive
integral second and the time stamp. So from the data given ATOM's behavior
looks strange here. Even more so as the other peers seem to indicate 
basically
good synchronization.

Further step:
Verify that PPS is picked up correctly:
    - go to /src/external/bsd/ntp/dist/util and make pps-api
    - call pps-api with your PPS device

If all is well (NetBSD 6.99.20) you should see something like this:
1374221788.000029243 1374221788.200063352 267915 267916 0.200034109
1374221789.000023787 1374221788.200063352 267916 267916 -0.799960435
1374221789.000023787 1374221789.200024162 267916 267917 0.200000375
1374221790.000023219 1374221789.200024162 267917 267917 -0.799999057
This is a GPS receiver with a 200ms PPS pulse. The 23usec offset comes from
the RS232 external status interrupt path.

Another driver of mine reads high resolution time stamps (100ns) via 
PCIe and feeds that
as PPS time stamps (only the asserts are used) and gives this result:
1374222460.999998308 0.000000000 267996 0 -1374222460.999998331
1374222461.999998197 0.000000000 267997 0 -1374222461.999998093
1374222462.999998197 0.000000000 267998 0 -1374222462.999998093
1374222463.999999030 0.000000000 267999 0 -1374222463.999999046
1374222465.000000365 0.000000000 268000 0 -1374222465.000000477
1374222465.999999209 0.000000000 268001 0 -1374222465.999999285
1374222466.999998552 0.000000000 268002 0 -1374222466.999998569

The machine is currently doing bulk builds (thus 'big' load changes wrt/ 
clock
oscillators).

So you must be seeing PPS information ~1 second apart. For some time
I have the suspicion the the CD interrupt is not always correctly picked up,
but I have not been able to prove that as the issues went away on ntpd
restart.

Frank

On 07/19/13 06:30, Simon Burge wrote:
> Hi folks,
>
> Is anyone happily running a stratum 1 NTP server with a GPS with a PPS
> signal on NetBSD 6?
>
> I've got a Garmin GPS18x on a Soekris net4801 where the GPS clock has
> a funny offset.  Here's the output from "ntpq -pn":
>
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>   127.127.20.0    .PPS.            0 l   14   16   17    0.000  -658.75   6.388
>   192.168.0.1     27.50.90.253     3 u   11   64    3    0.348   -0.594   0.166
>   192.168.0.42    192.168.0.1      4 u   10   64    3    0.345    5.670   0.200
>   202.191.108.73  47.187.174.51    2 u    8   64    3   30.141   -2.695   0.401
>   59.167.170.228  203.35.83.242    2 u   11   64    3   55.362   -1.997   1.068
>   27.50.90.253    202.46.181.123   2 u    8   64    3   36.167    0.108   0.162
>
>
> The GPS clock offset appears to be reasonably random (but seems to like
> between -800 and -600 more often than not), but is then pretty much
> constant for each ntpd invocation.
>
>
> I've thrown some debugging in ntpd, and the offset is very suspiciously
> close to the time the PPS info was read from the kernel (the "now") and
> not the time of the PPS timestamp (the "assert ts"):
>
> time_pps_fetch: now = 1374192482.658097  assert ts = 1374192480.999648384
> time_pps_fetch: now = 1374192484.675356  assert ts = 1374192482.990470645
> time_pps_fetch: now = 1374192486.656708  assert ts = 1374192484.990341144
> time_pps_fetch: now = 1374192488.659388  assert ts = 1374192487.005927355
>
>
> My ntp.conf has this:
>
>         server  127.127.20.0    mode 1          minpoll 4       maxpoll 4
>         fudge   127.127.20.0    flag1 1         flag3 1         refid PPS
>
> I've tried various modes to select different NMEA sentences without any
> effect, and having flag3 (use kernel pps) set to 0 also has no effect.
>
>
> With a NetBSD 5 userland and kernel, all is much happier:
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *127.127.20.0    .PPS.            0 l   13   16  377    0.000    0.002   0.004
> -192.168.0.42    192.168.0.1      4 u   53   64   77    0.371   -7.618   0.924
> -192.168.0.1     27.50.90.253     3 u   48   64   77    0.379   -6.047   1.768
> -54.252.129.186  149.20.64.28     2 u   38   64   77   33.982   -9.149   1.730
> +202.125.45.77   223.252.32.9     2 u   40   64   77   47.374   -2.040   1.800
> -202.191.108.72  47.187.174.51    2 u   42   64   77   29.762   -8.068   1.379
>
>
> I've also tried the netbsd-5 version of ntp on netbsd-6, and that has the
> same offset problem as native ntpd.
>
> The PPS bits of the com driver and inside sys/kern don't appear to be
> different in any obvious way.  I'm about to start looking at the 64-bit
> time_t change.
>
> Anyone have any ideas or suggestions?
>
> Cheers,
> Simon.