Computer Network Time Synchronization

Ben Rothke writes "For most people, having their clocks accurate to within a few millionths of a second is excessive. Yet there are plenty of reasons to ensure that clocks on networks and production systems are that accurate. In fact, the need for synchronized time is a practical business and technology decision that is an integral part of an effective network and security architecture. The reality is that an organizations network and security infrastructure is highly dependent on accurate, synchronized time." Read the rest of Ben's review.

Computer Network Time Synchronization
author	David L. Mills
pages	304
publisher	CRC
rating	10
reviewer	Ben Rothke
ISBN	0849358051
summary	Definitive reference on how to deploy and use NTP

From a practical perspective, nearly every activity requires synchronized time to operate at peak levels, from plane departures and sporting events, to industrial processes, IP telephony, GPS and much more. Within information technology, technologies from directory services, collaboration, to authentication, SIM and VoIP all require accurate and synchronized time to work effectively.

Computer Network Time Synchronization: The Network Time Protocol is a valuable book for those that are serious about network time synchronization. David Mills, the author of the book, is one of the pillars of the network time synchronization community, and an original developer of the IETF-based network time protocol (NTP). The book is the summation of his decades of experience and a detailed look at how to use NTP to achieve highly accurate time on your network.

While network time synchronization is indeed crucial to corporate networks, this is only the second book on the topic. Last year saw Expert Network Time Protocol: An Experience in Time with NTP, which is a most capable title. But this book is clearly the indisputable reference on the subject, given its extraordinary depth and breadth. While Expert Network Time Protocol gets into the metaphysics of time, Mills's book takes a much more rationalist and pragmatic approach, which explains the myriad mathematical equations.

Mills is an electrical engineer by training and a significant part of the books 15 chapters involve advanced mathematics. But even for those who can't manage such equations, there is enough relevant material to make the book most rewarding.

Chapters 1 and 2 provide an excellent overview of the basics of network timekeeping and an overview of how NTP works. We often take for granted that network computers have the capabilities to set their internal clock. But while the capabilities are there, the reality is that these clocks are rarely accurate and subjected to many externalities that affect their ability to provide accurate time. The book shows how highly accurate time is easily achievable; often without the need for additional hardware. The goal of book is to show the reader how they can use NTP to synchronize the time on their network hosts to within a few milliseconds.

Chapters 3 - 11 detail the internals of NTP and time synchronization. Topics such as clock discipline algorithms, clock drivers and more are detailed. For many readers, the information may be overkill, but remember that this is not a For Dummies book.

Chapters 13 - 15 ease up on the abstract mathematics and are much more readable to newbie to the world of time synchronization. Chapter 13 is quite readable and details the metrology and chronometry of how NTP measures time as opposed to other time scales.

One of the key differences is the notion of absolute vs. relative time. Relative or astronomic time is based on the earth's rotation. Since the earth's rotation is not absolute, leap seconds are added to keep UTC (Universal Coordinated Time) synchronized with the astronomical timescale.

So what exactly is this legendary thing called the second? In 1967, the 13th General Conference on Weights and Measures defined the International System unit of time, the second, in terms of atomic time rather than the motion of the Earth. Specifically, a second was defined as the duration of 9,192,631,770 cycles of microwave light absorbed or emitted by the hyperfine transition of cesium-133 atoms in their ground state undisturbed by external fields.

Since the 17th century, time has for the most part been measured astronomically via the solar day. But in the 1940s, it was established that the earth's rotation is not constant, as the earth is spinning slower than it did years ago.

Part of what NTP provides is coordination to UTC. UTC provides operating systems and applications with a common index to synchronize events and prove that events happened when timestamps state they did. UTC is a 24-hour clock system and that any given moment, UTC is the same no matter where you are located.

For the purist, UTC really stands for Coordinated Universal Time, but both terms are used. Mills somewhat humorously notes that we follow the politically correct convention of expressing international terms in English, and their abbreviations in French.

Chapter 15 concludes the book with a fascinating look at the technical history of NTP. As of mid-2006, NTP has been in use for over 25 years and remains one of the longest, if not longest running, continuously operating application protocols in use on the Internet. Currently in version 4.2.1, NTP is a well-developed, stable protocol.

For those that are simply interested in how time synchronization works, or are responsible for time synchronization in their organization, Computer Network Time Synchronization: The Network Time Protocol is the most comprehensive guide available to using NTP.

