The NTP Pool is migrating its central infrastructure from Equinix Metal to two smaller, globally distributed clusters. Equinix Metal is sunsetting later this year, so the project must move.

Equinix Metal — originally Packet — hosted the NTP Pool’s central infrastructure for almost seven years. The web application, databases, DNS zone building, monitoring pipelines, observability, development and beta environments all ran there. It was the backbone that kept the entire pool management system running.

The relationship started with Packet, whose team went out of their way to help during an emergency migration in 2019. Equinix continued that same level of support after acquiring Packet. Their generosity made it possible for a volunteer-run project to operate infrastructure at a scale that would otherwise be out of reach. We would gladly have stayed — Equinix Metal was an excellent home for the project.

The NTP Pool is upgrading its monitoring system to support more monitors and provide better coverage for all servers. The current monitoring system (v2) supports a smaller number of monitors with just “active” and “testing” states. The new monitoring system (v4) can support many more monitors, makes them easier to provision and operate, and introduces a new “candidate” state for better resource management.

Key Improvements in v4

• Expanded capacity: Support for significantly more monitoring nodes worldwide
• Better coverage: Enhanced geographic distribution and network diversity
• New candidate state: Improves resource allocation and provides backup monitoring coverage
• Easier operations: Simplified setup and management for monitor operators

With the new monitoring infrastructure, we’ll have a world-class globally distributed monitoring system to match the unparalleled NTP service. The monitoring system will better test local conditions across the world and give us new and better tools to diagnose network problems across countries and networks.

This weekend the system that monitors the NTP servers in the NTP Pool got a major overhaul!

NTP servers are now monitored from a number of monitors across the world, usually closer to the server than the single monitor was before.

One of the most frustrating things about operating an NTP server in the NTP Pool was how random network issues far away from the server would impact the score. Sometimes cause an email to be sent to the operator about potential problems.

This year the NTP Pool Project has been serving time to the world for 20 years!

Trillions and trillions of DNS requests have been served to billions of clients, with the NTP requests handled by thousands of NTP servers across the world day and night.

Development on the project ebbs and flows, but maintenance and upgrades on the production infrastructure is consistent – and constant.

Our community is active; and the NTP server operators even more so with almost 2,000 operators managing the 3,000 IPv4 NTP IPs and 1,600 IPv6 IPs active in the system.

The main website (www.ntppool.org / www.pool.ntp.org) doesn’t set any browser cookies. Some access logs are generated strictly for diagnostics purposes. No long term storage or analytics on user behavior is attempted.

The manage website (manage.ntppool.org) sets a cookie on login to track authentication. The site also keeps a record of the account information you provide and NTP server IPs that are registered. We try hard to not keep any information that’s not essential for operating the system.

Packet is awesome.

When we started planning our recent unplanned server move, we investigated options for having not one, but two sites, for the “hub” systems for the NTP Pool. With 4000 NTP servers and hundreds of millions of clients using the system, it really should be a given!

Evaluating our options on a ridiculously short timeframe, Packet stood out as an interesting choice, though we were a little apprehensive at first if their setup would be too unusual compared to more familiar options.

After a quick chat with some of the friendly staff at Packet, we were off to the races to see if we could get everything migrated in less than a week of nights and weekends. If we could, we’d be able to move the physical servers the following Sunday without downtime to any critical services, and get us closer to having proper redundancy.

Working with the Packet system has been fascinating and extremely productive. Despite having done this sort of work for several decades, it was a surprise how mixing familiar capabilities, APIs and abstractions opened new ways for quickly building and managing powerful, reliable and scalable infrastructure.

The beta site has been updated with new features for managing the accounts. Until now each server had to be associated with just one user login. In the new system servers are associated with an account that can have multiple user logins.

If you can, please try it out and post bug reports or suggestions in the development forum or via email.

The NTP Pool consists of (as of this writing) more than 4000 NTP servers provided by the community, about 40 DNS servers and a good handful of “hub servers” running the website, databases, monitoring (for NTP, DNS, etc) and a bunch of other software to keep the system going.

