But another key consideration beyond accuracy is the reliability of a server's GPS constellation view. If you can lose GPS sync for an hour or more (not uncommon in terrain-locked locations), the NTP time will go free-running and could drift quite a bit. You need an OCXO to minimize that drift to acceptable levels. While this is drifting a bit off-topic for NANOG (and drifting into the topic range for time-nuts@febo.com), I'll just add one more thing to

All,   Thanks very much for all the replies. Extremely helpful. "...ask someone what time it is and they'll tell you how to build a watch." Luckily I got both. Ed -------- Original message -------- From: Lamar Owen <lowen@pari.edu> Date: 5/14/2016 10:27 AM (GMT-05:00) To: NANOG <nanog@nanog.org> Subject: Re: NIST NTP servers On 05/13/2016 04:38 PM, Mel Beckman wrote: this.  The Hold time (when the oscillator is free-running) is a very important consideration, especially, as you say, when terrain is an issue. For us it is even more important, as the 10MHz output from the timing rack is used as a site-wide frequency standard.  Of course, you never discipline a cesium PRS, but the rubidium secondary is disciplined by circuitry in the SSU2000. Back in the days of common backbone delivery over SONET discussion of cesium standards would have been on-topic, as some SONET gear (Nortel Optera for instance) needs a master clock; especially if you were delivering channelized circuits or interfacing with customers and telcos with DS3 or even DS1 circuits or DS0 fractions within them.  Ethernet is far more forgiving.