The time server below is an ancient Pentium-166 with 64Mb of RAM. It uses a version of NTPv4 customized to work with the GPSClock 200. It runs FreeBSD 4.7-stable and has been running as it is for the last two years.

The time server also has several other systems listed as servers. It could therefore fall over to a reliable time source if the GPS clock failed for any reason. This also gives it a standard by which to check the sanity of the time codes it gets from the GPS receiver.

Notice that the GPS clock's time and that of tick.exit.com agree to within 94 microseconds. They are probably really much closer, but network jitter makes it impossible to prove this.

     remote           local      st poll reach  delay   offset    disp
=======================================================================
 time.nist.gov   206.223.0.14     1   64  377 0.05650  0.000453 0.00421
.GPSCLOCK(0)     127.0.0.1        0   64  377 0.00000 -0.000000 0.00093
.tick.exit.com   206.223.0.14     1   64  376 0.00102  0.000094 0.00522
 tock.gpsclock.c 206.223.0.14     2   64  377 0.03864  0.001005 0.00487
 tick.gpsclock.c 206.223.0.14     2   64  377 0.03906  0.001523 0.00487
*PPS(0)          127.0.0.1        0   64  377 0.00000  0.000000 0.00095
 tick.ucla.edu   206.223.0.14     1   64  377 0.02553  0.002209 0.00462

Here's the output of a 'sysinfo' command on the server.

system peer:          PPS(0)
system peer mode:     sym_active
leap indicator:       00
stratum:              1
precision:            -18
root distance:        0.00000 s
root dispersion:      0.00186 s
reference ID:         [PPS]
reference time:       c1f632dc.39a13dca  Thu, Feb 13 2003  7:06:04.225
system flags:         auth monitor ntp kernel stats pps 
jitter:               0.000000 s
stability:            0.001 ppm
broadcastdelay:       0.003998 s
authdelay:            0.000013 s

Here's the output of a 'kerninfo' command on the server. It shows how well the kernel locked the system's clock on to the reference clock. Notice the precision and the pps stability and jitter.

pll offset:           1.275e-06 s
pll frequency:        -95.648 ppm
maximum error:        0.032407 s
estimated error:      2e-06 s
status:               2107  pll ppsfreq ppstime ppssignal nano
pll time constant:    6
precision:            1e-09 s
frequency tolerance:  496 ppm
pps frequency:        -95.648 ppm
pps stability:        0.002 ppm
pps jitter:           2.302e-06 s
calibration interval: 256 s
calibration cycles:   3188
jitter exceeded:      1417
stability exceeded:   0
calibration errors:   15

Here's the output of a 'showpeer' on the GPS clock. This basically shows a perfect clock, estimated to be off by a few microseconds (near the rated PPS jitter).

remote 127.127.41.0, local 127.0.0.1
hmode client, pmode unspec, stratum 0, precision -20
leap 00, refid [GPPS], rootdistance 0.00000, rootdispersion 0.00000
ppoll 6, hpoll 6, keyid 0, version 4, association 46596
reach 377, unreach 0, flash 0x0000, boffset 0.00400, ttl/mode 0
timer 507s, flags config, refclock, bclient, prefer
reference time:      3e4bb69d.00000a0c  Mon, Feb 13 1933  7:15:41.000
originate timestamp: 3e4bb69d.00000a0c  Mon, Feb 13 1933  7:15:41.000
receive timestamp:   c1f6351d.a284672d  Thu, Feb 13 2003  7:15:41.634
transmit timestamp:  c1f6351d.3970d367  Thu, Feb 13 2003  7:15:41.224
filter delay:  0.00000  0.00000  0.00000  0.00000 
               0.00000  0.00000  0.00000  0.00000 
filter offset: -0.00000 -0.00000 -0.00000 -0.00000
               0.000000 -0.00000 0.000001 0.000001
filter order:  0        1        2        3       
               4        5        6        7       
offset -0.000002, delay 0.00000, error bound 0.03072, filter error 0.00000

And here's a web server that is configured to consider the time server as a possible network peer. The web server and the time server are connected via DSL.

The system "tock.exit.com" is the Pentium 166 system running FreeBSD 4.7 with the GPSClock 200. The other system, "tick.exit.com" is an early prototype of a new device consisting of a Soekris Net4501 single-board computer (essentially a 486-class machine) connected to a Motorola UT+ Oncore GPS unit. (It hasn't been tweaked, particularly, it's just a plain- vanilla installation, but it is very accurate. Future versions should be significantly more accurate.)

Most of the differences between the stratum-one servers can be attributed to network delays. In particular, the apparent superiority of tock versus the Truetime server can be attributed to the fact that the web server is much closer in the network topology to tock.exit.com than to ntp2.truetime.com. It is almost certainly not the case that Tock is the more accurate server. This goes double for time.nist.gov.

     remote           local      st poll reach  delay   offset    disp
=======================================================================
.ntp2.truetime.c 206.223.0.140    1  128  377 0.02415  0.000099 0.00764
.time.nist.gov   206.223.0.140    1  128  377 0.03691  0.000243 0.00430
*tock.exit.com   206.223.0.140    1  128  377 0.02225  0.000150 0.00478
 tick.exit.com   206.223.0.140    1  128  377 0.03177  0.002550 0.00479
 tick.ucla.edu   206.223.0.140    1  128  377 0.00543  0.002724 0.00522

Note that these are the results that I have achieved. I believe that they are typical of what can be done with this clock. I have used no unusual hardware and the software that I have used is freely available. Still, your mileage may vary. These are not guaranteed specifications.

Read about GPS timekeeping. Would you like a clock like mine? Would you like to see how it's working now?

Copyright © 1999, 2001, 2002, 2003 GPSClock.com
Contact Us