This spring we learned that the facility the systems were in was being decommissioned and we needed to find other arrangements, quickly. A few weeks later we had some options lined up and a long list of work to make it a smooth migration.

As you might have seen in the news or from the US CERT, there’s an internal counter in the GPS messages that will “rollover” this week.

Poorly implemented GPS receivers might lose track of time because of this.

Many servers in the NTP Pool are using GPS signals to set the time, either directly or indirectly from another server that listens for GPS signals.

The expected impact on users of the NTP Pool is very little or none at all. The NTP Pool monitoring system will detect any systems that are wildly off and have them removed from DNS responses within typically 10-20 minutes.

Daniel Ziegenberg wrote a tutorial for Digital Ocean on configuring NTP for the NTP Pool on Ubuntu.

Oliver Nadler has another tutorial covering non-Ubuntu, too.

There’s a new forum for discussion related to the NTP Pool at community.ntppool.org. Please come join us. There are a couple interesting threads about the recent leap second and lots of empty space for your questions or suggestions. :-)

Since last Tuesday some countries have seen an excessive number of queries to the NTP Pool.

After much detective work on nanog (conclusion) and the #NTP IRC channel it was determined to be a buggy Snapchat app update.

A network switch failed causing an outage for the management system and the NTP Pool website. The DNS and NTP services should only be minorly affected, even if the outage lasts a little while.

I’ll update status website with updates.

The IETF has published a new version of NTP Best Current Practices documenting learned best practices on how to run NTP servers and clients.

If you know a little about the NTP protocol reading it will be a quick way to learn more about how it works “in the wild” (including on your own systems).

Thanks to the kind folks at statuspage.io we now have a system status page. It’s also available at an alternate domain.

Most of the data is updated manually, so it won’t be any better than the busy humans can manage, but it’ll be a better system for giving system updates than posting here (or on the dicussion mailing list).

The new login system that was tested on the beta site has been enabled on the production site.

The login system is now using Auth0 to add more login options than yet another username and password. If you have a Github, Google, Microsoft or other supported account you can use that to login.

If you are one of the many existing users, you have to create a “new account” (sign up again) with the email address you previously used to login to your account. No passwords have been transferred over.

This week we’re testing using Auth0 to login on the beta site. This will hopefully make the user account management much easier for everyone.

The beta site is a full installation of the system running with a separate database that gets new code before the regular site.

As you might have seen a few days ago several potentially critical security vulnerabilities in all versions of ntpd were announced.

Most OS’es have released back-ported fixes. Depending on your specific ntp and network configuration you might not be exposed, but the easiest way to make sure your systems aren’t vulnerable is to apply the software updates and make sure ntpd has restarted on the fixed version.

Alternatively you can read the announcement page linked above carefully and make configuration changes to mitigate the issues.

If you have built ntpd from source, the easiest fix is to update to 4.2.8. If you have trouble building that version, there’s a “4.2.8p1-beta1” version available now from support.ntp.org as well with some fixes.

If you aren’t already subscribed then you might be interested in subscribing to the NTP Pool discussion mailing list. For general discussion of NTP there’s the comp.protocols.time.ntp newsgroup.

If you are using the standard ntpd daemon to serve time to the public internet, it’s important that you make sure it is configured to not reply to “monlist” queries. Many routers and other equipment are included in this.

The configuration recommendations include the appropriate “restrict” lines to disallow any management queries to ntpd. Most Linux distributions will have an updated version by now that just disables the “monlist” queries, that will also solve the primary problem.

The NTP Support wiki has more information.

If you operate a network you can use the Open NTP Project to see if you have vulnerable devices on your network.

This week we had a period of weird behavior for the monitoring system for (mostly) German IPv6 servers.

After much back and forth on the mailing list and numerous debugging sessions we got this information from a network engineer at Hurricane Electric:

The NTP Pool “backend systems” are moving racks at Phyber. To minimize the risk of things going wrong we’re doing it the old-fashioned simple way of turning everything off, moving it and turning it on again. It will mean about an hour where servers are not monitored and we can’t add new ones or access the www.pool.ntp.org site.

In the new rack there’ll be more power available so when the move is done we’ll have more capacity.