For those that need an exhaustive tome on all of the minutiae related to NTP and synchronization, this is the source. Short of a vendor and product analysis, the book covers every detail within NTP and is the definitive title on the subject.

Two new books on the subject in a year demonstrate the importance of time synchronization. While this is not likely indicative of a flood of new books on time synchronization, this book should be considered the last word on the topic."

---

You can purchase Computer Network Time Synchronization from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

ieee 1588 is where it is at

[__aapopf3474]

NTP is somewhat coarse, IEEE 1588 [nist.gov] gives much tighter timing. IEEE 1588 can be used for industrial automation.

From the intro [nist.gov]:

Measurement and control systems are widely used in traditional test and measurement, industrial automation, communication systems, electrical power systems and many other areas of modern technology. The timing requirements placed on these measurement and control systems are becoming increasingly stringent. Traditionally these measurement and control systems have been implemented in a centralized architecture in which the timing constraints are met by careful attention to programming combined with communication technologies with deterministic latency. In recent years an increasing number of such systems utilize a more distributed architecture and increasingly networking technologies having less stringent timing specifications than the older more specialized technologies. In particular Ethernet communications are becoming more common in measurement and control applications. This has led to alternate means for enforcing the timing requirements in such systems. One such technique is the use of system components that contain real-time clocks, all of which are synchronized to each other within the system. This is very common in the general computing industry. For example essentially all general purpose computers contain a clock. These clocks are used to manage distributed file systems, backup and recovery systems and many other similar activities. These computers typically interact via LANs and the Internet. In this environment the most widely used technique for synchronizing the clocks is the Network Time Protocol, NTP, or the related SNTP.

Measurement and control systems have a number of requirements that must be met by a clock synchronization technology. In particular:

• Timing accuracies are often in the sub-microsecond range,
• These technologies must be available on a range of networking technologies including Ethernet but also other technologies found in industrial automation and similar industries,
• A minimum of administration is highly desirable,
• The technology must be capable of implementation on low cost and low-end devices,
• The required network and computing resources should be minimal.

In contrast to the general computing environment of intranets or the Internet, measurement and control systems typically are more spatially localized.

IEEE 1588 addresses the clock synchronization requirements of measurement and control systems.

Origination of abbreviation UTC

[flooey]

In case anyone's interested, one of the reasons that the abbreviation is UTC is because there are a series of Universal Time time references: UT0, UT1, etc. Despite being officially "Coordinated Universal Time", it's abbreviated as UTC partly to continue the UTx notation.

Re:I've always wondered...

[hubie]

and the definition of a second was changed so that the length of a second remains constant

This isn't my field of study, but I believe the second is defined as a certain number of oscillations between two hyperfine levels of the cesium-133 atom. This was done in the late sixties to get the definition of the second away from earth rotations and tie it to something more reliable and easy to measure.

Re:Duh

[PatrickThomson]

They took the pre-existing definition of a second, and measured how many cycles happened in that second, then rounded that to the nearest integer and said "new definition which is only dependant on quantum mechanics".

Re:Origination of abbreviation UTC

[flooey]

Not so. From Wikipedia:

The very next paragraph in that article says:

"UTC" also has the benefit that it fits in with the pattern for the abbreviations of variants of Universal Time. "UT0", "UT1", "UT1R", and others exist, so appending "C" for "coordinated" to the base "UT" is very satisfactory for those who are familiar with the other types of UT.

Re:NTP gurus wanted... ?

[jimwelch]

>>about how many people out there actually need to know NTP to this degree?

NTP or acurate time?

I am sure you can find the answer to acurate time on Google or by reading the book.
But just to get us started:

  * network file sharing with central backup
  * ditto with CVS type system.
  * network databases.

GPS card

[hey]

If you really care about time why not use a GPS card in your PC.

eg http://www.visualgps.net/NMEATime/ [visualgps.net]

Offtopic, but sig related

[Anonymous Coward]

You don't by chance happen to be a nudist?

Re:Hasn't this already been written?

[Antique Geekmeister]

I agree with you in general: the man pages for NTP are quite good. However, there are a few vagaries that I certainly hope this book covers: why you always want at least 3 upstream NTP servers and at least 3 local ones if you're maintaining them (so that the 2 good ones can outvote the confused one), how to gracefully monitor the state of the NTP servers (the Nagios plugins are quite good!), etc.

