As Chicago said back in 1970, does anybody really know what time it is? The message of the song is that we really shouldn’t care. But when it comes to our computer systems and other gadgets, having an accurate clock matters.
Widely used security protocols like Kerberos (which Windows uses to authenticate access permissions to folder shares) depend on the clocks of different computers being synchronized—if the clocks differ by more than a few minutes, Kerberos-based authentication attempts will fail. If you are a software developer, incremental build tools like make rely on the time stamps on source and object code files being accurate, regardless of the system where the file was created or modified. Widely used file synchronization protocols like rsync can also rely on file time-stamp information, depending on how they are used. These are but a few examples; in our increasingly wired world, many of our devices really do depend on knowing the time and assuming other devices to which they talk know, as well.
You may be thinking, "But wait, my computer’s CMOS clock keeps track of the time, so why do I need to care?" The problem is, your computer’s CMOS clock typically has worse accuracy than a cheap wristwatch. As computer motherboards became commodities, manufacturers started cutting corners on things like accurate CMOS clocks. Over a period of just a few weeks, that clock can drift way off. If that weren’t bad enough, when the computer is actually running, the OS keeps track of the time itself instead of relying on the CMOS clock. However, the clock source used by the OS (typically derived from the CPU clock) can be even more inaccurate than the CMOS clock—a clock that drifts by a minute or more in a single day isn’t uncommon.
Given that nearly every computer is now connected to the Internet, the solution seems obvious: synchronize the clock to a known accurate source online. All modern OSes provide a means to configure an Internet time service to keep the clock synchronized. But who provides the accurate time source to which you’re synchronizing? That’s a very good question… and a lead-in to a brief history lesson and the point of this whole blog post.
A brief history of (network) time
(With apologies to Stephen Hawking.)
The need for accurate time synchronization between computer systems was already recognized as an issue in the early days of the Internet, and it led to the development of the Network Time Protocol. Back in those days, the number of systems connected to the Internet was small, and usage was limited to government, military, and educational institutions. These same institutions provided a small number of central time servers that were used to synchronize time for all systems across the Internet.
Then the dot-com boom happened, and everybody got online. The number of systems connected to the Internet rose exponentially, and even embedded devices started using the NTP protocol to keep their clocks accurate. Existing time servers could barely keep up with the load; and if that wasn’t bad enough, several manufacturers of consumer networking equipment inadvertently launched DOS attacks against several public NTP servers by hard-coding the IP addresses of specific time servers into the firmware of thousands of devices. D’oh!
Clearly, something had to be done. Enter the NTP Pool Project. Many of you are already familiar with distributed computing in the form of Internet-based computing efforts like Folding@home. The NTP Pool is essentially the same concept applied to time servers, i.e. distributed time serving.
How the pool works
The concept behind the NTP pool is fairly simple: use a number of systems distributed across the Internet to serve accurate time to everyone. The servers in the pool ultimately get their time from accurate time servers provided by governments, universities, ISPs, and anyone else who operates a public Stratum 1 or Stratum 2 time server. (Stratum 1 servers get their time directly from a known accurate source like a GPS or WWV Radio, while Stratum 2 servers get their time directly from Stratum 1 servers. Everyone else is Stratum 3 or below.)
The NTP Pool Project operates a DNS server. When you configure your system or device to use an NTP pool server like us.pool.ntp.org, you’re actually asking the NTP Pool DNS server to randomly assign you to a set of time servers that are (hopefully) geographically close to you. The default NTP servers Microsoft Windows uses when you enable Internet time synchronization (time.windows.com) are part of the NTP pool, as are the default time servers configured by all of the major Linux distros. So, you’re probably already using the NTP pool without even knowing it!
Joining the pool
If you have an always-on broadband connection, you can help the NTP Pool Project. By adding your system to the pool, you will improve the accuracy of Internet time service for everyone by helping share the load. You need a static IP address and the ability to unblock/forward UDP port 123 on your router or firewall. You also need to run the reference NTP server implementation. That’s a no-brainer for UNIX/Linux users, since the server is probably already included on your system. For Windows users, you will need to install the Windows port of the NTP reference server, since Windows doesn’t include one out of the box.
When you join the pool, you tell the NTP Pool the speed of your broadband connection. The NTP Pool will include you in the server rotation at a rate that depends on your broadband speed, only consuming a small fraction of your available bandwidth. If you’re still concerned about bandwidth usage, you can configure a value lower than your actual connection speed to throttle the usage back even further. When joining the pool, you’ll want to configure a few Stratum 2 servers near you from this list from which to synchronize your own server. Unless you’re willing to do some extra legwork to get permission from the administrator(s) of the upstream server(s), only select servers that have an open access policy and no notification requirement (as noted in the list). If your ISP operates an NTP server for its customers, you can also use that as one of your upstream servers.
The NTP Pool project monitors the accuracy, network latency, and availability of your time server by polling it twice an hour, and assigns you a score based on this monitoring. Periods of high network latency, unavailability, or instances when the time your server reports is off by more than 100 milliseconds will result in deductions from your score. Conversely, periods of low latency and high accuracy cause that score to rise. Your system is only included in the pool rotation when your score is above +5 (scores range from -10 to +20).
You can access the monitoring data for your server on the NTP Pool web site. The screenshot below shows some of the monitoring history for my server. The dips and peaks in the "offset" graph (and corresponding drops in score) correspond to periods of high Internet activity (i.e. downloads) on my DSL connection, which trashed my network latency.
So, dive in! The water’s fine… and the next time someone asks you if you really know what time it is, you can give them a definitive answer.