The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers.
Adrian von Bidder created this project after a discussion about resource consumption on the big timeservers, with the idea that for everyday use a DNS round robin would be good enough, and would allow spreading the load over many servers. The disadvantage is, of course, that you may occasionally get a bad server and that you usually won't get the server closest to you. The workarounds for this is respectively to make sure you configure at least three servers in your ntp.conf and to use the country zones (for example 0.us.pool.ntp.org) rather than the global zone (for example 0.pool.ntp.org). Read more on using the pool.
The pool is now enormously popular, being used by millions of systems around the world. It's the default "time server" for most of the major Linux distributions (see information for vendors).
The pool project has since 2005 been maintained by Ask Bjørn Hansen, Develooper and a great group of contributors on the mailing lists.
go up
Subscribe in a reader
Subscribe to NTP Pool News by Email
Happy New Year everyone! Please take a moment to remind your fellow sysadmins about registering their servers in the pool if they have servers meeting the requirements (~100% uptime and a static and stable IP address).
As mentioned earlier the pool system now has partial support for IPv6 servers.
It's currently limited to just getting the servers registered though! They are not monitored and the pool DNS system does not give out AAAA records.
The plan is to start testing various approaches to IPv6 support during 2009. Stay tuned.
This morning I pushed the latest version of the NTP Pool Server code to www.pool.ntp.org. The news are:
Runs on the code from the git repository
Translations are back! The end-user portions of the site is now available in English, Dutch and French.
Partial IPv6 support (thanks to Martin von Löwis). More about this in the next post.
Apache 2 / mod_perl 2 support - this makes it much quicker to setup a development sandbox.
Various bugfixes.
We hit another milestone in the last few days with 1000 active servers in Europe!
Now of course we need to get more servers added so we don't slump below that number again - right now the number is 999. Who will take us back over 1000? :-)
Growth in North America have practically stalled on the other hand; we could use more servers there too (and as always in Asia, South America and Africa, too).
Most people don't know, but the NTP Pool web site and monitoring software is actually licensed under the Apache Software License 2.0.
I did that to make it easier if at some point the community decides that my stewardship of the NTP Pool isn't good enough. Since installing the pool site doesn't make much sense other than for development I don't make ordinary releases, but all the code is available in my public subversion repository.
On a somewhat related note the project has an entry on ohloh. If you are an open source contributor and haven't seen that site before, you should give it a look.
I've been adding support to the NTP Pool site for translations again.
Before I took over the site it was translated in a bunch of languages, but as the site got dynamic features and more pages we lost that. Now it's back!
If you are interested in helping then send me a mail at ask@develooper.com. Experience with gettext (".po") files or Locale::Maketext lexicons and with version control (Subversion specifically) will be helpful, but if you are willing to learn then it isn't required.
Early this morning (PST) we had a few hours of "sub-optimal" performance on the monitoring server. A hundred servers or so were marked "bad" and got unnecessary warning mails because of it. users of the pool should not have been impacted. Work is in progress to permanently improve on this.
We were upgrading the servers that the pool web site is running on yesterday and had an outage for a few hours. It should all be back to normal now.
The upgrade was (mostly) about getting all our servers up from RHEL 3 to version 5 (before we had mostly RHEL3 boxes and a few with 4 and 5 ...). Now when they are all the same it's easier for us to manage the configuration across all the boxes and soon we'll have some more high availability things setup for the pool system. Long term the goal is to get more of the infrastructure completely distributed, but the website (for showing stats etc) will likely still be in just one place.
A relatively frequent question I get is "when will the pool support IP v6".
It's on the "road map", but not too high up on the list. Months ago I wrote up the current plans on the NTP Pool wiki.
Speaking of the wiki - eventually I'll get that moved over to the NTP Public Services Wiki.
With some assistance of Guillaume Filion the fifth pool.ntp.org is now running the new DNS software, too. It's located in Germany. We have a few more servers offered by volunteers ready to be setup and we'll work on that over the next week or so and then we'll experiment with how best to use them to get the best possible performance for the pool users.
The difference is that now pool operators shouldn't see "spikes" in traffic, unless a big ISP caches the DNS entry and gives it out to many many many clients. If that happens we'll experiment with adjusting the TTL of the served records (The "TTL" is the time-to-live, the time the data should be cached by the end-user nameserver).
We deployed the new DNS system to 4 out of the 5 pool.ntp.org nameservers. We have several new systems that volunteers have offered ready to be setup, but no time to configure and test them yet. Hopefully it will be done within a week or so...
There's a description of the new system on the DNS page on the wiki.
We've noticed an issue with the new system that it seems too eager to send traffic to the high bandwidth systems rather than the low-bandwidth ones. I am looking into it, although not with too much urgency as none of the high-bandwidth server operators have gotten more traffic than they can handle.