[ntp:questions] ntpd connect gpsd shared memory driver
David Taylor
david-taylor at blueyonder.co.uk.invalid
Tue Jun 18 18:48:42 UTC 2013
On 18/06/2013 18:54, Richard Cagley wrote:
[]
> 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"
Progress!
Now you can take the average of the offset values, say -171
(milliseconds) in round numbers, and change the ntp.conf to read:
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.171 refid GPSD
This will make the serial data be approximately in sync with the
external servers. Ideally, average over a few minutes, but it doesn't
need to be that exact unless you will have no PPS signal.
I just did the same on my Raspberry Pi test server:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#user-mode
How are you feeding the PPS data into the system?
--
Cheers,
David
Web: http://www.satsignal.eu
More information about the questions
mailing list