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
>
>

Reply via email to