I won’t even try to pretend I’m not a huge geek here…<\/p>\n
I’ve run public NTP servers for ages, and been somewhat intrigued ever since a dedicated server ended up misclassified as being in Brazil and got an enormous volume of traffic, but without impacting performance. I have a DigitalOcean droplet in Singapore that’s serving a few terabytes a month of NTP queries; the pool tells me it’s about 3% of pool traffic for all of Singapore.<\/p>\n
NTP servers are categorized into strata, essentially indicating how far down in the chain a clock is. A stratum 1 server gets its time directly from a (non-NTP) reference source, and a system syncing to a stratum 1 server becomes stratum 2, and so forth. (As an aside, strata don’t actually have enormous significance: a local stratum 3 is probably more accurate than a stratum 1 on the other side of the globe.)<\/p>\n
For years, EC2 instances have had Time Sync<\/a> available over a link-local address. This, incidentally, has proven the point about server stratum not being everything: the Time Sync server is generally at stratum 3, but I infer that everything up to stratum 1 occurs within the availability zone, if not data center, level. Given the link-local Time Sync address and some good stratum 1 clocks within the country, my servers running in AWS typically end up syncing to Time Sync. I have a couple servers in the pool at stratum 4 as a result. It’s further down “the chain,” but it’s a particularly good chain.<\/p>\n But more recently, Amazon has been making PTP available<\/a> on certain instance types in certain regions. While PTP can be succinctly described as a more precise version of NTP (it is, after all, the Precision Time Protocol), it’s a lot<\/em> more precise, making use of hardware timestamping the whole way, and can therefore achieve sub-microsecond accuracy.<\/p>\n And so, I spun up an instance in Malaysia<\/a> and put it in the pool. I’ve kept it at only 512 kbps because there were only 3 IPv4 servers in all of Malaysia, and AWS bandwidth pricing is obscene. It has the PTP Hardware Clock (PHC) set up as a reference source, and is reporting offsets in the range of a handful of nanoseconds.<\/p>\n I went a step further and configured it for NTS<\/a>. This required a hostname, and in trying to use Porkbun to find a novel domain name, I stumbled over the fact that ntpservers.org was open. Obviousy, I went ahead and registered it.<\/p>\n So now there is As an aside: I ended up bringing up I have not yet listed it anywhere outside registering it in the pool, because it’s currently more of a novelty than a long-term committment. I am tempted to eventually withdraw Right now the other AWS regions supporting PTP instances are all areas well-served by stratum 1 clocks: Tokyo and the United States. It will be interesting to see if it becomes available in, say, India, where the available options are more limited.<\/p>","protected":false},"excerpt":{"rendered":" I won’t even try to pretend I’m not a huge geek here… I’ve run public NTP servers for ages, and been somewhat intrigued ever since a dedicated server ended up misclassified as being in Brazil and got an enormous volume … Continue reading malaysia-1.ntpservers.org<\/code> online, as a stratum 1 NTP server in Malaysia supporting NTS.<\/p>\nmalaysia-2.ntpservers.org<\/code> as well in a (seemingly paradoxical) attempt to save money. It’s a cheap instance as a provider including 2TB of bandwidth for under $10\/month (USD). Amusingly, its default config synced to the pool and had selected my stratum 1 server. I cleaned the config up slightly to point to some stratum 1 clocks in Japan an Singapore, and it’s been fielding a lot more traffic from the pool at a higher bandwidth setting.<\/p>\nmalaysia-1<\/code> from the pool but list it as an available stratum 1 supporting NTS on the relevant sites to hopefully cut down bandwidth costs and make it reasonable to maintain long-term.<\/p>\n