NTP and GPS - Some Background

I started fiddling with Network Time Protocol (NTP) because Windows 2000 systems in an Active Directory (AD) domain need to be time synchronized to work properly. That part was easy, just point the highest domain controller (DC) in the AD forest to a  time server. The rest of the Win2000 systems in the domain sync to the DC. The Win2000 systems use SNTP (Simple Network Time Protocol) which I understand is a subset of NTP.

As with everything, I got carried away. It wasn't enough to create a single time source. After scanning though the NTP documentation, I decided to assemble a small time network with some redundancy using a couple of Linux servers that I had access to. As with every project I do, I try to be economical and put all the stuff I have laying around to work. I had an old Delorme Tripmate GPS receiver in that pile of stuff. GPS makes a good time source so all of a sudden the old GPS receiver became useful.

The Time Network

The network turned out to be the easy part even though there was a steep learning curve. I started with two Linux servers, one in my office and one at another office. I used two independent external stratum 2 server at each office, plus I cross linked the two servers as peers. This gave each of my Linux server three time sources. This is probably a minimum, because if one server became unreachable, and the other two sources didn't agree, the system could fail.

Too add some redundancy, I added a third Linux server. It was my old system and was doing nothing anyhow. As with the other two servers, I used two independent external stratum 2 time sources, and cross linked my three (stratum 3) servers as peers. I didn't bother with authentication at this time.

This all seemed to work well. Each of my servers had two stratum 2 time sources and two stratum 3 time sources. Once in a while one of the external servers would become a stratum 3 source which forced my server to a stratum 4 server, but the times synchronized to within a few milliseconds among the three servers.

I used these time servers as the source of time for my Windows AD domains. In my office, I use a Windows 2000 server as the DC and the base of my forest, so I just pointed that server to my Linux NTP server to get the time. From the Windows 2000 command line:

C:>net time /setsntp:tic.rivercitycanada.com

where tic.rivercitycanada.com is the name of the system with the NTP daemon. In the other office, we used Samba as the DC which also happened to be the NTP server. I added the line to the smb.conf file:

time server = Yes

The only problem there is that the Windows service (w32time) that sets the clock would not use the Samba system for time. The system logs filled with w32time errors. It would find the server with the net command:

C:>net time
Current time at \\CHECKIN is 3/14/2002 6:10 PM

Which was correct. I found out later that Windows 2000 will only use a server version 5.0 or better for time. The Samba server reported itself as version 4.5.

One of the solutions was to create a logon batch file to use the net time command to manually set the time every time the user logged on. The second method is to set the w32time service to use the NTP server directly rather than the Samba server as I did with the DC at the other office. I used the net time /setsntp command to point the all computers at the NTP server which just happens to be the PDC for the NT domain also. This is more elegant and doesn't rely on the user logging on and off to set the time.

This was better than what was needed. Synchronization to UT is not a requirement of the Windows AD, the systems just have to synchronized to one source. However, setting the time to a world standard makes things like the time stamp on email and files work properly.

The GPS Connection

While stratum 3 time was more than adequate, there is nothing like reusing old stuff to push the limits. As I mentioned, I had an old GPS receiver, a Delorme Tripmate to be exact. This receiver has a serial cable and was made to be used attached to a laptop computer and in conjunction with the Street Atlas software. There are no external controls other than the serial connection. However, it does output some NMEA 0183 signals so can be used as a time source using a NTP type 20 reference clock driver.

There were a couple of problems with the Tripmate. It was run by batteries or by a +5-10V source on pin 9 of the serial cable. I happen to have a cable adapter from Delorme that gets the +5V from the PS2 port. I was using both PS2 ports (keyboard and mouse) but found a splitter that allowed me to draw off the +5V source I needed.

The second problem is that the GPS receiver needs a clear view of the sky to receive the signals from the satellites. It will work through your roof, but I suspect it's not very reliable that way and the signal is degraded somewhat. While a clear view from horizon to horizon is preferable, it only needs three satellites to get a 2D fix, so even if you have a portion (50%) of the sky available, you'll probably get a good continuous signal. I have mine out back of the house for now, but will probably permanently attach it to the roof if it continues to function OK. It looks waterproof, but I think I'll place it inside or under better waterproofing. I don't know what temperatures it'll tolerate. We'll find that out when it gets cold I guess.

Aside from the physical problems, the system outputs some NMEA statements every second, but I don't think they are very accurate. I had to add a fudge factor of 2.1 seconds. This seems to change if you restart the GPS receiver. I used batteries for a couple of hours, then I hot wired it to test that before I bought the proper cables and the fudge factor changed each time. I'm not sure why the differences. I did try unplugging the cable to restart it. The fudge factor didn't seem to change with this method.

Irregardless of the accuracy, the signal from the GPS receiver seems to have very little jitter. So once the fudge factor is applied to adjust the time to UT, it probably provides a very reliable signal.

I also had one other problem. The receiver outputs four signals, three NMEA (GGA, GSA and RMC), plus one proprietary signal (ZCH). The NTP documentation discusses the RMC statement, but the GGA statement also outputs UT. I left the receiver output all the statements, until I found that the driver switched statements for a while. This changed the fudge factor, because there is a difference in time from when the RMC and the GGA statements are output. NTP quickly noticed this and marked the GPS signal as a falsetick. I had to turn off all the statements except for the RMC so that there was no confusion. I found the documentation on the web to do this.

Conclusion

The network changed slightly with the added GPS time source. When it took over, the stratum 3 peers became stratum two peers as the best source was now the server with the GPS time source. They were also rejected as candidates as system peers because they got their time from the server connected to the GPS receiver. A catch-22 I guess.

I suppose I could remove the one server now. It wasn't supplying a time source to anything anyhow. I may add one of the external time servers to the system without the GPS source so that it would have at least four sources (three servers and one peer) but drop the other. That would keep in line with my economical nature. The other server also has four sources, GPS, two servers and one peer.