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" <[email protected]>
To: "Tim Bray" <[email protected]>
Cc: [email protected]
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&product_id=92
LeoNTP server. If you want to run your own.
--
Tim Bray
Huddersfield, GB
[email protected]
+44 7966479015
---------------------------------------------------------------------------
Peter Beckman Internet Guy
[email protected] http://www.angryox.com/
---------------------------------------------------------------------------
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
---------------------------------------------------------------------------
Peter Beckman Internet Guy
[email protected] http://www.angryox.com/
---------------------------------------------------------------------------
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
