NTP servers
The NTP servers I run are listed below. Um, for a general introduction to NTP, you should really look elsewhere. There are several good ones around, and I’m a terrible writer. :P
Rules
The rules are basically the same as any other open access NTP server:
- Notification is not required.
iburstis fine.burstis not fine.- Don’t poll more frequently than the default of 64 seconds.
- Honor
KoDpackets. - Don’t start sending excessively frequent requests if you fail to receive responses.
- My IP addresses may not be hardcoded in any sort of hardware, firmware, software, wetware, or anything else.
- My DNS addresses may not be hardcoded in anything, either. They may be used as a default, changeable setting in situations I wouldn’t consider risky. The configuration file used by a couple thousand Debian servers running NTP 4.2.6? Sure, why not. An unchangeable hardcoded setting in some piece-of-crap router firmware sold to a hundred thousand people? No way in hell.
- Types of abuse that I haven’t thought of yet are not allowed, either. Or types of abuse that I have thought of but forgot about, or just decided not to mention.
I don’t mind the occasional htpdate request (not that that would stop pool users anyway), as long as you use HEAD and send a User-Agent header (and preferably Host as well, for the sake of my analytics). However, I may disable my HTTP services without notice, and it goes without saying that you should use (S)NTP if you can anyway — it’s more accurate and uses fewer resources.
In general, you don’t really have to worry. Just be friendly and avoid abuse. Despite the rules above, my enforcement is very loose; if you’re forced to use some idiotic NTP client that makes requests every 59 seconds or something, I don’t care that much, and I’ll never notice you in the sea of jerks polling every 7 seconds anyway…
By the way, despite what some people using the pool apparently think, I do not run DAYTIME, TIME or NCP servers, and I can’t respond to traffic from non-routable IP addresses, either. Seriously, people, WTF?
Finally, I do not provide any warranties or guarantees whatsoever. You know those Caps-Locked legal warnings on every piece of software ever? Yeah. I keep things running to the best of my ability (well, to a usually-adequate portion of my (somewhat limited) ability), and I mostly succeed, but no suing me when I screw up.
Pools
The pools below are hostnames pointing to one or more servers, for various purposes.
The hostnames also provide TXT records listing the servers currently included by name (e.g. ntp.mattnordhoff.com. IN TXT "tick.mattnordhoff.com.").
-
ntp.mattnordhoff.com
Pool that includes my “production” servers.
If I ever don’t have any servers, I’m not sure what I’ll do. Probably point it to a friend’s server.
- Hostname (IPv4 and IPv6 dual-stack)
- ntp.mattnordhoff.com
- Hostname (IPv4-only)
- ipv4.ntp.mattnordhoff.com
- Hostname (IPv6-only)
- ipv6.ntp.mattnordhoff.com
-
all.ntp.mattnordhoff.com
Pool that includes non-production servers. It should usually be a superset of ntp.mattnordhoff.com, also including experimental or unreliable servers, servers with less than static IPs, and things like that.
I created it for my own personal use, and I may change or remove it at any time.
- Hostname (IPv4 and IPv6 dual-stack)
- all.ntp.mattnordhoff.com
-
dfw1.ntp.mattnordhoff.com
Pool of my Linode, SoftLayer née The Planet, Dallas, TX, US servers (or server, as the case may be).
The public hostnames include native IPv6 addresses, but the private network hostname currently does not. This may change.
- Hostname (IPv4 and IPv6 dual-stack)
- dfw1.ntp.mattnordhoff.com
- Hostname (IPv4-only)
- ipv4.dfw1.ntp.mattnordhoff.com
- Hostname (IPv6-only)
- ipv6.dfw1.ntp.mattnordhoff.com
- Hostname (private network)
- private.dfw1.ntp.mattnordhoff.com
-
dfw2.ntp.mattnordhoff.com
dfw2.ntp.mattnordhoff.com will be taken down sometime in 2013-05.
Pool of my Rackspace Cloud, Rackspace DFW1, Grapevine, TX, US servers (or server, as the case may be).
IPv6 tunnel addresses are not included, to avoid routing all around the city to get to a machine a meter away.
- Hostname (IPv4 and IPv6 dual-stack)
- dfw2.ntp.mattnordhoff.com
- Hostname (IPv4-only)
- ipv4.dfw2.ntp.mattnordhoff.com
- Hostname (IPv6-only)
- ipv6.dfw2.ntp.mattnordhoff.com
- Hostname (ServiceNet)
- private.dfw2.ntp.mattnordhoff.com
Servers
-
tick.mattnordhoff.com
Linode Xen VPS, running Ubuntu 8.04 Linux with NTP 4.2.7p169 and kernel 3.0.18 as of this writing.
The public hostnames include its native IPv6 address, but the private network hostname currently does not. This may change.
$ ntpq -p tick.mattnordhoff.com
- Time services
- NTP, HTTP (see warning above)
- Synchronization
- Various stratum 1 servers; use
ntpq -pfor details. - Location
- Linode, SoftLayer née The Planet, Dallas, TX, US
- Hostname (IPv4 and IPv6 dual-stack)
- tick.mattnordhoff.com
- Hostname (IPv4-only)
- ipv4.tick.mattnordhoff.com
- Hostname (IPv6-only)
- ipv6.tick.mattnordhoff.com
- Hostname (Linode Dallas private network)
- private.tick.mattnordhoff.com
- Public NTP Time Server Lists entry
- tick.mattnordhoff.com
- NTP Pool statistics
- IPv4, IPv6
-
ntp2.mattnordhoff.com
ntp2.mattnordhoff.com will be taken down sometime in 2013-05.
Rackspace Cloud Servers Xen VPS, running Ubuntu 8.04 Linux with NTP 4.2.7p169 and kernel 2.6.35.4 as of this writing.
It also has relatively low bandwidth, so please be extra careful about abuse, and don’t point large numbers of clients to it. (These restrictions do not apply to ServiceNet.)
IPv6 is through a Hurricane Electric tunnel. RTT to the tunnel server is ~1-2 ms.
$ ntpq -p ntp2.mattnordhoff.com
- Time services
- NTP
- Synchronization
- My other servers, Rackspace’s local stratum 3 servers, and the NTP Pool; use
ntpq -pfor details. - Location
- Rackspace Cloud, Rackspace DFW1, Grapevine, TX, US
- Hostname (IPv4 and IPv6 dual-stack)
- ntp2.mattnordhoff.com
- Hostname (IPv4-only)
- ipv4.ntp2.mattnordhoff.com
- Hostname (IPv6-only)
- ipv6.ntp2.mattnordhoff.com
- Hostname (Rackspace Cloud DFW1 ServiceNet)
- private.ntp2.mattnordhoff.com
- Public NTP Time Server Lists entry
- N/A
- NTP Pool statistics
- N/A
-
ntp3.mattnordhoff.net
This server is semi-experimental. It probably won’t be moved across the country with no notice, and its IPs probably won’t change, but I will not guarantee this.
The
ntp3.atl0.mattnordhoff.netAtlanta private network hostnames are experimental and may be removed without notice.Linode Xen VPS, running Ubuntu Linux and an NTP development build.
Notice that it is
ntp3.mattnordhoff.net, not.com.$ ntpq -p ntp3.mattnordhoff.net
- Time services
- NTP, HTTP (see warning above)
- Location
- Linode, AtlantaNAP, Atlanta, GA, US
- Hostname (IPv4 and IPv6 dual-stack)
- ntp3.mattnordhoff.net
- Hostname (IPv4-only)
- ipv4.ntp3.mattnordhoff.net
- Hostname (IPv6-only)
- ipv6.ntp3.mattnordhoff.net
- Hostname (Linode Atlanta private network, IPv4 and IPv6 dual-stack) (experimental)
- ntp3.atl0.mattnordhoff.net
- Hostname (Linode Atlanta private network, IPv4-only) (experimental)
- ipv4.ntp3.atl0.mattnordhoff.net
- Hostname (Linode Atlanta private network, IPv6-only) (experimental)
- ipv6.ntp3.atl0.mattnordhoff.net
- Public NTP Time Server Lists entry
- N/A
- NTP Pool statistics
- IPv4, IPv6
News
(Minor downtime, upgrades and other changes will not usually be listed. All dates and times are in UTC unless otherwise noted.)
- 2013-03-12: Officially announce that ntp2 and dfw2.ntp are going away. Not only am I not giving three months notice, the original warning from 2012-08? I somehow accidentally didn’t deploy it until this year. Nice going.
- 2013-03-09: Add ntp3.mattnordhoff.net. Notice that it is not a .com.
- 2012-08-12: I am likely to take down ntp2 sometime in the next 6 months or so. If this happens, it will be kept up 3 months, or until it stops receiving traffic. Its hostnames will be CNAMEd elsewhere, most likely to ntp. It will be replaced by a new server, but probably at a different location, and almost certainly with new IPs.
- 2011-11-23: tick was down for 2 hours for maintenance that was supposed to take less than 30 minutes.
- 2011-10-04: all.ntp accidentally included two incorrect IPs for the last few days, one IPv4 and one IPv6 (along with several good IPs). Ugh… Sorry about that. (The IPs used to be mine, but aren’t anymore. I accidentally reenabled them when making another change. As of now they don’t respond to NTP queries (or ping).)
- 2011-08-29: tick’s old IPv6 addresses have been taken down. The old address still had 2 clients, and the old-old one had 1. This hadn’t changed for a couple months. (These are fairly significant figures, since the IPs never had much more than a half-dozen clients.)
- 2011-07-23: Rackspace routing fixed. And it was fixed better than it was last time, so it should be less likely to recur again. Probably. Well, anyway, native IPv6 will be coming fairly soon…
- 2011-07-23: Damn you, Rackspace routers… And me, for being offline the last few days.
- 2011-07-12: Rackspace’s routing seems to be better. I’ve added the affected pool records back, probably a bit earlier than I should have.
- 2011-07-08: Oh FFS. Now Rackspace has a crazy, asymmetric route to Hurricane Electric’s Dallas tunnel server — it goes through California! I’ve pulled the affected pool DNS records.
- 2011-07-01: Remove all.ntp’s IPv4- and IPv6-only hostnames. For now — and probably forever — they’ll exist as
CNAMEs to the main hostname. - 2011-06-28: Rackspace has started to roll out native IPv6. It will soon become available for ntp2, which means another IP change dance. How fun! As with tick, I’ll keep the tunnel up for 3 months or until it’s no longer used. I’ve added a warning above. Anyway, nothing will be happening immediately; I plan to wait until I take down tick’s old tunnel.
- 2011-06-09: tick’s new IPv6 IP now has reverse DNS. Yay!
- 2011-06-07: The NTP Pool has experimental IPv6 support. tick is, of course, included in this.
- 2011-05-29: I changed the rDNS of tick’s old IPs to
new-ip.update-now.1.tick.mattnordhoff.com.andnew-ip.update-now.2.tick.mattnordhoff.com., respectively. Hopefully people will notice. - 2011-05-27: I changed the rDNS of tick’s old IPv6 IP, to
old2.tick.mattnordhoff.com. The new IP doesn’t have any rDNS yet — my provider doesn’t support it yet, but they’re working on it. I figured you wouldn’t want me to wait just for that. - 2011-05-27: tick has native IPv6! This means an IP change. I have transferred its old tunnel to a Rackspace Cloud Server (like ntp2, but a different one) — which, incidentally, solves the routing problem, yay! — and will take it down 2011-08-27. I could handle this differently, and keep the tunnel up indefinitely, but I CBA to set it up. I am sorry for the inconvenience, but not sorry enough not to do it. :P
- 2011-05-25: I’m definitely thinking about taking down tick’s IPv6 tunnel eventually. I have no idea when, but it could be quite soon. Frankly, I want to be a good netizen, but I also don’t want to expend money or effort. I am not looking forward to making the tunnel work alongside native, and I’ll be very glad to be rid of the damn thing. If the choices are between a couple hours of mind-numbing work and some money, and an immeasurably minor inconvenience to half a dozen clients, who are already experiencing degraded service anyway… In any case, I have added a warning about this to tick’s information section above, which I should have done weeks ago.
- 2011-05-19: The situation with tick’s IPv6 tunnel is unchanged. In better news, it will gain native IPv6 “soon”, so I’m probably just going to grit my teeth and wait this one out. Unfortunately, if tick’s deprecated address is anything to go by, even after I get native the tunnel will be in use for a long time. (This news entry may be an early indication that I’m considering taking down the tunnel eventually.)
- 2011-04-19: tick’s IPv6 tunnel grew an extra 26 ms of RTT last week. I don’t know whose fault it is and, frankly, it’s not a very high priority. (Despite being on the same tunnel server, ntp2 is fine.)
- 2011-01-14: I’m declaring ntp2’s new kernel no longer experimental. Yay! (Although it’s not like I tested it under load or anything.)
- 2011-01-11: dfw1.ntp and dfw2.ntp are no longer experimental. That was quick!
- 2011-01-11: Create experimental dfw1.ntp and dfw2.ntp pools and add them to this page.
- 2010-12-08: tick has a new IPv6 address (within the same /64). I also changed the old address’s reverse DNS, to
old1.tick.mattnordhoff.com. I have no plans to deactivate the old address. This should have no operational impact, other than the rDNS change and IPv6-enabledpooldirective users getting a duplicate association. - 2010-11-23: A kernel upgrade and clock source change on ntp2 fixed the longstanding 10 ms clock resolution issue.
- 2010-03-10: Added all.ntp to this page.
- 2010-03-09: Created experimental all.ntp pool.
- 2010-01-22: The IPv6 tunnel server is back to normal as of about 19:40.
- 2010-01-21: The IPv6 tunnel server used by tick and ntp2 suffered a hardware failure, and IPv6 was inaccessible for 6 hours. It’s back up now, temporarily on a server in Los Angeles, greatly increasing latency. Sorry about the inconvenience.
- 2010-01-07: Made ntp2 public.
- 2010-01-07: Added this news section, filling in some old entries.
- 2009-11-25: Set up NTP on ntp2.
- 2009-11-03: Officially made tick stratum 2. Before, it used a couple stratum 1 servers, but I only intended it to be stratum 3.
- 2009-10-28: Enabled loose rate-limiting, after an incident.
- 2009-10-05: Added tick to the Public NTP Time Server Lists.
- 2009-06-14: Created this web page. Whee!
- 2009-05-29: Added IPv6 tunnel to tick.
- Before 2009-05-20: Added tick to the NTP Pool.
- 2009-04-26: Set up NTP on tick.
— Matt Nordhoff <mnordhoff@mattnordhoff.com>