The NIST time servers do NOT get their time from GPS. NIST, like several government standards agencies and other research labs around the globe, run an ensemble of high precision atomic clocks. In the case of NIST, they use the ensemble to produce the timescale UTC(NIST) at their Boulder, Colorado campus.
In addition, they produce secondary copies of the timescale at Fort Collins and Maryland. The time transfer from Boulder to these locations use various techniques, but not traditional "get your time from GPS" methods. The closest they come is that the Maryland location uses GNSS common view time transfer where the phase difference between the UTC(NIST) realization at each site is measured against the signal from a single GPS satellite that both sites can see in the sky at the same time. The GPS signal is only used as a reference... think start button on a stopwatch. If both sides have the same delay from a specific feature in the GPS signal then you can be sure they are synchronized with each other. This is also just a measurement, and a scientist makes the decision about whether the timescale needs to be adjusted to be kept within specs. These are physical realizations of UTC... that is, a phase-aligned 1PPS pulse and a high precision clock signal. These realizations are used to directly drive the NIST NTP servers at each location. GPS is not involved. Note that this realization of UTC is different than what you get from GPS. GPS gets its time from the naval observatory which has it's own ensemble of clocks which produce UTC(USNO). These two timescales are within a few ns of each other, also verified with GNSS common view technology, so one can consider them the same for most purposes. Note that a similar process is used to derive UTC(NICT) in Japan. Pointing a NTP server at ntp.nict.jp would result in receiving time that was produced independently by NICT, and was not transmitted by GPS. There are various simplifications I've made to the above description so there are a few places the description leaves out intermediate steps. As far as a rubidium clock goes, I'd much rather see it disciplined regularly to a GPS time source, but that comes from the fact that I like my 1PPS to be within a microsecond or so of UTC due to the precision I need in the lab. If I let either of my lab rubidiums free run for more than a few days, I'm typically off UTC by more than that amount. But that level of accuracy isn't typically needed for computer time so I will concede that you could get away with freerunning for an extended period. Not hundreds of years on a rubidium. But a while. Assuming the original calibration was done correctly. Note that some of the high end appliances I'm referring to just use GPS over days and weeks to discipline a precision oscillator (sometimes rubidium) which is essentially an automatic calibrating version of what you're proposing. On Fri, Aug 11, 2023, 3:33 AM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > Forrest Christian (List Account) wrote: > > > The recommendation tends to be the following: > > > > 1) Run your GPS-derived NTP appliances, but DO NOT point end-user > > clients at it. 2) Run a set of internal NTPd servers, and configure > > them to pull time from all of your GPS-derived NTP servers, AND > > trusted public NTP servers 3) Point your clients at the internal NTPd > > servers. > > That is not a very good recommendation. See below. > > > At some point, using publicly available NTP sources is redundant > > unless one wants to mitigate away the risks behind failure of the GPS > > system itself. > > Your assumption that public NTP servers were not GPS-derived NTP > servers is just wrong. > > > What I'm advocating against is the seemingly common practice to go > > buy an off-the-shelf lower-cost GPS-NTP appliance (under $1K or so), > > stick an antenna in a window or maybe on the rooftop, and point all > > your devices at that device. > > Relying on a local expensive GPS appliance does not improve > security so much and is the worst thing to do. > > But, additionally relying on remote servers (including those > provided by NIST) is subject to DOS attacks. > > As such, the ultimate (a little expensive) solution is to have > your own Rb clocks locally. > > Masataka Ohta > >
