Time has recently been mentioned time several times and from the response, it may have been timely. So, this week, we'll take a closer look at network time-keeping.
But first, put the following snippet in a file and save the file with the extension "htm" (you could also paste it in the body of an existing Web page):
Now load that file into your Web browser and, as long as you can access the Internet and run Java applets, you'll see a real-time display of the time at the National Institute of Standards (NIST) with an accuracy of plus or minus one second. This applet is used on the page www.bldrdoc. gov/timefreq/javaclck.htm (I added the CODEBASE argument so that the correct location of the applet can be resolved).
NIST also offers 16- and 32-bit time synchronising utilities on the same page, but they are rather less sophisticated than the ones discussed in my last column (www.nwfusion.com, DocFinder: 2728)Underlying these tools are several protocols. The oldest is the Net- work Time Protocol (NTP), defined in RFC 1305, which you can find at www.cstv.to.cnr.it/toi/rfc/rfc1305.txt. For a good overview of NTP and synchronising clocks over networks, check out the Executive Summary at www.eecis.udel.edu/ ~ntp/ntpspool/html/exec/htm.
You may also come across other time protocols, including Simple Network Time Protocol (SNTP), a streamlined variant of NTP. You'll find RFC 1769, the spec of SNTP, at www.cstv.to.cnr.it/toi/rfc/ rfc1769.txt.
The idea behind NTP isn't complicated: The client sends a request containing a time stamp - a notation of the client's local time - to a time server. The server responds by adding its time stamp to the packet and sending it back to the client.
The client then subtracts the time stamp it sent out from its current time to estimate the round-trip delay. Next, the client halves that round-trip value and adds that result to the time server's accurate time stamp to derive the correct time. Then the client resets the local clock adjusting for the local time zone.
Of course, the assumption that the round-trip delay is made up of equal outbound and inbound delays isn't necessarily true - the trips across the Internet could be different for each leg.
In short, getting really high accuracy is quite a feat (proving once again that the devil is in the details). But most NTP and SNTP software can easily achieve subsecond accuracy, providing that the time server they reference is at least a "stratum 2 server".
Stratum 2 servers are those that talk to (guess what?) the stratum 1 servers. These servers are directly connected to the really high accuracy atomic clocks. As of early 1999, there were 79 stratum 1 servers worldwide and around 100 stratum 2 servers. While you can access the stratum 1 servers, you are strongly discouraged from doing so because they are under a huge load from the designated stratum 2 servers as it is.
So why is time such a big deal? Well, if you require accurate timing for mission-critical operations, such as air traffic control, you have to build a robust time-keeping architecture.
Of course, in these environments you would want to put a highly accurate and reliable time source directly on the network rather than count on network time servers on the not always reliable Internet. See www. eecis.udel.edu/~ntp/hardware.html for a list of vendors that sell time hardware.
Some other fine time resources online can be found at Yahoo's listing of time-related sites: http:// dir.yahoo.com/Science/Measurements and Units/Time/Current Time/.