If your computer's clock is wrong, scheduled tasks, such as backup and virus scans, might run during the day, or your log files could become worthless. The pool.ntp.org project has an answer.
In theory, setting a computer's clock over the network is easy: simply send a query to the time server and get the current time in return. For low-precision usage on a trusted network, this process does indeed work fine, as demonstrated by the old UNIX “time” protocol. For today's Internet, however, and for millisecond (ms) or even sub-ms precision, problems such as authentication, reliability of the time servers and network delays need to be considered. This is where the Network Time Protocol (NTP), with its reference implementation, steps in. The specification and the reference implementation are being written by Professor David Mills of the University of Delaware, his graduate students and many other volunteers.
To allow everybody to use NTP to synchronise computers' clocks over the public Internet, Prof. Mills has long maintained a list of public time servers. Most of these servers are operated by universities or national standardisation organisations. Today, this list is maintained by the NTP Public Services Project, under the umbrella of the Internet Systems Consortium. However, the growth of the Internet and the prevalence of small, cheap appliances, such as cable or DSL routers, with built-in NTP clients lead to a rapidly growing load on these public time servers. One of the most famous cases involved a severe firmware problem in a range of such devices, resulting in more than 150Mbps of NTP traffic to the University of Wisconsin's NTP server.
After reading the discussion of one time server operator's request to be taken off the public time servers list, I wondered if there was a better approach to this whole problem—instead of having tens of thousands of clients targeting one single time server, the load should be distributed on many different time servers all over the network. So I went ahead and created the original time.fortytwo.ch DNS round-robin in January 2003. The project quickly acquired many interested volunteers and was well received by Prof. Mills and his team. It soon became the pool.ntp.org project with a somewhat more official status.
During the next two years, the project continued to grow, thanks to all the people who mentioned it in various Web forums, HOWTO documents and the like. Today, the project consists of more than 300 servers, offering service to tens of thousands of clients, in a very rough estimate. Also, pool.ntp.org is now the default time server in several operating system distributions, including Debian GNU/Linux, NetBSD and Gentoo Linux.
So far, the growth in servers could more or less match the growth of the user base of the project. However, the future remains challenging, and discussions on the project's discussion mailing list have shown that the project needs to deal with an inherent conflict between providing easy service for as many clients as possible and assuring good quality of the time servers participating in the project. That aside, the big challenges for the near and medium future are:
IPv6 integration.
More automation—currently, I process server additions and removals mostly manually.
Better, more novice-friendly documentation on the Web.
Of course, we always need more servers too.
And above all, we need to deal with abusive clients. In one example, the six worst clients were responsible for 25% of the traffic on one time server.
Although the first three items are not technically difficult and the “getting more servers” plan should see a big leap ahead with the publication of this article, we don't currently have a good plan to educate the hundreds of users with sub-optimally configured clients. Due to their number, they are a serious problem for the project. At the same time, the bandwidth per client is small enough that the big ISPs' abuse departments are not prepared to help in any way.
In the medium to long term, we will need to face the issue that DNS round-robin, as currently implemented, is not a good solution for load balancing on the scale of several hundred servers with a hundred thousand or more clients. Wide deployment of IP multicast together with the existing multicast support in ntpd would be a good solution to this problem, but obviously not one the NTP and pool.ntp.org crew can deploy on their own. Another possible solution is to make the ntpd dæmon aware of the pool.ntp.org project and, in some generic way, similar such databases and have the dæmon configure itself to use such a resource.
Finally, on a personal note, I honestly can say that it was fun to get this project started and see it grow, but I now see the need for somebody new, with fresh ideas, to take over from here. Indeed, as I write this, I am talking with several people about the project's future, and I am certain that the involvement of a new “father figure” will do the project much good as new ideas are looked at and implemented by a new crew.
Resources for this article: /article/8454.