On Tue, 18 Feb 2020, Mike Hammett wrote:
I would love to have my own stratum one in each Frontier CO we're in. Unfortunately, we don't have access to put GPS antennas on the buildings and the important buildings don't have windows and have us behind multiple layers of brick walls\concrete floors, so an indoor antenna isn't likely to work.
Clocks that accept their information via PTP from a location where we can put up a GPS antenna run into the thousands of dollars (though I am still waiting on quotes), thus aren't exactly reasonably priced.
To seemingly conclude the thread, 3 are required, 4 or 5 are recommended. VM NTP servers are to be avoided.
I'll roll with VMs for now while I develop a plan to have something there I can use the hardware directly (no VM). I'll swap out each VM for hardware when a reasonable course of action is available.
I don't see them saying: 1. The NTP servers must be in your control 2. The NTP servers must be in your local datacenter There are *thousands* of public NTP servers around the world, and others that you can request access to. https://www.ntppool.org/ I'm not quite sure why YOU need to run 3-5 NTP servers yourself when NTP is designed to use network-delayed NTP clocks over the network to keep your clock as close to an accurate time as possible. As an example, I have 8 public NTP servers that we use on one of our servers to keep accurate time. --> ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +208.79.xx.xxx 127.67.xxx.xx 2 u 952 1024 377 55.772 -0.063 0.245 -140.82.xx.xx 47.187.xxx.xx 2 u 78 1024 377 7.740 -0.736 0.345 #2605:xxxx:x:x:: 164.67.xxx.xx 2 u 417 1024 377 59.151 -4.343 0.094 #72.5.xx.xx 216.218.xxx.xxx 2 u 842 1024 377 71.629 3.662 0.113 -2607:5300:xxx:x 213.251.xxx.xxx 2 u 743 1024 377 13.837 -1.033 0.097 *17.253.xx.xxx .SHM. 1 u 54 1024 377 67.756 0.424 0.081 -216.232.xxx.xx 206.108.x.xxx 2 u 113 1024 377 77.116 2.135 0.795 +207.34.xx.xx 206.108.x.xxx 2 u 642 1024 377 56.826 -0.008 0.161 Checking our current clock time against a few other servers we do NOT use for time sync: --> ntpdate -q tock.usno.navy.mil server 192.5.41.41, stratum 1, offset -0.000841, delay 0.08321 18 Feb 15:12:58 ntpdate[13806]: adjust time server 192.5.41.41 offset -0.000841 sec --> ntpdate -q time.apple.com server 17.253.16.125, stratum 1, offset -0.000065, delay 0.09431 server 17.253.4.125, stratum 1, offset 0.000692, delay 0.09024 server 17.253.4.253, stratum 1, offset 0.000718, delay 0.09026 server 17.253.16.253, stratum 1, offset 0.000412, delay 0.09337 server 17.253.26.125, stratum 1, offset -0.000387, delay 0.08112 18 Feb 15:13:09 ntpdate[13843]: adjust time server 17.253.26.125 offset -0.000387 sec --> ntpdate -q time.windows.com server 51.105.208.173, stratum 3, offset -0.000548, delay 0.11067 18 Feb 15:13:20 ntpdate[13862]: adjust time server 51.105.208.173 offset -0.000548 sec Our native clock skew is -6.36 parts per 1 million. Breaking a day (86,400 seconds) into 1m parts yields 0.0864 seconds per part. This means that without NTP, our local hardware clock would be slow by about 550ms per day. NTP corrects that on an ongoing basis to keep us within about 0.1ms. --> cat /var/lib/ntp/drift -6.360 Using only public time servers from NTPpool.org and any available local clocks, we are within 1/1000th of a second of the correct time. We also monitor our clock skew with Nagios and alert if it gets to more than 1/10th of a second accuracy, or if we lose more than 30% of our NTP peers. If you set up NTPD.conf correctly, an errant source or clock tick won't totally hose your local clock (this HAS happened). Beckman
----- Original Message -----
From: "Peter Beckman" <beckman at angryox.com> To: "Tim Bray" <tim at kooky.org> Cc: voiceops at voiceops.org Sent: Monday, February 17, 2020 10:02:46 PM Subject: Re: [VoiceOps] NTP Question
Ooooh I like that one!
The thread got a little confusing --
Are we talking about using NTP as a client on VMs?
Or using VMs to run NTP servers?
If as a server: Hell NAH! Don't do it. Like everyone said, the clock available to the OS isn't reliable, you don't want its drift to affect other machine's clocks.
If as a client: Hell YAH! VM clocks are unreliable. Heck, we had a dedicated server that had a 14 second a day drift! We used the heck out of NTP to keep that sucker from losing time.
Sort of related: I really love OVH as a hosting provider, but they offer one time source, and it is in Beauharnois, Canada, even if you use their Oregon US Datacenter. These NTP devices are so inexpensive to cover a whole datacenter, why are we introducing network latency?!?
I am of the opinion that each physical datacenter should provide its own Stratum 1 NTP source.
Beckman
On Tue, 18 Feb 2020, Tim Bray via VoiceOps wrote:
On 17/02/2020 21:52, Mike Hammett wrote:
How many NTP servers do you guys run? I just spun up two NTP servers in different locations on this network. Metaswitch just asked me for at least four (preferably five, or even more). Right now, the ones I have are just referencing the US pool. Eventually, they'll reference on-net GPS-backed devices.
https://store.uputronics.com/index.php?route=product/product&path=60_70&prod...
LeoNTP server. If you want to run your own.
-- Tim Bray Huddersfield, GB tim at kooky.org +44 7966479015
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------