NTP Sync Issue Across Tata (Europe)

Sun Aug 13 15:08:54 UTC 2023

John Gilmore wrote:

> Subsequent conversation has shown that you are both right here.
> 
> Yes, many public NTP servers ARE using GPS-derived time.
> Yes, some public NTP servers ARE NOT using GPS-derived time.

The point is whether

: 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

is a proper recommendation against total GPS failure or not.

> At one point I proposed that some big NTP server pools be segregated by
> names, to distinguish between GPS-derived time and national-standard
> derived time.  For example, two domain names could be e.g.:
> 
>    fromnist.pool.tick.tock
>    fromgps.pool.tick.tock

A problem is that a public NTP server, which is not necessarily
stratum 1, may depends on both.

Another problem is that domain name management is not so
trustworthy. An NTP server once relying on NIST may now
relying on GPS but an administrator of the server may not
change its domain name.

"trusted public NTP servers" is not a trustworthy or
verifiable concept.

> PS: When we say "GPS", do we really mean any GNSS (global navigation
> satellite system)?  There are now four such systems that have global
> coverage, plus regionals.  While they attempt to coordinate their
> time-bases and reference-frames, they are using different hardware and
> systems, and are under different administration, so there are some
> differences in the clock values returned by each GNSS.  These
> differences and discontinuties have ranged up to 100ns in normal
> operation, and higher amounts in the past.  See:

Because of the relativity, 100ns of time difference between
locations more than 30m apart can not be a problem for correct
transaction processing or ordering of events.

						Masataka Ohta