Something I noticed while recompiling NTP 4.2.6p3: $ ./configure --enable-linuxcaps --enable-debugging --enable-all-clocks --enable-parse-clocks | grep -i pps checking timepps.h usability... no checking timepps.h presence... no checking for timepps.h... no checking sys/ppsclock.h usability... no checking sys/ppsclock.h presence... no checking for sys/ppsclock.h... no checking sys/ppstime.h usability... no checking sys/ppstime.h presence... no checking for sys/ppstime.h... no checking for struct ppsclockev... no checking for the ppsclock streams module... no checking for TTY PPS ioctl TIOCGPPSEV... no checking for TTY PPS ioctl TIOCSPPS... no checking for TTY PPS ioctl CIOGETEV... no checking ATOM PPS interface... yes
I tried copying the header from ntpsrc/ports/winnt/include/timepps.h to /usr/include/timepps.h, but no dice. Do I just need to copy some more headers somewhere or does this mean I have to recompile the kernel? I am seeing "refclock_newpeer: clock type 22 invalid" even with the --enable-ATOM flag in the configure script. Ken On Tue, Aug 16, 2011 at 9:53 AM, Miroslav Lichvar <[email protected]> wrote: > On Tue, Aug 16, 2011 at 09:42:09AM -0500, Ken Link wrote: >> I wrote a script to compare the previous/current assert timestamp >> (ignoring the seconds), and this is what I get when NTP is *not* >> running: >> >> -.000004357 >> -.000007328 >> -.000008905 >> -.000007969 >> -.000007593 >> -.000009174 >> -.000006566 >> -.000008152 >> -.000007500 >> -.000006854 > > That looks good. > >> I tried setting flag3 to 0 but it didn't appear to make a difference. >> Also, I would have expected NTP to mark the clock as a PPS source with >> 'o', but when I let it sync it seems to stick with '*' instead: >> >> $ ntpq -p >> remote refid st t when poll reach delay offset >> jitter >> ============================================================================== >> LOCAL(0) .LOCL. 12 l 232 64 10 0.000 0.000 >> 0.002 >> *GPS_NMEA(0) .GPS. 0 l 7 16 377 0.000 20.012 >> 26.423 > > It seems the GPS driver is not getting or is ignoring the PPS signal. > I think there were some issues fixed recently in it. I'd try the ATOM > driver (22) first to verify ntpd was compiled with PPS support and is > able to use it. > > -- > Miroslav Lichvar > _______________________________________________ > questions mailing list > [email protected] > http://lists.ntp.org/listinfo/questions > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
