Notes on setting up reliable timekeeping
|Setting up a timekeeping server|
|GPS Receiver Hardware|
Setting up a timekeeping server with a Power Macintosh
I have a Power Mac G4 MDD that for the last 5 years has been sitting idle and gathering dust (literally). I have always liked the machine, initially because at the time I acquired it, it would eat the lunch of any comparable machine in its price range and secondly, it is just so well engineered. No screws to open the case, just fold down the door. Disks are mounted in easy to remove carriers, etc etc.
Anyway, I digress. I figured it was time to put the machine to work again and to use it as a Linux based server on my home network.
The machine is built to only run on IDE disk, so first up I decided to find a PCI Sata card and install a SATA drive. Thats not easy these days because PCI is itself almost obsolete. I found one locally (here in New Zealand) and then found that MacOS would not see the card and that OpenFirmware didnt recognise it either. There would be no way to boot from it. However I didnt really see that as presenting a problem, such is my faith in the ability of Linux to run on just about every piece of computer (and computer like) hardware that has ever been invented.
I downloaded the ISO install image for Debian Linux (powerpc version of course), burnt it to CD and was able to immediately boot the G4 in Linux from the CD. The SATA controller was visible to the installer and I preceeded to install the operating system to the SATA drive.
I still have the IDE drives installed in the machine and I was able to put the Linux boot strap onto a small (800K) partition on one of those drives, remove the CD and successfully reboot the machine.
Finally a working Linux machine on my PowerMac G4.
GPS Receiver Hardware
As well as the computer, you must also have a GPS receiver. In addition to position data, the gps system will transmit time data with the accuracy of the atomic clocks on board the satellites that provide the service. It is easy acquire a USB powered receiver for well under $100 that will lock into these signals, but there are caveats.
USB gps receivers present to the computer as a serial device. Most of the USB powered receivers are very good at providing location data, but the timekeeping accuracy is only good to within a couple of hundred milliseconds. The signals from the satellite are extremely accurate, but by the time they have been interpreted by the receiver, transmitted over the usb bus/serial port to the computer and then interpreted by the software on the computer, some 100's of milliseconds will have elapsed. And this is not a constant value. The messages from the GPS receiver vary in length and the time to transmit each one over the usb interface is also variable.
The software team who develop gpsd figured out that the little red LED on the side of USB receivers, the one that blinks at a steady one pulse per second when lock has been acquired, is in fact synchronised to the atomic clocks on the satellite (allowing for propogation delays through the atmosphere). They were able to work with a vendor to have a USB Receiver built that transmits this pulse as a PPS signal to the pseudo-serial interface seen by Linux, enabling timing data with accuracy of better than 1 millisecond.
This unit they helped develop is the Navisys GR-601W_1PPS GPS Receiver and it is readily available.
If you want to do accurate timekeeping with GPS then you MUST have a GPS receiver that provides PPS synchronisation.
There are 2 packages that must be installed to provide timekeeping on Debian Linux. I use the aptitude interface to Debian's package management system.
aptitude install gpsd
aptitude install ntp
Thats it - pretty easy I think.
Reference documentation for gpsd is available at the gpsd project website in addition to the man pages that are installed with the software package.
Carefully read the man page installed with gpsd and ensure that your receiver is working and getting a good lock on the satellites.
Towards the end of the man page are examples of how to interface gpsd to the ntpd daemon. You may need to adjust the constants in the configuration to match your particular GPS receiver. My own configuration is shown below, with constants provided to me by Gary Miller for the Navisys GR-601W_1PPS GPS Receiver. I also deviated from the sample in the man page by marking my PPS receiver as a truechimer. Without this parameter it switches to being a falseticker after about 5 minutes of operation.
# time1 values recommended by Gary Miller for GR301-W USB GPS server 127.127.28.0 minpoll 4 maxpoll 4 fudge 127.127.28.0 time1 0.150 refid GPS server 127.127.28.1 prefer true minpoll 4 maxpoll 4 fudge 127.127.28.1 time1 0.001500 refid PPS
Debian - systemd
The new (on debian linux distributions) systemd replacement for init and startup scripts caused a few problems with gpsd. I guess I didn't read enough before allowing the apt-get update, but after the first reboot, gpsd was running with incorrect flags.
Previously, using SystemV init scripts, the configuration file
/etc/default/gpsd looked like this:
root@millie:/etc/default# cat gpsd # Default settings for gpsd. # Please do not edit this file directly - use `dpkg-reconfigure gpsd' to # change the options. START_DAEMON="true" GPSD_OPTIONS="-b -n" DEVICES="/dev/ttyUSB0" USBAUTO="false" GPSD_SOCKET="/var/run/gpsd.sock"
The solution was simple. once I found out what to do.
- cd /etc/systemd/system
- Copy the package service file to this directory.
cp /lib/systemd/system/gpsd.service .
- Open the copy with your favourite text editor (vi, nano, emacs ...)
- Find the line
- Append your specific options to this line. In my case
ExecStart=/usr/sbin/gpsd -N -b -n /dev/ttyUSB0
- Save your changes and exit the editor.
- Re-enable the service and get it running
root@millie:/etc/systemd/system# systemctl reenable gpsd root@millie:/etc/systemd/system# systemctl restart gpsd
- Verify that gpsd is running as expected.
ps -ef|grep gpsd
After allowing the software to run for several hours, ntpd will discipline the system clock and give very accurate readings of the current time. Of note are the very low offset and jitter (sub 1 msec) for the PPS synchronised clock, SHM(1). Also, you can see that the raw values from the receiver SHM(0) have about an order of magnitude worse performance.
The clock precision on the G4 is also of interest. At -22 it is at least an order of magnitude better than the clock on my Intel machines. I'm not sure if that's significant but it is certainly noteworthy.
root@millie:~# ntpq -pcrv remote refid st t when poll reach delay offset jitter ============================================================================== xSHM(0) .GPS. 0 l 4 16 377 0.000 6.954 1.150 *SHM(1) .PPS. 0 l 3 16 377 0.000 0.103 0.297 associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync, version="ntpd firstname.lastname@example.org Mon May 20 15:37:24 UTC 2013 (1)", processor="ppc", system="Linux/3.10-2-powerpc-smp", leap=00, stratum=1, precision=-22, rootdelay=0.000, rootdisp=0.697, refid=PPS, reftime=d5e92390.2acaac18 Sun, Sep 22 2013 20:06:40.167, clock=d5e92393.7a1ca8cb Sun, Sep 22 2013 20:06:43.476, peer=63606, tc=4, mintc=3, offset=0.103, frequency=20.967, sys_jitter=0.297, clk_jitter=0.452, clk_wander=0.069