Over the last couple of months we had a couple of the “central servers” fail. It hasn’t caused any service outage for the NTP clients, but some of you might have noticed that the manage NTP Pool site has been sluggish at times.

A few months ago I bought a few new servers and sent them down to our friends at Phyber Communications who wired them up in their hosting facility. Over the last weeks I’ve added puppet declarations to configure them and since earlier this evening they’re in production for the web sites and a few other services.

Over the last month the NTP Pool has gotten the biggest upgrade it has had in years. The changes has given us much more scalability and performance.

As you might know, the NTP Pool system is essentially a monitoring system and a smart DNS server. Server operators register their server in the system, the monitoring system checks and evaluates the submitted servers and the DNS server gives end-users a (hopefully) local selection of servers, weighted by preferences given by the server operator and other factors.

Last month there was a big change to the DNS server.

For years the geodns server has had a misconfiguration so users in Great Britain by default (accessing the non-country-code domain) would get a European server rather than a more local one.

The zone in the NTP Pool system has always been called ‘uk’, but the GeoIP library returns ‘gb’ for the relevant users. Oops! The system didn’t have a ‘gb’ zone configured, but knew it was in Europe so would fall back to that.

To safely upgrade some of the DNS configuration infrastructure updates to the DNS data will be suspended for 20-45 minutes. Some parts of the website might also return errors while everything is being updated.

For end-users of the pool there should be no interruption.

Update Maintenance was completed in 20 minutes. The changes were in part to get ready to deploy a new Go based DNS server to replace the current DNS server.

Meinberg have since long generously been supporting the NTP Pool and other open source projects. The monitoring system uses a Meinberg NTP server for “reference time” when checking the more than 3000 servers in the pool. I can’t recommend their equipment or expertise enough.

This month they are giving away in a raffle seven DCF77 computer clocks and three GPS time receivers to current and soon-to-be participants in the NTP Pool.

The form and rules are short and simple, but the deadline is July 29th, so don’t delay!

The client base for the NTP Pool continues to grow, so we also need to increase the number of servers. Being a “public utility” of sorts (you likely use it for some computer or device in your house, office or both even if you don’t know it), we need help from, well, the public. At least the particular kind of public who is running a server or two with static IP addresses and know how to configure a new daemon on it.

Today I am experimenting with hosting www.pool.ntp.org through Fastly. If you don’t know about them, they make an excellent CDN based on Varnish serving billions of requests a day.

The downside is that it is IPv4 only (currently), but then all the “static assets” (CSS files, images, etc) were already served by them, so using the site with only IPv6 was not a good experience.

Fastly is also hosting Perldoc.perl.org and have been doing so for a while.

Some months ago our friends at Phyber setup a few more servers for the NTP Pool project. Over the last months I’ve been moving services to them to make the NTP Pool infrastructure run faster and with more redundancy.

The old RRD based graphs (deprecated a few months ago) are still being used a bit, but really don’t play well with having multiple servers. Over the last week I changed the site to generate the offset and score graphs via the same D3.js based system and PhantomJS.

Today I updated the graphs from being generated by rrdtool to be generated with Javascript and SVG using the wonderful d3.js library. You can see an example of the new graphs or if you have a server in the pool you can use the new graphs.

There are a lot of things I wanted to do that using RRD made hard. Splitting the central parts of the system across more servers than the 2-3 it’s running on now. Supporting multiple monitoring nodes. More interactive graphs. Showing historical data. Etcetera.

As announced some days ago on the pool-dev mailing list, yesterday I moved the “manage your server” section to a separate site. This helps keep the main site fast and made it easier to make all connections to that site encrypted.

Today the NTP Pool site got some changes to run better and faster. In the process there was 10 minutes of downtime late Tuesday (pacific time) and through much of the day Wednesday some pages might have loaded in a language that wasn’t your usual preference.

World IPv6 Day is over, but we’ll continue to serve AAAA (IPv6) records for 2.pool.ntp.org (and 2.europe, 2.fedora, 2.debian, etc).

So far no problems have been reported, even the servers going through IPv6 tunnels seem to work fine.

