Richard Cagley <[email protected]> wrote: > On Tue, Jun 18, 2013 at 10:16 AM, Rob <[email protected]> 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. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
