NO reference clock support. I need Oncore ref clock support in ntp.

I tried to hand build ntp with pps and reference clock support. from the configure I see that it is looking for the following header files:

sys/pptime.sys
sys/ppsclock.h
timepps.h

Checking my Gentoo installation I see that only the last header is installed. I copied the timepps.h header to /usr/include/ and at that point the ntp build configuration will configure the build for the oncore ref clock. I now get teh following erros in the log:

can't open /var/log/ntpstats/clockstats: Permission denied
refclock_open /dev/serial.0: Permission denied
127.127.20.0 interface 127.0.0.1 -> none

So it is failing to create a clockstats file because of permissions. What do I need to do to get this working?

Also my udev rules for the PPS/GPS stuff looks like this:

KERNEL=="ttyS1", RUN+="/bin/setserial -v /dev/%k low_latency", SYMLINK+="oncore.serial.0"

KERNEL=="pps0", OWNER="root", GROUP="uucp", MODE="0660", SYMLINK+="oncore.pps.0", OPTIONS+="last_rule"

What do I need to do in my udev rules to allow ntp to open the serial device?

Another issues that may be related to this. NTP will NOT build with NANOsecond support and this should be working on all kernels starting with 2.6.26. Not sure what is causing this but there is likely some type of issue with the kernel or glibc header files.

These lines indicate you need to update your AppArmor profile:
Jul 4 12:00:30 Office kernel: [ 1782.601471] type=1400 audit(1309806030.808:24): apparmor="DENIED" operation="mknod" parent=1 profile="/usr/sbin/ntpd" name="/var/log/ntp/ntp.log" pid=2520 comm="ntpd" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
Jul 4 12:03:34 Office kernel: [ 1965.794660] type=1400 audit(1309806214.006:25): apparmor="DENIED" operation="mknod" parent=1 profile="/usr/sbin/ntpd" name="/var/log/ntp/ntp.log" pid=2592 comm="ntpd" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

Add:
  /var/log/ntp/ntp.log rw,

To /etc/apparmor.d/usr.sbin.ntpd and then do:
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.ntpd

Please report back if this fixes the issue for you.

I added the following to /etc/apparmor.d/usr.sbin.ntpd

/var/log/ntp/ntp.log rw,
/var/log/ntpstats/clockstats rw,
/dev/oncore.serial.0 rw,
/dev/oncore.pps.0 r,

It will not create the log file in /var/log/ntp. But it will do it in /var/log even with the above changes. When I run ntp configured to create the log file in /var/log I get the following:

 6 Jul 13:44:06 ntpd[2220]: can't open /var/log/ntpstats/clockstats: Permission denied
 6 Jul 13:44:06 ntpd[2220]: can't open /var/log/ntpstats/clockstats: Permission denied
 6 Jul 13:44:06 ntpd[2220]: refclock_open /dev/oncore.serial.0: Permission denied
 6 Jul 13:44:06 ntpd[2220]: can't open /var/log/ntpstats/clockstats: Permission denied
 6 Jul 13:44:06 ntpd[2220]: 127.127.30.0 interface 127.0.0.1 -> (none)
 6 Jul 13:44:07 ntpd[2220]: running in unprivileged mode disables dynamic interface tracking

The PPS stuff is correctly configured and is running although I have not fully automated it's startup and am starting it by hand. Testing this with:

testpps /dev/pps0

or

testpps /dev/oncore.pps.0

I get the correct results showing that the PPS system is active and that the correct interrupts are being generated.

Also from past experience I know that running ntp in microsecond mode against a nanokernel will result in fairly poor timekeeping. With everything in NANO mode this setup should keep the clock synced to with in 2 microseconds of UTC worst case and most of the time it should maintain offsets that are less than 1 microsecond. But with ntp in micro mode and a nanokernel my experience has been that offsets will get as high as 100 microseconds and the clock will be unstable and poorly synced. This is not apparent when using Internet based time servers since time errors are typically 3 orders of magnitude greater than we expect to see with a local high precision reference clock (IE. milliseconds vs. microseconds) and jitter is also in the milliseconds range where I expect to see 1 microsecond jitter levels with this setup.

I made some more udev changes and I got the Oncore reference clock almost working. Here is what my PPS udev rules look like:

KERNEL=="ttyS1", RUN+="/bin/setserial -v /dev/%k low_latency", OWNER="ntp", GROUP="ntp", MODE="0660", SYMLINK+="oncore.serial.0"

KERNEL=="oncore.serial.0"OWNER="ntp", GROUP="ntp", MODE="0660"

KERNEL=="pps0", OWNER="ntp", GROUP="ntp", MODE="0660", SYMLINK+="oncore.pps.0"

KERNEL=="oncore.pps.0", OWNER="ntp", GROUP="ntp", OPTIONS+="last_rule"

-----------------------------------
NTP now starts and initializes the Oncore but I have not been able to get it to sync.

I am seeing the following in the clock stats file:

