[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