[ntp:questions] ntpd connect gpsd shared memory driver

Rob nomail at example.com
Tue Jun 18 18:30:03 UTC 2013


Richard Cagley <rcagley at gmail.com> wrote:
> On Tue, Jun 18, 2013 at 10:16 AM, Rob <nomail at example.com> wrote:
>
>> It now locks to the serial data but not yet to the PPS.
>> What happens when you add some external timeserver(s)?
>> Are you within a fraction of a second from those?
>>
>
> after about 5min...
> / # ntpq -p
>      remote           refid      st t when poll reach   delay   offset
>  jitter
> ==============================================================================
> *SHM(0)          .GPS.            0 l    4   16  377    0.000   11.086
> 0.992
>  SHM(1)          .GPS1.           0 l    -   16    0    0.000    0.000
> 0.000
> +clock1.redhat.c .CDMA.           1 u   12   64   37   79.170  -169.23
> 3.578
> -a1.hotfile.com  209.51.161.238   2 u    7   64   37   59.899  -172.68
> 3.375
> +200.140.8.72.in 64.147.116.229   2 u   11   64   37    7.124  -170.26
> 1.946
> -ec2-50-16-231-1 209.51.161.238   2 u   11   64   37   72.309  -172.73
> 1.987
> -nbg1.shellvator 209.51.161.238   2 u    7   64   37   74.942  -173.58
> 7.111
>
> It's not very close I suppose. Maybe I just need to be patient? Unclear me
> how close the time needs to be for pps to "kick in"

This is close enough.
There are problems when it is off by more than 400ms.
gpsd gets the serial data and the pulses, and it has to correlate the
pulses with the correct absolute timestamp.  This cannot be done reliably
when the reception of the absolute timestamp is too far of the correct
time (the PPS could pull the clock to the next second).  However, this
is not happening here.



More information about the questions mailing list