Advanced ntp setup - using a local reference clock

English Install/Boot/Login
#1

First some background. I am helping someone, who is a SuSE user, to install a local GPS reference clock. Since this person asked for my help I built a reference clock using an ebay purchased Motorola Oncore UT+ GPS receiver and tested it on my own workstation. I gave him the reference clock as a present and it is now attached to his machine.

I normally use another distro so I would like some advice on setting up the SuSE machine the “SuSE way” so that the user can maintain the setup in a correct way. Also since the “SuSE way” creates RPMs it should be possible to make these RPMs available so that other 11.1 users can also install reference clocks.

The machine is running SuSE 11.1. So far he has patched the stock kernel with the LinuxPPS patches and built and installed the new PPS kernel using a HOWTO for doing this the SuSE way. Doing it this way created both source and arch specific RPMs for the new PPS kernel. The new kernel has been tested (IE. it is seeing the PPS pulses from the GPS) and it appears to be stable with everything working the way it should. The only change from the stock kernel is the PPS patches and the PPS specific configuration items.

After getting the PPS kernel installed and tested we looked at the YAST configuration stuff for NTP. It has stuff to configure the supported reference clocks which includes the Oncore series GPS’s so I though great this should not be too difficult since on the surface it appears that SuSE 11.1 is mostly ready to go for installing a reference clock. However the YAST reference clock configuration stuff does not work and it appears that this part of YAST is still “a work in progress” since it does not do stuff that is required to make a reference clock work. For the Oncore the missing things include:

  1. It does not create the /etc/ntp.oncore.<0…9> configuration files for the Oncore and has no way to set or change the configuration items in these file(s).

  2. It only allows setting up one symlink for the hardware but for most reference clocks two symlinks are needed to make the refclock driver work. One for the PPS device and one for the device that is used to talk to and get time information from the reference clock (normally a serial port).

  3. It does not have a way to setup pps line discipline.

OK once I figured out that it was not possible to configure the reference clock using YAST I hand configured it by creating /etc/ntp.oncore.0 with the needed settings including setting up a SHMEM file and hand tweaking /etc/ntp.conf to do things like create a clockstats file.

Bumping NTP after doing this was not satisfying. At no point did ntp try to create the clockstats file and it never creates a SHMEM file. These are both things that should happen when NTP starts if it is correctly configured and built to use reference clocks. It appears that the NTP package shipped with SuSE 11.1 was not built with reference clock support and it simply ignores the

server 127.127.30.0 prefer

line in /etc/ntp.conf since the driver for this device is not available. But it also fails silently and issues no error messages. One of the reasons to create the clockstats file is to get more information from ntp about what is happening.

There are also other issues related to this. Starting with kernel version 2.6.26 Linux went from being a micro second kernel to being a nano second kernel. The main issue is that glibc is still using time related declarations that date from the linux 2.2 era that are no longer correct for these newer versions of the kernel. There are patch sets to bring glibc into sync with these newer kernels and these need to be applied and installed before building ntp otherwise ntp and the kernel will not work well together.

So there are two main areas of concern.

  1. What is the “SuSE way” of building and installing a patched version of glibc?

  2. What is the “SuSE way” of building ntp with a custom ./configure command to turn on reference clock support?

Can anyone point me to either RPMs that already have this stuff correctly setup or to a HOWTO web site for doing either or both of these things?

By the way the LinuxPPS patches are now fairly mature and are now appearing in the daily mm kernel snap shots. There is a high likely hood that these will become a standard part of 2.6.29.

#2

You could modify the spec file and make a new SRPM file from which a new RPM can be built.

#3

Yes I was thinking along those lines but is there a HOWTO some place? I use a source based distro so I need some help with how to modify the spec file and exactly what needs to be done.

For example glibc needs a patch and I suspect that the patch needs to be added to the tarball and something added to the spec file to apply it. It that how that works?

For ntp I need to change how it is configured and I suspect that the spec file needs to be modified to make that happen but how?

Doing a patched kernel did not require messing with the spec file although I suspect that for the new kernel RPM to be correct that the spec file would need mods to build and install the PPS user land tools.

#4

In the spec file you get to specify the steps needed to get from the upstream distribution + patches to the package. You will see a number of Source lines (usually 1) and a number of Patch lines. That’s where you add your diff patch so that it gets assimilated during the build process.

To unpack a SRPM, put it in /usr/src/packages/SRPM and rpm -i it. The sources will appear in /usr/src/packages/SOURCES and the spec file in /usr/src/packages/SPECS. Then edit the spec file and issue rpmbuild -bb foo.spec to rebuild the RPM under /usr/src/packages/RPMS. The build directory will be /usr/src/packages/BUILD and you can specify no cleanup after the build as a debugging tool to inspect the build to see that the build is working.

You should be able to find quite a few online resources about using rpmbuild. I don’t have one bookmarked, it’s been a while since I did a build and the basics haven’t changed, only the build process has lots of elaborations now. But you only need to tinker with one small step in the process.

PS: A lot of your time will be spent installing build prerequisites before you can get a spec file to build.

As for userland tools, usually that would go in a separate package from the kernel. I think you can specify Recommends in RPM specs these days, didn’t use to be able to.

PPS: When you have mastered the build, consider building and distributing the packages via the OpenSUSE Build System, of course.

#5

Thanks I think that helps. I am not too worried about build prerequisites since glibc is pretty much stand alone and ntp only needs glibc and the kernel headers (I think but in any case not much more then that) which are already installed.

These are new user land tools and currently they are sitting in the kernel tree after the PPS patch is applied. I agree that they should be in a separate package and have said so on the LinuxPPS email list. I suspect that the kernel devs will make the LinuxPPS developer remove these before kernel inclusion in which cast there will have to be a separate package created. Although from following the kernel discussion threads related to this patch set they have yet to raise this issue since their primary focus has been to have this not impact the serial code too much.

I had a quick look at the OpenSuse Build System last week and it seemed a little over the top unless someone was doing a lot of RPM related dev work which I am not. While I agree that there are users that are interested in having this stuff working in a form that is easy to install there are a lot of other issues such as fixing the YAST ntp stuff that would likely make providing a set of RPMs more work then I am considering doing. If the LinuxPPS patches do end up in 2.6.29 it will create pressure for distros and those who support packages like glibc to get all of this time related stuff cleaned up. The linux time related stuff has changed a lot over the last few kernel releases and is still in a state of flux.

These reference clocks are now cheap to setup. About $60 for a new garmin 18 lvc plus you need some small parts to hook it up to a serial port. Or you can get tested, used Oncore UT+ modules that are pulls from cell sites on ebay for a little over $20 including shipping. Plus you need about another $30 or so for other parts (antenna, ttl to rs232 circuit, serial cable…) and a few hours to build the circuit. The result is a highly accurate system clock once everything is working. But getting there is currently non-trivial since it requires, in most cases, some hardware fabrication and a lot of patched software.

The Oncore UT+ units have the PPS pulse happen with in ± 50 nano seconds of the UTC seconds epoch before the driver applies saw tooth correction which removes most of the error. The limiting factor is the instability introduced by ambient temperature fluctuations affecting the computer’s quartz oscillator. This limits system time accuracy to about ± 20 micro seconds on most systems since ntp ends up chasing these fluctuations in the PPL loop. Still this is at least 100 times more accurate than a typical ntp machine that is using public ntp servers.

The Oncore and Garmin units are the ones most commonly used right now. These are cheap, well supported and widely available.