Geeks in Paradise | Brian Chee » Roll your own NTP Server

August 30, 2006 | Comments: (0)

Roll your own NTP Server

TAGS: Industry Trends

It was in the mid 1990's that I had a conversation with some folks at Novell about their NDS (Netware Directory System) where network (as opposed to just file server) authentication became based upon directories instead of older flat file systems. The conversation wasn't so much about the system itself, but rather about an age old data base problem called "deadly embrace". Basically the problem surrounds how computer clocks aren't terribly accurate and we chatted about the possibility of NDS server clocks getting too far away from each other and no longer able to figure out who updated whom first.

Example:
Server A contains user Harry Truman, but so does Server B which is a backup directory server for the enterprise. However, the admin for Server A updates the password for Harry but unknown to them the clock of Server B is ahead by a couple of minutes. Just after the Harry Truman record gets updated, it's time for the servers to synchronize their databases. So does Server A or Server B have the correct password for Harry? The record in Server B is newer according to the clock. In reality, directory systems don't ONLY go by time stamp, but we have seen a case during our Identity Management Shootout where the migration of Active Directory records from Fergensmeir Corp to TCP/IP Corp didn't work because the clocks on the machines were too far apart.

The solution isn't tough to imagine, get more accurate clocks. However, cesium clocks (based upon the atomic decay of cesium, also called atomic clocks) haven't gotten inexpensive enough yet to become prevalent in even high end servers.  Even with new advances in single chip clocks, pricing hasn't dropped enough to make it economically viable solution for most corporations. The reality is that GPS already has super accurate Cesium clocks in them and through a mathematical formula can be accurate in the range of 40 nanoseconds or better. Truly accurate enough to eliminate the deadly embrace problem.

So I began the search to find a NTP (Network Time Protocol) server that would be inexpensive enough that even small business would be able to afford it. Failing this, I was looking at working with a Computer Science Grad student on modifying existing code to take advantage of a hardware hack that involved drilling a hole into an el'cheapo GPS. The biggest problem with this overall plan is that serial connections are inherently sloppy on timing and some sort of clock signal was needed to bring more accuracy to the clock feed from the GPS. The answer is the 1PPS (or 1 pulse per second) where we have the proverbial swinging pendulum with which to synchronize our clock with.

Fast forwarding this whole process, I'd like to bring your attention to a project started by Adrian Von Bidder and now maintained by Bjørn Hansen called pool.ntp.org where everyday folks setup time servers around the world to alleviate the load on the big popular time servers like time.microsoft.com. Interestingly enough, having local NTP servers available everywhere will also solve the deadly embrace problem I previously mentioned. So that's half the problem, but if an NTP server is going to cost upwards of $7,000/each this project is not going to get very many entries in the pool. The answer is another project by Philip M. White that utilizes a very inexpensive GPS from Garmin (under $100/each) that not only provides the serial time+location feed but also the all important 1PPS signal. Based upon the Garmin GPS 18 LVC (LVC is the barewire version) Mr. White outlines the process to build a very simple circuit to feed both the NMEA (National Marine Electronics Association) serial feed of time+location information and combining the 1PPS signal into a single serial interface.

One VERY important item to remember is that this system requires that you have a UART 8250 based serial port, anything else will skew the results and invalidate the accuracy of your clock source. Keep in mind that serial port are notoriously sloppy since it's an asynchronous interface and doesn't normally need to be that accurate. So by staying with a known quantity like the 8250 UART, the authors can predict a normalized delay for the circuitry.

So I've got an Garmin 18 LVC on order and will be hitting a local electronics store for the simple components needed for the interface. I'll update this post once I get it built, and include pictures of my version of the unit. From all indications, this circuit should be well within the realm of just about anyone that can do simple electronics soldering.

/brian chee

Posted by Brian Chee on August 30, 2006 06:52 PM

RATE THIS ARTICLE: