we get signal

2007-01-06

(not that) Obsessed with accurate time: Contemplating building a NTP server slaved to GPS

(tags timekeeping, GPS, hardware)

I have a fascination with accurate time. I remember when I was young, I used to call the time service to get the correct time to set various house clocks. ("At the tone, Pacific Standard Time will be twelve, forty-eight, and fifty seconds. BEEP") When I got Internet-savvy (is that a dated word or what?), I found out about the Network Time Protocol project (NTP). One focus, apart from maintaining the specification, is to publish accurate time over the Internet, for lower accuracy timing devices such as desktop PCs.

There is a lot of infomation out there for time synchronization. There is the NTP Public Services Project, the Japan Standard Time Project (日本標準時プロジェクト), then there are "time nuts". Check out the guy with his own cesium based "atomic clock" in his house. There is overkill, but then again this guy can never have enough overkill. I find that once you get the itch to get more accurate time, you run up against the "time nuts" sites real fast. They are filled with esoteric incantations, wierd squiggly graphs and hardware pr0n, but not much basic (intermediate?) knowledge.

Currently I use NTP public servers and the Meinberg NTP server and monitoring software on Windows XP. It generates nice graphs. The below shows that my computer has kept time within 0.1 seconds from a public NTP server (stratum 2).

NTP loop stats for Project Sugar, 2006-12-28 to 2006-01-06

I only recently began thinking about making my own time server, just for kicks. But this involves substituting the Internet for another reference clock. There are many options for various levels of tolerance and drawbacks, such as using radio and GPS, as well as using your own timing device (crystal oscillator, atomic clock!). Being a software guy with minimal hardware knowledge, I am considering a USB connected GPS receiver, since it receives time information from the multiple "atomic clocks" in orbit, the GPS satellites and should require only antenna setup.

Crudely summarizing, there are important concepts to remember when building a time server.

  1. Time provider (example: NTP stratum 2 servers, GPS device)
    With public NTP stratum servers, all you have to do make sure you are connected to the Internet and can receive NTP/SNTP packets. In contrast, the GPS device must be able to output time in a machine-coherent and continous pattern. Typically, desirable devices output time every 1 second or less.
  2. Time message protocol (example: NTP via Internet, NMEA 0138 via serial or USB interface)
    Within the NTP hierarchy, you use NTP. For your own time server there are many standards based on the type of reference clock device. Currently, the NTP server software supports many devices, from specialized to generic. One generic device type is called "Generic NMEA GPS Receiver", which has a message protocol that is now popular enough that many off-the-shelf Windows mapping software supports directly.
  3. Time consumer (example: NTP server software)
    Basically my example revolves around the reference NTP server software, because it has the ability to act as a server and also discipline (maintain accuracy) the local software clock. But it is possible to substitute a SNTP client, which merely brute forces synchronization. The w32time service in Windows XP is an example of an SNTP client. Take a look at Coding Horror's "Keeping Time on the PC" to improving the query time of that client.

It is possible to buy a USB connected GPS receiver for less than 10000 yen nowadays. Make sure it has the NMEA 0138 output protocol. Unfortunately, since the Windows ports of the NTP server software (on the surface? checkout ntpd/refclock_nmea.c:61) does not support anything other than the undisciplined clock, you may have to repurpose a FreeBSD or Linux box for NTP. And no, you can't use a Virtual Machine for the task.

It doesn't seem insurmountable, it just takes some patience and more hardware. And time! Ack!