[LinuxPPS] NTP Build Errors fixed(?), ATOM issues persisting.
Hal V. Engel
hvengel at astound.net
Tue Aug 18 19:33:17 CEST 2009
On Tuesday 18 August 2009 01:17:48 am K. Connolly wrote:
> Dear all,
>
> As documented in my previous thread(July 22nd,2009) I've been running into
> a lot of problems enabling the ATOM PPS ref clock. One of the issues I ran
> into, not entirely related to the PPS setup, was that NTP would not build
> with the LinuxPPS header files as described in the wiki
> (http://wiki.enneenne.com/index.php/LinuxPPS_installation#Header_files).
> An apparent fix has been made, so I would like to document the issues I
> had and the solution and ask for feedback -- I'll try to be concise to
> spare a lengthy post, please feel free to ask for more details.
>
> The Warning/Error: Configuring NTP (stable release) gives warnings like:
>
> configure: WARNING: sys/capability.h: present but cannot be compiled
> configure: WARNING: sys/capability.h: check for missing prerequisite
> headers?
I don't see anything like this on my system. This is related to glibc (or
what ever libc you are using).
>
> Similar warnings occur for "linux/serial.h" Attemping to build results in
> errors of this kind:
>
> "error: expected specifier-qualifier-list before __le32"
My linux/serial.h does not have a reference to __le32 in it.
>
> Three files were edited to fix these warnings/errors: include/serial.h,
> include/capability.h, and ntp-version/ntpd/ntpd.c
>
> In serial.h, this change was made:
>
> #include <linux/types.h> <---- This line moved above of #ifdef __KERNEL__
> #ifdef __KERNEL__
> #include <asm/page.h>
>
> In capability.h, these changes were made:
>
> typedef struct __user_cap_header_struct {
> __u32 version;
> int pid;
> /*} __user *cap_user_header_t;*/ <-- comment out, apparent bug?
> } *cap_user_header_t;
>
> typedef struct __user_cap_data_struct {
> __u32 effective;
> __u32 permitted;
> __u32 inheritable;
> /*} __user *cap_user_data_t;*/ <-- same.
> } *cap_user_data_t;
>
>
> In ntpd.c, this line was added:
>
> #ifdef HAVE_LINUX_CAPABILITIES
> # include <linux/types.h> <--- This line added.
> # include <sys/capability.h>
> # include <sys/prctl.h>
>
> *********
None of these changes should be necessary. These are the result of messed up
libc and/or kernel headers. Looks like a distro issue to me. Either your
stuff is too old or too new or has screwball patches.
>
> Those modifications may be very sloppy or backwards (help?) but they seem
> to do the trick. NTP compiles fine and things seem to work.
>
> My problem of having the ATOM clock never get polled is still present.
> I've switched hardware from an old compute to a new computer and behavior
> is the same. I've lengthened my PPS pulse to 100ms, I've got the patched
> timex.h file, I've verified the signal with a scope and with ppstest, I've
> compiled (various) versions of NTP (now using the above fixes) with the
> LinuxPPS header files and all logs seem legit. I have a few clues/hopes to
> pursue now, so here goes the final summary of remaining questions:
>
> Before making the above changes, I'd compile NTP with the old kernel
> header files and I'd get messages like this in my ntp log:
>
> clock PPS(0) event 'clk_noreply' (0x01)
> peer PPS(0) event 'event_peer_clock' (0x85) status 'unreach, conf, 1 event,
> event_peer_clock' (0x8015)
>
> Those messages are now gone, but now, in the system messages log I get:
>
> refclock_atom: time_pps_kcbind failed: Operation not supported
Not an issue. This error is issued if the kernel does not have support for
hard PPS. Hard PPS is optional and is not required for ntp to use the PPS.
>
> This message is similar to the NMEA message mentioned in the FAQ, and I
> assume it is not an issue. The remaining bit of informatin is that, as
> commented on before, the ATOM driver is apparently rather touchy as to
> when it will be used, and my ntptime results seem to show large maximum
> error and estimated error (which may be inhibiting the ATOM clock?).
> William Brasher posted his results of a working ATOM driver here
> (http://ml.enneenne.com/pipermail/linuxpps/2009-July/003197.html), for
> comparison, and my results are:
>
> ntp_gettime() returns code 0 (OK)
> time ce34de6d.5df66600 Tue, Aug 18 2009 17:01:49.367, (.367041977),
> maximum error 294964 us, estimated error 361 us, TAI offset 0
> ntp_adjtime() returns code 0 (OK)
> modes 0x0 (),
> offset 479.607 us, frequency -86.397 ppm, interval 1 s,
> maximum error 294964 us, estimated error 361 us,
> status 0x2001 (PLL,NANO),
> time constant 8, precision 0.001 us, tolerance 500 ppm,
>
>
> What does an inactive ATOM PPS source look like? Should it be getting
> polled but being listed as an outlyer, or should it not even be active,
> and listed as rejected in the associations? ntpq and associations below:
>
> # ntpq/ntpq -c rv -p
> assID=0 status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg,
> version="ntpd 4.2.4p7 at 1.1607-o Tue Aug 18 05:13:30 UTC 2009 (1)",
> processor="i686", system="Linux/2.6.28-rc6-NO_KTIMER2", leap=00,
> stratum=2, precision=-20, rootdelay=62.652, rootdispersion=16.681,
> peer=2127, refid=115.139.9.150,
> reftime=ce34de97.c3266950 Tue, Aug 18 2009 17:02:31.762, poll=8,
> clock=ce34e08e.c266b31f Tue, Aug 18 2009 17:10:54.759, state=4,
> offset=0.766, frequency=-86.395, jitter=1.329, noise=0.348,
> stability=0.004, tai=0
> remote refid st t when poll reach delay offset
> jitter
>
===========================================================================
>=== +kanda.likk.net 133.100.9.2 2 u 241 256 377 21.615 -0.168
> 0.501 -arisa.attrition 133.100.9.2 2 u 129 256 377 26.019
> 18.646 7.804 +suisho.attritio 195.58.160.5 3 u 125 256 377
> 26.719 4.362 9.720 -81.91.129.95 192.43.244.18 2 u 243 256
> 177 424.681 11.217 0.456 -61.153.197.226 216.218.192.202 2 u 121
> 256 377 442.843 85.978 2.252 *115.139.9.150 .GPS. 1 u
> 246 256 377 62.652 0.563 0.921 -114.80.81.1 216.218.192.202 2
> u 121 256 357 341.595 15.206 3.402 -121.122.129.99 128.250.36.2
> 2 u 244 256 377 272.932 -78.949 8.722 PPS(0) .PPS.
> 0 l - 64 0 0.000 0.000 0.001
>
>
> # ntpq/ntpq -c as
>
> ind assID status conf reach auth condition last_event cnt
> ===========================================================
> 1 2122 9414 yes yes none candidat reachable 1
> 2 2123 9314 yes yes none outlyer reachable 1
> 3 2124 9414 yes yes none candidat reachable 1
> 4 2125 9314 yes yes none outlyer reachable 1
> 5 2126 9314 yes yes none outlyer reachable 1
> 6 2127 9614 yes yes none sys.peer reachable 1
> 7 2128 9314 yes yes none outlyer reachable 1
> 8 2129 9314 yes yes none outlyer reachable 1
> 9 2130 8000 yes yes none reject
>
>
>
> OK, that's all for now.
>
> Cheers,
>
> -Kevin
My experience with the Atom driver when I was having trouble getting it
working is that it was reachable but was listed as an outlyer. So it appears
that the issues I was seeing with this driver are different from what you are
seeing. "ntpq/ntpq -c as" says the clock is reachable (reach=yes) but "ntpq
-p" says the reach is 0. Seems like a contradiction. Have you tried ntpq -c
"rv <assID of the atom clock>"? this should give you more info about the Atom
device and perhaps that will help you locate the cause of the issue.
But status=8000 probably will likely give a result like:
status=8000 unreach, conf, no events
which says that the clock is unreachable.
I also agree that this appears to be ntp and/or libc related.
Hal
More information about the LinuxPPS
mailing list