I ran ntpq -cmru on khronometr.sputnik-vremya.net (Raspberry Pi with GPS hat) and of ~1800 entries, more than 500 entries were from *.compute.amazonaws.com and ~700 from comcast. I dont mind the comcast entries, but aws, afaik, are virtualized servers. If my assumption is correct, it seems alot of bandwidth is being wasted for on servers that could just use the host time. I only have 2 linodes reporting. I am not making a claim of abuse, but is there a way to limit the number of virtual server that use the pool, and ultimately my stratum 1 server?
I’m seeing a bit over 30% of traffic for my US-zone server coming from AWS. I don’t think it’s abusive per se; I think they probably really do account for about 30% of *nix boxes online pointing to the pool by default.
Every VM I’ve seen runs either ntpd or chrony; its dependence on the host clock is unclear to me.
AWS runs a time service accessible to their VMs over link-local addresses, called Time Sync: Keeping Time With Amazon Time Sync Service | AWS News Blog – however, it shows up as stratum 3 and doesn’t seem to be enabled by default. I wish their base AMIs would point at this; it would save a tremendous amount of external traffic, and seems to be very good quality. (I’m assuming they have stratum 1 internally at each DC and fan it out with each hypervisor running at stratum 3 and making it available to VMs.)
I actually learned yesterday that Comcast operates time.comcast.com and time.xfinity.com. Both appear to be (overlapping?) pools of stratum 2 servers. I don’t see much documentation on it, and I don’t think it’s given out by default with DHCP leases, so I doubt they see a whole lot of traffic.
I wonder if we could make the amazon.pool.ntp.org vendor zone include the 169.254.169.123 Time Sync IP? (Whether we should is a different question, I suppose.)
169.254.169.123 is not routed on the public Internet and hence cannot be seen by the NTP Pool monitor. See the Wikipedia article
Oh, indeed not. My thought was that we could just always include it as one of the 4 IPs returned to any AWS-sourced requests, since it should be good (AFAICT) on any AWS instance – assuming the resolvers don’t object to a link-local address in public DNS results, which some may?
Of course, beyond not being monitorable, there’s the fact that it’s not actually a pool server at all. Just a half-baked idea to try to get AWS clients to discover Amazon’s time service.
Another important point is that the link-local server has leap smearing enabled, so it cannot be mixed with servers from the pool. They are not serving the same thing.
2 Likes