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