Abstract
The use of a GPS timing receiver with Pulse Per Second output to
increase the accuracy of a Network Time Protocol server is explored.
Setup
In this experiment a Motorola Oncore GPS timing receiver's 1 pulse
per second (PPS) output was connected to the data carrier detect (DCD)
line on a serial port on an Intel Pentium 133 based PC running
FreeBSD
and the
Network Time Protocol Daemon (ntpd).
The
Pulse Per Second reference clock driver was used to allow the PPS
signal to discipline the system clock. Second numbering was obtained
by configuring ntpd to query a second public NTP server. This is necessary
since the PPS driver cannot label the second number or even the date,
only provide an accurate representation of when the actual second occurs.
Ntpd was also
configured to keep statistics on clock performance.
A second FreeBSD system on the same local area network was configured to
poll the test NTP server as well as other public NTP servers and keep
statistics on the quality of the server performance.
Results
The two parameters graphed for each system are the offset and jitter.
Offset is the difference between when the time source (GPS for the
server, NTP server for the client) indicates the 'tick' of the second
should occur and the NTP calculated clock. The root mean square (RMS)
jitter is a measurement of the instability of the time source as
compared to the NTP clock. Each graph contains data over a 24 hour
period, starting at UTC midnight. Please note that the Y-axis scales
on the graphs are not identical.
Statistics from GPS/NTP server
Statistics from external client
Conclusions
The data seems to indicate that although the GPS timing receiver PPS signal
does a very good job of disciplining the server clock to a very low-jitter time setting,
external NTP clients keying off the server see timestamps with offset and jitter
about two orders of magnitude worse than the PPS signal itself. If this is caused by
the server hardware, the network infrastructure, ntpd, the GPS receiver, or
some combination of these or other issues is unknown at this time.
Update: December 26, 2007
This server continues to run as one of three 'production' NTP servers. The
server itself was upgraded to a 250 MHz Cyrix M2 system with 165 MB of RAM.
It was discovered that the Motorola Oncore receiver had locked up for
approximatly 43 days, putting out no PPS signal. Since the server was configured
to use a network NTP server to number the seconds, the server fell back to this
as the primary time source and continued to function. After checking the
antenna and cables, the receiver was power-cycled and returned to operation.
The cause of the receiver lockup is unknown at the time of this writing. It
would seem some sort of automated monitoring of the GPS receiver status would
be a good addition to the server.
Update: January 14, 2008
The Motorola Oncore GPS receiver was turned off and removed from the ntp server,
replaced with a Garmin GPS-18 LVC unit. The specs on the Motorola are actually
better on the PPS line (20ns) than the Garmin (1us), but the Oncore unit had to
be returned to its owner. The Garmin replacement was reasonably priced, and
given serial port hardware jitter, should be just as applicable.
