It's worth pointing out that the NTPsec project is working hard on reducing the attack surface of NTP classic. At some point there will be few or no reasons to run NTP.
I'm on a home cablemodem connection. All internal NTP traffic is redirected to my OpenBSD firewall, which is a client of 6 different NTP servers (including time.apple.com and some from us.pool.ntp.org).
Right now my firewall's offset to the 6 servers is in the range of -6 ms to +8 ms. The delay to them varies between 26 ms and 95 ms.
All in all, works great for me, and for many other people. And with a much lower attack surface than the reference NTP implementation.
FYI: The delay is simply a function of your network connection. When discussing your satisfaction with an ntp daemon the delay to upstream servers is as relevant as your $/kwh on your electric bill.
Has your computer ever selected one of the apple servers to be the truechimer? I always thought the apple servers were kind of crappy.
Has your computer ever selected one of the apple servers to be the truechimer?
The OpenBSD ntpd implementation doesn't strive for perfection, rather for "good enough". So its selection algorithm might not meet with Mills' approval.
OpenBSD frequently selects one of the Apple servers. Previously I've seen about 12 or 14 different Apple NTP servers being returned by DNS, including places like Singapore and London. Recently, Apple has changed this and now presents about 4 or 5 different servers. As of this moment, my firewall in Oregon is using an Apple NTP server in NYC as its truechimer: 17.253.14.253.
The delay to some of the far-flung Apple servers is well over 100 ms, but the jitter to them is usually quite low, often below about 3 ms. I would agree that delay isn't that relevant, but it intertwines with jitter. In this case, whatever the network topologies that are involved, the jitter usually stays low. Apple's network/peering with Comcast is pretty good in that regard.
As for Microsoft NTP servers (someone responded to you about that), I've previously had bad luck with them. time.windows.com resolves to something at Akamai, and it has been very hit or miss. Often not responding. Often being 100 ms off from other servers. I don't keep time.windows.com in my ntpd config file even though I use Microsoft software and thereby am somewhat "entitled" to use it. I don't know if Akamai has upped its game in recent years.
Recently I've seen 131.107.13.100 show up as part of the US NTP pool. This is time-nw.nist.gov, which is a stratum 1 hosted by Microsoft in Redmond. My experience is that server is almost invariably running about +8 ms from most other servers I'm using. This despite the latency being very low, usually around 20 ms. I'm happy to keep using it as part of the pool, but I don't see how it is any better than the other servers out there.
Are you sure the project is still active? The README talks about first releases happening "soonish", but it's been over a year since the repo saw any activity.
People make a lot of complaints about esr. The one thing I always thought esr excelled at was english composition. After reading that post it seems his writing skills have deteriorated.
Unrelated to NTP, but I (network engineer at an ISP) have also recently observed a few DDoS attacks using the "rpcbind/portmapper" service being used for amplification as well.
The first time I saw this was fairly recently but I've seen a few more instances since then, which may be an indication that this will become more widely used in the future.
Ensure that you've disabled unnecessary services and put a (default deny) firewall in front of your servers, for fuck's sake!
I've seen a fair amount of chargen attacks; it's exciting because for whatever reason, the response packets are very large, so they're getting fragmented, but many people are trying to fix their outgoing chargen mess, and the first fragment (the one with the UDP port number) never arrives at my servers.
I've been under the impression for a while now that unless you needed the super accurate timekeeping that ntpd provides (most don't) you're better off just using openntpd which should exist in most distro's repo's[1]. It's basically just "good enough" for everybody who doesn't need sub ms accurate time keeping.
If you do need sub-ms accurate time keeping, then "just" running ntpd is not enough. You need to have a low-jitter connection to at least one stratum 1 server (if you don't know you have one, you don't), or a local clock. Otherwise, ntp doesn't give you more precision over openntpd -- only faster convergence after you've lost contact with servers for a few days.
If you don't know _exactly_ why you need ntpd, the default should be openntpd.
On the low end (small ISPs with zero or a handful of downstream ASes), people aren't aware or are too lazy to implement egress ACLs. Complicating this: A surprising number of small ISPs and telcos don't actually staff for internet routing skills (e.g. can work with BGP & have heard of a BCP). They'll bring on a consultant to "turn up my new circuit" and move on. If the first consultant sets up egress ACLs and they get a new netblock chances are the next consultant will just remove the ACL instead of updating it...
Medium to large ISPs: IRRs are supposed to solve this but implementation is spotty / OMG scripting changes on routers / etc. http://www.irr.net/docs/list.html
High end: I've heard that some providers have so many customers landing on a given aggregation router that the ACLs from IRRs end up too large for the router.
Cogent's approach is to require a LOA for the subnets that you are announcing and filter out everything else. This seems reasonable, though it gets annoying when you have a downstream AS that has downstream ASes (BUT that's fairly uncommon).
I use egress ACLs that allow my RIR-issued and downstream customer blocs and drop everything else. I have a friend that runs a slightly larger ISP (5x more downstream ASes) that does automation with IRRs.
http://esr.ibiblio.org/?p=7167
https://www.ntpsec.org