[VoiceOps] NTP Question

Peter Beckman beckman at angryox.com
Tue Feb 18 10:26:08 EST 2020


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&product_id=92
>>
>>
>> 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/
---------------------------------------------------------------------------


More information about the VoiceOps mailing list