On Thu, Nov 3, 2011 at 01:16, jimmyterrence <[email protected]> wrote: > It only ever notices the NMEA output in ntp, and I can tell that > because the jitter is always terrible: > > remote refid st t when poll reach delay offset jitter > ======================================== > *GPS_NMEA(0) .GPS. 0 l 7 16 377 0.000 23.791 16.842 > > It doesn't seem to matter how long I let ntp run, it never seems to > see the PPS signal. > > Right now, my ntp.conf entry is the following: > > server 127.127.20.0 minpoll 4 maxpoll 4 mode 0 prefer > fudge 127.127.20.0 flag1 1 flag2 0 time2 0.600 > > I've tried ntp-4.2.6.p3 (came with Debian Wheezy) 4.2.6p4 and 4.2.6p5- > RC1 from ntp.org > > What do I need to do to get ntp to notice the PPS signal? What am I > missing?
My guess is your ntpd binaries were built without PPSAPI support, because (or the builder in the case of the stock one) you don't have timepps.h available where ntpd can find it. You can verify that for the 4.2.6p5-RC1 you built by searching for PPS in its config.h: /* Do we have the PPS API per the Draft RFC? */ #define HAVE_PPSAPI 1 #define HAVE_SYS_TIMEPPS_H 1 /* #undef HAVE_TIMEPPS_H */ If you see /* #undef HAVE_PPSAPI */ you need to either pick up timepps.h by hand somewhere, or possibly update your libc. Linux has a strange convention of distributing kernel-dependent headers in libc, so building a kernel with PPSAPI support doesn't necessarily imply you have the right headers to match. If you do see HAVE_PPSAPI defined, check your syslog for messages from ntpd including the text "time_pps". Good luck, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
