Forwarding to see if removing base64 encoding affects propagation. On 2011-11-03, Dave Hart <[email protected]> wrote: > 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
