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.
While the DNS system is resilient in handling failures, to get decent performance it's important that each "layer" has fast and highly available servers. To that end we're fortunate that Dynect are providing Anycast DNS services for the NTP Pool (about 300 million requests a month right now, and we're just getting started).
For now we're just using Dynect for the ntpns.org zone, but in the future we're looking forward to also using their failover system to help make sure the pool website is always available.
]]>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).
That’s a lot of accurate time distributed; and yet triains, planes and meetings run late. :-)
]]>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.
For people in the Northern Hemisphere: Enjoy spring and the increasing daylight!
For those of you on the other side: Sorry, but it’s our turn to have longer days now. :-)
]]>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.
]]>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.
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 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.
]]>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.
]]>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.
]]>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.
]]>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).
]]>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.
]]>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).
]]>