October 03, 2001, 5:35 PM — About ten years ago, Dennis Ritchie posted the
question "What time is it?" on
net.general, then the catch-all for USENET
traffic of interest to the masses. Dennis was poking fun at messages
(and their authors) that arrived several days after bearing any sense
of relevance. The "what time is it?" probe demonstrated that USENET
isn't a good source for a watch-setting consensus. The underlying
problem, however, is not setting just one clock on one machine, but
instead keeping an entire network of machines synchronized with
respect to a global, reliable time source and with respect to each
Accurate time-keeping affects many day-to-day functions as well
as issues critical to system administrators:
- File modification times are consulted by
skewed desktop clocks may result in erratic actions.
requests. Client clocks that stray into network tardiness result
in rejected requests.
are used to sequence events must refer to a time base that is not
log messages from multiple hosts require a single, global timepiece
for the network. You can't track a performance problem across several
machines if you can't lay out events on a single, absolute timeline.
Put simply: how do you keep the software watches of hundreds or
thousands of systems synchronized, particularly when they are spread
around the world, and how do you make sure that your sense of time
matches that of the rest of the computing world? This month, we
address the question of what to do when your sense of time bombs.
We'll start with an overview of how Unix systems keep track of time,
We'll look a simple method for synchronizing Unix system clocks, and take
a peek at the Network Time Protocol, a small dose of Swiss perfection
you can bring to most Unix and Windows NT machines.
A brief history of time, in 64 bits or less