55749 72470.280 127.127.30.0 ONCORE[0]: ONCORE DRIVER -- CONFIGURING
55749 72470.280 127.127.30.0 ONCORE[0]: state = ONCORE_NO_IDEA
55749 72470.281 127.127.30.0 ONCORE[0]: Input mode = 1
55749 72470.281 127.127.30.0 ONCORE[0]: Initializing timing to Assert.
55749 72470.281 127.127.30.0 ONCORE[0]: SHMEM (size = 3628) is CONFIGURED and available as /var/log/ntp/oncore.0
55749 72470.281 127.127.30.0 ONCORE[0]: state = ONCORE_CHECK_ID
55749 72471.276 127.127.30.0 ONCORE[0]: Oncore: Resend @@Cj
55749 72471.738 127.127.30.0 ONCORE[0]: @@Cj
55749 72471.738 127.127.30.0 ONCORE[0]: COPYRIGHT 1991-1997 MOTOROLA INC.
55749 72471.738 127.127.30.0 ONCORE[0]: SFTW P/N # 98-P36848P
55749 72471.738 127.127.30.0 ONCORE[0]: SOFTWARE VER # 2
55749 72471.738 127.127.30.0 ONCORE[0]: SOFTWARE REV # 2
55749 72471.738 127.127.30.0 ONCORE[0]: SOFTWARE DATE APR 24 1998
55749 72471.738 127.127.30.0 ONCORE[0]: MODEL # R5122U1152
55749 72471.738 127.127.30.0 ONCORE[0]: HWDR P/N # 5
55749 72471.738 127.127.30.0 ONCORE[0]: SERIAL # R05UD5
55749 72471.738 127.127.30.0 ONCORE[0]: MANUFACTUR DATE 9E14
55749 72471.738 127.127.30.0 ONCORE[0]:
55749 72471.738 127.127.30.0 ONCORE[0]: This looks like an Oncore UT with version 2.2 firmware.
55749 72471.738 127.127.30.0 ONCORE[0]: Channels = 8, TRAIM = ON
55749 72471.738 127.127.30.0 ONCORE[0]: state = ONCORE_CHECK_CHAN
55749 72476.278 127.127.30.0 ONCORE[0]: Input says chan = -1
55749 72476.278 127.127.30.0 ONCORE[0]: Model # says chan = 8
55749 72476.278 127.127.30.0 ONCORE[0]: Testing says chan = 8
55749 72476.278 127.127.30.0 ONCORE[0]: Using chan = 8
55749 72476.278 127.127.30.0 ONCORE[0]: state = ONCORE_HAVE_CHAN
55749 72477.728 127.127.30.0 ONCORE[0]: state = ONCORE_TEST_SENT
55749 72484.988 127.127.30.0 ONCORE[0]: GPS antenna: OK
55749 72484.988 127.127.30.0 ONCORE[0]: state = ONCORE_INIT
55749 72487.276 127.127.30.0 ONCORE[0]: Oncore: Resend @@Cj
55749 72488.028 127.127.30.0 ONCORE[0]: Setting Posn from input data
55749 72488.028 127.127.30.0 ONCORE[0]: state = ONCORE_ALMANAC
55749 72496.148 127.127.30.0 ONCORE[0]: Posn:
55749 72496.148 127.127.30.0 ONCORE[0]: Lat = N 38.0000817deg, Long = W 122.0366131deg, Alt = -11.40m (-37.40ft) GPS
55749 72496.148 127.127.30.0 ONCORE[0]: Lat = N 38deg 0.0049m, Long = W 122deg 2.19678m, Alt = -11.40m ( -37.40ft) GPS
55749 72496.148 127.127.30.0 ONCORE[0]: Lat = N 38deg 0m 0.29s, Long = W 122deg 2m 11.81s, Alt = -11.40m ( -37.40ft) GPS...

Also the timepps.h file along with some user land pps related tools can be found here:

git://github.com/ago/pps-tools.git

The version there is somewhat outdated as it does not include support for the new kernel consumer that is part of 2.6.38. Here is a diff for a version that does work with the kernel consumer:

$ diff timepps.h /usr/include/timepps.h
188a189,205
> #ifdef PPS_KC_BIND
>
> static __inline int time_pps_kcbind(pps_handle_t handle,
> const int kernel_consumer,
> const int edge, const int tsformat)
> {
> struct pps_bind_args __bind_args;
>
> __bind_args.tsformat = tsformat;
> __bind_args.edge = edge;
> __bind_args.consumer = kernel_consumer;
>
> return ioctl(handle, PPS_KC_BIND, &__bind_args);
> }
>
> #else /* !PPS_KC_BIND */
>
198c215,217
< #endif /* _SYS_TIMEPPS_H_ */
---
> #endif /* PPS_KC_BIND */
>
> #endif /* _SYS_TIMEPPS_H_ */

[Expired for ntp (Ubuntu) because there has been no activity for 60 days.]

Not sure how a bug where the only person who has posted information is the OP can be closed without any response from the group that should be handling the report (IE. the group responsible for time keeping in this case). But for some reason in Ubuntu if the developers choose to not respond to a bug report the bug report is automatically closed by the system. I guess it makes for better bug stats.

There is a ton of info in this report about what the bug is and what errors are happening. This includes a time related system header file that is missing. But it appears that the devs don't care that a system header is missing. Anyone care to explain this?

How can a bug report that has not been responded to be automatically closed?

The bug was automatically expired because it was kept in status "incomplete" for 60 days. Of course, it should not have expired, and or course, it should not be "incomplete".

But it was left incomplete -- and automatic closure took place.

It is a pity that it is easier to blame the developers and maintainers than to try and find out what happened, though.

Marking triaged/Low.

It would be good to get Hal's suggested changes into Debian first, then they will flow into Ubuntu with no extra maintenance effort. Here is a Debian bug report for getting timepps.h included: http://bugs.debian.org/570233

Thanks for taking the time to find this bug in the upstream bug tracking system this is a tremendous help. Launchpad has the ability to watch lots of upstream bug trackers and this can be done by following the procedure documented at https://wiki.ubuntu.com/Bugs/Watches. I've added the bug watch for this bug report.

PPS support is enabled in NTP as released with Xenial, setting fix released.