Almost everything in todays PC's relates in some way to time: CPU cycles, bus frequencies, graphics refresh rates, file dates, even a simple cursor blink. Correct time is one of the fundamentals for reliable and secure computing. Yet setting and keeping correct time is one of the challenges standard computers didn't solve yet. Computer time happily drifts away and relies on the user to be set, while any cheap digital watch keeps better time and is often already radio synchronized to a public time service.
Fortunately, there is a solution. In todays networked world, public servers provide time via the network time protocol NTP. These servers build a chain, were correct time is distributed down from servers that get their time from the highest accurate clocks available today.

UltraLink Model 325 WWVB Time Receiver, serial port
UltraLink Model 325 WWVB Time Receiver, serial port

Wouldn't it be good to have such a root server directly in your local network? There are several ways to do that. Apart from turnkey blackbox networked server solutions ($$$), a time signal receiver can be attached to a soon to be NTP root server (off the shelf hardware), usually through a parallel or serial port. Several receiver technologies are to choose from, with GPS the most expensive. For my budget and requirements, I choose the M325 WWVB radio receiver from UltraLink. Moderate priced at $165, it is small, compact and, something I learned to value highly, does not need an external power supply. The receiver gets its time signal from the atomic clock in Fort Collins, Colorado, operated by the National Institute of Standards and Technology (NIST). The signal is transmitted in low frequency at 60kHz with an effective power of 50KW and an accuracy of up to 100 microseconds. It covers all States in the U.S., with the exception of Alaska and Hawaii. Hawaii got its own WWV station located on the island of Kauai near Kekaha, while Alaska is covered by the Canadian time signal. Although being located on the U.S. mainland, signal strength and good reception is dependand on the receiver location and placement. I had almost no reception in the office building, but have excellent, full strength signal at home (wood house). On the receiver, signal reception is indicated by the green led blinking, low blink frequency or steady green light indicate no reception.

UltraLink Model 325 WWVB Time Receiver, inside view
UltraLink Model 325 WWVB Time Receiver, inside view

Lets see what data the clock provides. Communication with the clock could not be simpler: using a standard serial connection with 9600-8N1, were I can send single character commands to it. After 'T', the clock returns a time string, while for 'I' it replies with its model and revision information. But how does the clock get its data via radio? According to the WWVB protocol, information regarding the current date and time is transmitted one bit per second in binary coded decimal (BCD) format - were four bits represent one number. Bits are recognized when when the signal power is reduced for a few milliseconds, 200ms and its a '0', 500ms and we got a '1'. It takes a full minute to transmit the 9 time digits and various other bits including separation markers. That explains why the clock needs 5 minutes to be ready after initialization. It needs some time to synchronize itself, and then a full minute after it cought the beginning of a new transmission cycle. The clock itself contains a microchip that implements a real time clock driven by a a precision quartz crystal. This ensures continous operation should there be an reception outage.

After connecting the clock to a computer, we can start integrating it into the operating system. NTP implements a daemon that compares the data from external clocks with the computers internal clock and adjusts the internal time.

Console connection via serial port
Console connection via serial port at 9600 bps 8N1

Reference clock drivers allow the NTP daemon to identify the correct clock type and decode its data. Number 34 is the assigned reference clock driver number for our vendor UltraLink. Unfortunately, in NTP version 4.2.0, the newer Model 325 was not supported by this driver yet, so I sat down myself and rewrote the driver to add support for Model 325. After adding support to the reference clock driver and sucessfully compiling ntp, its time to verify it all works together. Before starting ntp, I had to create a symbolic link for the expected device file /dev/wwvb0 to the serial port device file were the receiver is connected to. Then the configuration file ntp.conf got the following lines:

server prefer
fudge stratum 0 flag1 1

NTP clock statistics
NTP clock statistics, (click to enlarge)

Adding some a few lines for access control and all is ready. Combined with the standard Solaris 9 operating system kernel, I expect to be accurate down to one millisecond. A higher accuracy can be achieved with special kernels working at higher time precision, combined with switching on the PPS feature in the receiver. With my feedback to the NTP team, I am now maintainer for this reference clock, feel free to send me questions and I'd be happy to help. 2010 Update: Ultralink discontinued the sale of NTP clocks - to bad since they were affordable and reliable. Good luck with your time!


Credits and Copyrights: