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

Bug #805661 reported by Hal Engel on 2011-07-04
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released
ntp (Ubuntu)

Bug Description

It appears that ntp does not have reference clock support built in. As a result I can not run NTP with my Oncore reference clock. PPS support is built into the kernel and I was able to configure PPS support and the related sym links. But NTP fail whwn I try to start it with a message that it can't find the time server with the address of the reference clock.

The hardware has been tested and this same setup is working on the same machine running Gentoo.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: ntp 1:4.2.6.p2+dfsg-1ubuntu5
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic
Uname: Linux 2.6.38-8-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Mon Jul 4 12:48:19 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
NtpStatus: No association ID's returned
ProcVersionSignature_: Ubuntu 2.6.38-8.42-generic
SourcePackage: ntp
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.ntp.conf: 2011-07-04T12:10:46.600562

Hal Engel (hvengel-h) wrote :
Hal Engel (hvengel-h) wrote :

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:


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 interface -> 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.

Jamie Strandboge (jdstrand) wrote :

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

  /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

Jamie Strandboge (jdstrand) wrote :

Please report back if this fixes the issue for you.

Changed in ntp (Ubuntu):
status: New → Incomplete
Hal Engel (hvengel-h) wrote :

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]: interface -> (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


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.

Hal Engel (hvengel-h) wrote :
Download full text (6.0 KiB)

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


Hal Engel (hvengel-h) wrote :

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


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
> #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 */
< #endif /* _SYS_TIMEPPS_H_ */
> #endif /* PPS_KC_BIND */
> #endif /* _SYS_TIMEPPS_H_ */

Launchpad Janitor (janitor) wrote :

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

Changed in ntp (Ubuntu):
status: Incomplete → Expired
Hal Engel (hvengel-h) wrote :

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?

Hal Engel (hvengel-h) wrote :

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

Changed in ntp (Ubuntu):
status: Expired → New
C de-Avillez (hggdh2) wrote :

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.

Changed in ntp (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Kenyon Ralph (kralph) wrote :

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:

Maarten Bezemer (veger) wrote :

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 I've added the bug watch for this bug report.

Changed in ntp:
status: Unknown → New
Changed in ntp:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.