Re:Summary of the book

[QuesarVII]

Even shorter still!

emerge ntp

Microsoft's version of NTP

[AB3A]

Actually, having set up the NTP servers in our network, I have to say that the Windows version of NTP draws very substantial vacuum. It's not nearly as easy to configure. It can't be queried about what it thinks of the configured time standards, and I'm not exactly sure how they expect you to manage keys.

As long as you don't give a damn about sub-second accuracy (in our SCADA system, we like to stay in sync within 7 milliseconds or less) and as long as you don't care about traceability, then I guess it's better than nothing. However, the NT version of Mills' NTP is free, it is very stable on all versions I've tested it on from NT through 2003 server, and the configuration is exactly the same as most POSIX systems.

Having been there and tried it, I have to say that Microsoft did a piss poor job with their version of NTP. Get the GNU version. It Just Works Better.

Re:NTP gurus wanted... ?

[DerekLyons]

Seriously... about how many people out there actually need to know NTP to this degree? Anyone have a rough estimate? I can't imagine any one organization would have to dedicate an individual to this sort of thing or would they?

Anyone writing hard real time distributed applications will need to know NTP this deep, or deeper. So figure, at least a couple of dozen or more individuals in the brokerage sub section of the financial world *alone*.

Re:NTP gurus wanted... ?

[Anonymous Coward]

Or - try running a distributed sonar system without NTP. We have a bunch little embedded boxes (read - flash only) for each of our sensors, like motion, GPS, etc, a two big honking dual-Opteron boxes for display and signal processing/database - one windows, one linux. All of which must be synchronised to within a millisecond or so. Easy you say? Remember that the whole system is power cycled on a daily basis, and is expected to be up and running a few minutes after power on. There is also no internet access, but we do have a GPS for a stable time source. NTP is great for us - but this is far from the usual configuration.

A book like this would very useful to us right now.

Re:ieee 1588 is where it is at

[__aapopf3474]

IEEE 1588 is much more accurate than NTP. Yes, to get greatly increased accuracy, it is helpful to have switches [hirschmann-ac.com] that properly handle 1588 traffic. However, this is not a huge issue with industrial automation, where one has complete control over the hardware. Yes, I'm not sure if running 1588 over the commodity internet would buy you much. However, if you really wanted tight timing, then 1588 is worth a look. The reason to use 1588 over NTP is if you need greater accuracy like +/- 60ns. My interest in 1588 is dealing with realtime distributed operating systems. It is starting to look like interesting things can be done if you have a really precise clock on physically distributed nodes. This could be interesting for distributed time triggered architectures.

Never use two NTP sources!

[Terje Mathisen]

First, my credentials: I've been working with NTP for more than 10 years, my personal web server, which you can find via http://www.ntp.org/ [ntp.org] (I won't link directly to try to avoid the /. effect.) have hosted windows binaries of the official NTP distribution for some years now.

Since the original article didn't mention this, I would like to warn NTP users against ever configuring two servers! The reason is that NTP by design requires a plurality of all sources to agree on what the time is, before it will believe any of them.

This means that if you have two sources that disagree slightly, you can relatively easily get into a situation where your local machine decides to distrust both and simply start drifting away. I have actually seen this happen multiple times.

This means that you need to configure either a single or at least three servers, and if you want fault tolerance you actually need four, since that will leave three even when one of them fails.

Terje

Re:NTP is great, except if you need it in Windows

[pe1chl]

Common PC hardware can't keep a clock within this accuracy

Why not? You must be thinking about the CMOS clock?
Current PC hardware has high-resolution timers that can be synchronized to within microseconds using NTP.

Re:Microsoft's version of NTP

[pe1chl]

Microsoft did not implement NTP. They first needed it to be simplified to "SNTP", which essentially is what they always did: send a query, receive the result, and put the timestamp in that result in the clock.
A full NTP implementation includes a PLL that locks the clock to the consecutive incoming timestamps. This filters out jitter and ensures that the system knows about the inaccuracy of the clock oscillator. It uses this information during the intervals between incoming timestamps.

So, an NTP-controlled system smoothly advances time staying as close to real time as possible, while a Microsoft system has a sawtooth pattern and may even step the clock backward when a query happens to be delayed in the network.
Don't use SNTP outside of a LAN.