Years ago, while configuring a dedicated server, I noticed that ntp.conf encouraged people to join the pool, so I did. Due to a GeoIP quirk, our server was misclassified as being in Brazil, and got a ridiculous amount of traffic. Since NTP is just small UDP packets, and ntpd just tells you the time, it had no adverse impact, so we ran with it. At this point I have a handful of servers in the pool, including some VMs in esoteric locations solely because they’re underserved. (For a while I was doing about 10TB/month in Singapore.)
They’re not currently in the pool (or even on the Internet), but I also have a couple hardware NTP servers with GPS receivers; I intend to fill in some blather here with references to them so I have the documentation in one consolidated place.
Stratum One
NTP servers have an associated stratum, which denotes their position in a chain. A stratum-one server is connected directly to a high-stability time reference (with that reference sometimes being referred to as “stratum zero”); a stratum-two server gets its time from a stratum-one server, and so on. In general, lower-strata servers are preferable, but it’s not everything. For example, I have a couple servers that are meant to be stratum 2 servers in the pool, but they’re running on AWS / Lightsail instances so I also configured 169.254.169.123 for Amazon Time Sync, which shows up as stratum 3 but I think it’s all within the same data center. chrony ultimately decided that this was better than the stratum 1 servers over the Internet, so now the servers operate at stratum 4.
A similar thing plays out sometimes with people who insist on using time.nist.gov as the “best” time source when it’s on the opposite side of the country.
GPS
An interesting design of GPS is that it requires extremely precise time to give accurate time. Each GPS satellite broadcasts its own location and the time, and GPS are able to triangulate1this is really an oversimplification their position based on this. Even very minor time error can translate to substantial position inaccuracy, so each GPS satellite carries an atomic2“Atomic” meaning it measures time based on the behavior of atoms; unrelated to splitting atoms in an atomic bomb clock, which is regularly synchronized with ground-based atomic clock ensembles.
As a result, the US Space Force states that GPS enables timing accuracy to within 30 nanoseconds of the USNO’s ensemble.
Not only is it accurate, but it became the standard for standards organizations around the world to keep their own national time standards synchronized with each other.
In short, this means that a GPS receiver designed to solve for time instead of location (and thus operating from a fixed location) is an extremely accurate, extremely precise stratum zero source.
My pool servers
Listed here. This table is really kind of for my own reference. As of March 2023:
| IP | Software | Location/Remarks |
|---|---|---|
| 13.126.27.131 | chrony on Amazon Linux | Mumbai, India (Lightsail) (peered w/ DO India) |
| 13.209.84.50 | chrony on Linux | Korea (512MB Lightsail instance, which is too small) |
| 13.244.55.14 | chrony on Amazon Linux | South Africa (EC2) |
| 54.232.82.232 | chrony on Amazon Linux | Brazil (EC2) |
| 66.90.70.34 | chrony on Ubuntu | Brazil (FDC Servers) |
| 139.59.55.93 | chrony on Rocky 9 | India; Digital Ocean (peered w/ Lightsail India) |
| 144.126.242.176 | chrony on Rocky 9 | Singapore; Digital Ocean |
I have now moved all of them to chrony. The two Lightsail instances do not currently have Elastic IPs, so my ability to relaunch them is somewhat limited.
My hardware servers
SyncServer S350
- Manual: PDF deep link
- This has a Rubidium oscillator and the PTP option enabled, but the GPS receiver is hamstrung by a GPS week number rollover bug.
EndRun Sonoma D12
- OCXO and PTP upgrades
- GPS-based
Header photo credit
Photo by Thomas Bormans on Unsplash