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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
