"The sweet spot for accuracy in most timing applications has been one second," said Dennis Workman, senior director for the timing-product line at Trimble Navigation Ltd., which claims to have solved the problem in its Trimble Palisade NTP receiver. "These applications were typically time stamps for billing in telephone networks, for processing transactions such as competitive bids or for ISO 9000 event logging. For the most part, these time stamps just needed to be traceable to Coordinated Universal Time in some way.

"But the landscape is changing with the intrusion of media data types and secure data onto the global network," Workman continued. "If you break a stream of video up into packets, for instance, you need to tag them in some way so you can assemble them back into the right sequence and present them at the right time. There is still debate about whether you can accomplish this with sequence numbers, or whether you need very accurate time stamps."

There is less debate in network security, he said. "Really secure protocols require an accurate time stamp on each packet so that the receiver can determine how long the packet has been in transit. If transit time exceeds an expected figure, the receiver assumes the packet has been compromised and discards it."

The accuracy required for these applications varies from perhaps 10 milliseconds to a few microseconds — not earthshaking in electronics terms, but beyond the capabilities of a free-running crystal clock. So systems designers face two problems: first, how to generate a time base of sufficient accuracy, and second, how to convey that time information into a server.

There are several possibilities. Most direct would be a Cesium clock, but for most applications this would be vast overkill.

The next best thing to having a Cesium clock is to borrow one. Time signals locked to the National Institute of Standards and Technology's Cesium clock in Fort Collins, Colo., are available on short-wave radio from station WWV. But this, too, is a problematic time source.

Coordinated Universal Time

"A WWV receiver can be accurate to typically around 10 milliseconds, depending on the path from the transmitter to your system," Workman said. "But WWV is not a global network. Once you get outside North America, you may or may not be able to get a reasonable signal, depending on short-wave reception."

A Cesium-clock time reference is available from the GPS satellite system, however. The satellites transmit Coordinated Universal Time (UTC) as part of the necessary information for location computations, and every GPS receiver decodes it. The receivers now cost little more than a short-wave receiver, and there are no problems with global coverage.

That leaves the problem of getting the time information into the server, which also turns out to be nontrivial, Workman said. The obvious solution is to link a GPS receiver to the server via some high-speed, low-latency port and program it to send out a time stamp every so often.

But obvious isn't necessarily correct in this case. This approach bombards the server with a high-priority interrupt every time the GPS receiver decides to update the server, cutting deeply into performance for high-overhead systems. Worse, it puts the server OS' interrupt response time into the critical delay path on getting time data into the system.

"One of the key advantages we have with our Trimble Palisade NTP," Workman said, "is the way we interface to the system." The receiver, when initialized, spends about half an hour locating itself to within about 20 meters — necessary to work backward from the satellite data to the precise UTC. From then on it locks onto all the available satellites in its sky, and uses the received signals to maintain the current date and time internally with essentially microsecond accuracy.

"Usually there are at least three satellites visible, even in an urban canyon," Workman said. "So we have more than enough data to keep the time accurate, even if someone is obscuring the antenna once in a while, as might be the case with people working around it on a roof."

Inside the server, a background software task periodically interrogates the Palisade system via a serial port by asserting one of the unused RS-422 control pins. The Palisade responds with the time at the instant that the pin was asserted. This handshake mechanism removes the serial-port driver latency and interrupt response time from the loop.

Microsecond accuracy

The background task then adjusts the counters in the server's time-of-day clock to reflect the correct time. There is no attempt to manipulate the server's oscillator directly, and no need to modify any time-stamping code that uses the system clock as a reference. "Once it's up, we can typically get 10-microsecond accuracy between UTC and the host machine's clock," Workman said.

Simple in principle, but not always in practice. "The timing task was originally written for Unix systems," Workman said, "and sort of migrated to NT. But when we brought up our receivers on NT systems, it was a nightmare: We were having difficulty getting below 100-ms delays. We ended up having to rewrite the serial-port driver to correct some things Microsoft had done. We put the patch on our Web site."

The only remaining problem, Workman said, is to physically install the receiver. Because it is, after all, a GPS receiver, the unit — which includes an integral antenna — must either be on a roof or in a window that has a view of at least half the sky. Then it is connected back to the server's serial port via RS-422.

In this way servers, routers and similar equipment essentially anywhere in the world can be synchronized to UTC without significant hardware or software modification.