We already have almost 200 IPv6 servers in the pool; though that’s less than 10% of all the pool servers and they’re mostly in a handful of countries versus the wide deployment we have for IPv4.

While the system is rebuilding some internal statistics, monitoring of some of the IPv4 servers in the pool have been suspended. They’ll be reactivated in about 6 hours. All servers with IDs below 8500 are being monitored again after a break of a couple of hours.

In addition all IPv6 servers are being monitored now and are slowly increasing their scores [for inclusion in the “2.” pool](http://news.ntppool.org/2011/06 /experimentally-enabling-ipv6.html)!

If you are following the pool mailing lists you’ll have seen that the last days have carried a flurry of activity as new code for IPv6 support (and distributed monitoring) has been tested on the “beta pool” site.

June 8th is World IPv6 Day where many sites small and big will enable the IPv6 protocol for the day to help test everyones IPv6 readiness.

Here at the NTP pool we are today enabling monitoring of IPv6 servers; and over the next 12 hours we will start in a limited fashion to serve AAAA (IPv6) DNS records to clients asking for them. Right now the pool site is enjoying a brief break while the new code and database updates are being deployed.

One of the database replicas had some corruption; so I took down the primary database briefly to run some consistency checks there, too. This is taking down the NTP Pool website and delaying some of the monitoring.

Everything will be back shortly.

Today the NTP Pool site was upgraded to run on Plack and Starman instead of Apache.

Please let me know if you encounter any trouble!

This was a bit of work to get done and with this done I’ll get back to adding new features to the system. First up: Integrating some of the contributed translations and finishing the changes to support distributed monitoring and IPv6 support that Martin von Löwis started a while back.

“pool.ntp.org” is serviced by a number of DNS servers. One of them, a.ntpns.org, is actually several servers in an anycast cloud.

Until today it was just served by two nodes, one in Los Angeles and another in Luxembourg (both provided by Solfo). Today a third node in Northern California is joining in, hosted by Sonic.net!

If you are able to provide a server (most virtual servers work, too) on a network with BGP routers to join the anycast cloud, please email ask@develooper.com.

Earlier today the website and monitoring system had several 10-15 minute outages while the databases got moved around; backups reconfigured etc.

Our friends at sonic.net have for years provided some servers that are used for backups and auxiliary functions to the main servers hosted by Phyber.

Recently Sonic.net also started hosting one of the excellent GPS Time Servers donated by Meinberg and when the system eventually starts doing distributed monitoring their servers will likely be the first “second monitoring system”.

The pool servers are having a 45 minute outage to be moved to a new datacenter.

The primary server in the pool system had a brief outage today after running out of memory. All is better now. Because of the distributed nature of the service itself, serving of time to ntp users around the world wasn’t materially affected.

Adrian von Bidder has generously hosted and maintained the mailing lists since he started the project 7 years ago and it’s time for the lists to move. In the next few days the lists will move from fortytwo.ch to lists.ntp.org.

The ’timekeepers’, ‘i18n’ and ‘dev’ lists will be moved over; but the announcements list will be discontinued since de-facto the news.ntppool.org site is where the announcements are. You can subscribe either with the Atom feed or via Feedburner’s email feature at the mailing list page.

Since Saturday morning the NTP Pool server have had trouble routing to some servers in the pool system (about 5%). This was too few to trigger the “help help, something’s wrong!” alerts; so thanks to those of you who sent in tickets!

I opened a support with our provider and hopefully the issue will be resolved shortly.

The monitoring server is on the same network as www.pool.ntp.org (in AS 7012) if you have trouble and want to check traceroutes or BGP information from your end.

If you are IPv6 connected, the www.pool.ntp.org site will now be delivered to you via IPv6.

I did tests on a hundred thousand visitors to the site and nobody who could connect with IPv4 had trouble talking to a site with both “AAAA” and “A” records. The test only included users with javascript however, so it could still miss appliances, older boxes etc. More tests are needed to make the pool.ntp.org service “ipv6 enabled”.

In our ongoing process of getting the NTP Pool IPv6 compatible we took a first (small!) step getting the website partially available via IPv6. For now it’s via an IPv6-only hostname: www6.ntppool.org.

So far the anecdotal reports are that it’s working fine for people with IPv6. The next tests will be to see how connectivity is affected for everyone else if a host has both AAAA (IPv6) and A (IPv4) records in DNS.

The pool keeps growing (although we still need more servers).

Recently we’ve added zones and servers in Costa Rica, Venezuela, Serbia, Croatia, El Salvador and New Caledonia.

But we need more servers all over the world. In smaller developing countries internet use is picking up and local servers will help. In bigger countries usage is also growing faster than the number of servers; so extra help is needed. We’re getting close to 2000 active servers - but for millions and millions of users we need more.

Sometimes I’m asked if the NTP Pool really needs more servers. The answer is yes, always!

While the number of servers has grown nicely over the years, so has the number of users so we need

The only (tricky) requirement is that you have a static IP address and expect the server (and IP) to be around for a long time. ntpd doesn’t deal well with changing IP addresses (yet), so this is important.

As mentioned a few months ago, NTP operates exclusively with UTC time. If your system is (typically) one hour off after syncing with the NTP Pool then it’s because your operating system needs to be configured with the correct timezone and daylight saving time setting. If you live in a place that recently changed rules for daylight saving time you need to make sure you have the latest system updates installed.

The goal of the NTP Pool is to provide accurate time to everybody. Though internally it’s really about serving DNS requests. Quite a lot of them, and ideally fast.

Through history we’ve ended up with using the ‘pool.ntp.org’ domain for client access which for performance isn’t really optimal, but it’s what we have. Through a bit of administrative division it ends up that just to find out who to ask for the IP of ‘1.fedora.pool.ntp.org’ you have to send a whole lot of DNS requests out.

Due to the distributed nature of the pool system we don’t know exactly; but based on some sample measurements we estimate that the overall pool system on average handles somewhere between 40 and 120 thousand NTP requests per second.

If we assume it’s 50,000 a second, that makes a bit over 4300 million requests a day!

In a year that’s about 1500 trillion (american) / billion (other countries) requests a day. (1576800000000, if I’m counting the zeroes right).

In many places around the world March is the month of changing clocks as daylight saving time comes and goes.

Usually a number of users write to tell me that the NTP Pool is an hour off during this time and in the fall when clocks change the other way. Happily it isn’t so; because NTP is based on the almost stable Coordinated Universal Time (aka UTC).

If you use NTP and your clock is an hour off, you either need to update your operating system with the latest patches for the time zone information or you need to check that your time zone is configured correctly and “adjust automatically for daylight saving time” is enabled if that option is provided.

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.

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.

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).

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](http://log.perl.org/2007/12/upgrades- mostly.html) 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 (now a dead site…).

With assistance from Guillaume Filion the fifth pool.ntp.org name server 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…

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.

On hearing how many people had sent in applications for the equipment giveaway our friends at Meinberg offered us some more equipment!

For diversity from the GPS units the extra 3 systems will be DCF77 cards (PCI or PCI-Express).

Since DCF77 only works in Europe we’re planning to give them out there and then pick hosts in the rest of the world for the GPS units.

Also - in particular one of the locations having offered to host the LANTIME server is ideal as a future home for the pool system in general, so the LANTIME (also donated by Meinberg) that I’m currently using will also be sent out (location to be determined).

I’ve setup a weblog for posting news about the NTP Pool project. This will be much nicer and hopefully make it easier to get slightly more frequent updates. The old process had me updating the list of news by editing HTML on the site (or rather, edit in my development copy, commit to subversion and then run the deployment to the site).

I’ve “imported” all the old news into the weblog and soon I will update the main site so it pulls the recent news automatically.

Three awesome news items today:

1: We're announcing the great Meinberg GPS time equipment giveaway. Over the next months we're (thanks to Meinberg) giving away thousands of dollars worth of high quality time-keeping devices.

2: We got a brand new design and layout on the pool site! Many more updates are coming.

3: The pool is the default ntp service in several of the big Linux distributions (Fedora, Debian, RHEL, CentOS and many more). For this reason we really really need more servers to help with the traffic. Hopefully the equipment giveaway will help on this. Please mention it in your weblog or wherever else appropriate.

On a related sidenote we've started alpha-testing a new system for distributing traffic to the servers more evenly and with much less "spikes" in the traffic.

We are getting close to one thousand active servers in the pool system! The pool system has gotten a major software upgrade, most notably safely letting the server operators do more without having to involve me. Please email ask@develooper.com if you see anything odd.

Coming up on the todo list is revamping the monitoring system. With the help of a donated time server generously donated by Meinberg I am working on a better and distributed monitoring system.

The NTP Pool project now has a wikipedia entry.

The system has been changed a little so we now have separate counts for "all servers" (almost 700 servers!) and servers in the global pool (+600 servers!). The global is by far the busiest, as most users don't pick a country or continent zone.

I've also done some more measuring and estimating of the client population and my best guess is that somewhere between 2 and 6 million client systems are using the pool.

The new information for vendors page is up! Please let me know if your operating system/appliance/software vendor is using the NTP Pool but isn’t using a vendor zone.

Welcome Slashdot readers. The Slashdot story was that we had reached 500 active servers, but since the story was posted another 50 or so servers joined us! This is great, thank you everyone. The only way we can keep the load on each server reasonable is by adding more servers quickly. If you can, please join. More than 500 servers in the pool might sound like a lot, but our best guestimates puts the number of clients at either hundreds of thousands or millions of computers.

You can now add your NTP servers (and only your own, please) via the new web interface. Please email me if it doesn't work as expected.

You can now browse the available zones. Also, I split up the front page into a few smaller pages. I've fallen a little behind on adding servers. I'll catch up soon and get the self-service web interface done.

I've added a page for server admins to login and see their servers as they are listed in the pool system. I'm using Bitcard for the authentication, so don't be alarmed when you get redirected over there. In the not too far future I'll add functionality so new servers can be registered via the manage page too.

If you see this message you are fetching this page from the new server. I added a page to keep track of the dns servers.

No news for almost a year… It’s time to say good bye. I’ll hand over the project to Ask Bjørn Hansen effective tomorrow morning.

Details are, of course, in the list archives.

Server count hits 220.

Please do not use OpenNTP as a server for the pool.ntp.org project [2004-12-15: Versions later than 3.6.1 do now properly report the stratum, though].

The monitoring system has been changed: it now uses simple ntp queries instead of ’ntpd’ monitoring servers.

{0,1,2}.pool.ntp.org subzones have been reintroduced.

time.fortytwo.ch will be retired in the long run.

Read more in the [full announcement](https://marc.info/?l=timekeepers- announce&m=119487987909709&w=2).

Current server count: 115.

The ntp packages in Debian GNU/Linux now use pool.ntp.org by default, and include an invitation to join the pool.

A sidenote: some people have experienced problems when trying to reach me per mail. This is nothing personal, but as I’ve been flooded by spam, I now block some countries and some internet providers almost entirely.

There is a Spanish translation - thanks to Xisco Lladó.

Also, I have installed an automatic rating mechanism, so that bad timeservers are automatically removed from the pool.ntp.org nameserver (an associated mailing list has also been created).

Richard S. Shuford (Sun) sent me a note about how to configure nscd properly to work around the fact that it doesn’t do proper round robin of DNS entries. I don’t recommend the use of maxpoll 12 in ntp.conf anymore. As always: more information on the mailing list.

The project now consists of 87 servers - thanks to all who participate. Also, nameservers in the US and in New Zealand will be added shortly. The mailing list has seen some discussions about monitoring server quality - I’ll have to look at this problem more detail. Read the long version of these news in the mailing list archives.

It’s done! The project is now at pool.ntp.org. Also, country level subdomain are being created - the biggest (us) already has 18 servers, with ch (11) and nl (8) being the next biggest. Due to a problem with TCP nameserver requests, no more than 15 servers are visible at any moment in the zone. Debian developer Bdale Garbee considers using pool.ntp.org in the default configuration of the Debian ntp package. Read the longer version of these news in the mailing list archives.