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:
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).
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).
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.
What is the “SuSE way” of building and installing a patched version of glibc?
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.