Cloudflare Time

[Starrbuck]

me@RT-AC86U:/tmp/home/root# ping -c 5 us.pool.ntp.org
PING us.pool.ntp.org (66.228.58.20): 56 data bytes
64 bytes from 66.228.58.20: seq=0 ttl=54 time=22.960 ms
64 bytes from 66.228.58.20: seq=1 ttl=54 time=22.330 ms
64 bytes from 66.228.58.20: seq=2 ttl=54 time=22.148 ms
64 bytes from 66.228.58.20: seq=3 ttl=54 time=22.109 ms
64 bytes from 66.228.58.20: seq=4 ttl=54 time=21.830 ms
--- us.pool.ntp.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 21.830/22.275/22.960 ms
me@RT-AC86U:/tmp/home/root# ping -c 5 time.cloudflare.com
PING time.cloudflare.com (162.159.200.1): 56 data bytes
64 bytes from 162.159.200.1: seq=0 ttl=59 time=2.154 ms
64 bytes from 162.159.200.1: seq=1 ttl=59 time=3.022 ms
64 bytes from 162.159.200.1: seq=2 ttl=59 time=2.768 ms
64 bytes from 162.159.200.1: seq=3 ttl=59 time=2.741 ms
64 bytes from 162.159.200.1: seq=4 ttl=59 time=2.629 ms
--- time.cloudflare.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 2.154/2.662/3.022 ms

Nice improvement!

 

[sfx2000]

Nice improvement!

Ping time doesn't reflect NTP accuracy...

That's milliseconds...

I'm working on microseconds...

 

[Starrbuck]

Ping time doesn't reflect NTP accuracy...

I never claimed it did. I was just saying the reduction in time is nice.

That's milliseconds...

Yup.

I'm working on microseconds...

Huh?

 

[Marin]

1 microsecond = 0.000001 second (much shorter time interval)

1 millisecond = 0.001 second

 

[Marin]

Ping time doesn't reflect NTP accuracy...

That's milliseconds...

I'm working on microseconds...

Is this from using your Rubidium Standard device?

 

[Starrbuck]

1 microsecond = 0.000001 second (much shorter time interval)

1 millisecond = 0.001 second

I'm aware the difference between a millisecond and microsecond. I was querying for clarification of how that relates to my post.

 

[Marin]

I'm aware the difference between a millisecond and microsecond. I was querying for clarification of how that relates to my post.

Got ya, no problem. By the way, my pings to time.cloudlflare.com are very similar to yours - definitely see better results with it then my current servers.

 

[Marin]

ASUSWRT-Merlin RT-AX88U 384.12-0 Fri Jun 21 21:26:02 UTC 2019

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 tock.usshc.com
PING tock.usshc.com (199.102.46.72): 56 data bytes
64 bytes from 199.102.46.72: seq=0 ttl=54 time=33.382 ms
64 bytes from 199.102.46.72: seq=1 ttl=54 time=35.929 ms
64 bytes from 199.102.46.72: seq=2 ttl=54 time=33.812 ms
64 bytes from 199.102.46.72: seq=3 ttl=54 time=34.173 ms
64 bytes from 199.102.46.72: seq=4 ttl=54 time=32.852 ms
--- tock.usshc.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 32.852/34.029/35.929 ms

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 time.cloudflare.com
PING time.cloudflare.com (162.159.200.123): 56 data bytes
64 bytes from 162.159.200.123: seq=0 ttl=56 time=21.466 ms
64 bytes from 162.159.200.123: seq=1 ttl=56 time=21.800 ms
64 bytes from 162.159.200.123: seq=2 ttl=56 time=21.101 ms
64 bytes from 162.159.200.123: seq=3 ttl=56 time=21.939 ms
64 bytes from 162.159.200.123: seq=4 ttl=56 time=21.344 ms
--- time.cloudflare.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 21.101/21.530/21.939 ms

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 pool.ntp.org
PING pool.ntp.org (173.59.55.254): 56 data bytes
64 bytes from 173.59.55.254: seq=0 ttl=51 time=53.504 ms
64 bytes from 173.59.55.254: seq=1 ttl=51 time=47.149 ms
64 bytes from 173.59.55.254: seq=2 ttl=51 time=50.588 ms
64 bytes from 173.59.55.254: seq=3 ttl=51 time=54.246 ms
64 bytes from 173.59.55.254: seq=4 ttl=51 time=47.785 ms
--- pool.ntp.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 47.149/50.654/54.246 ms

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 0.us.pool.ntp.org
PING 0.us.pool.ntp.org (165.227.216.233): 56 data bytes
64 bytes from 165.227.216.233: seq=0 ttl=53 time=44.153 ms
64 bytes from 165.227.216.233: seq=1 ttl=53 time=43.644 ms
64 bytes from 165.227.216.233: seq=2 ttl=53 time=45.067 ms
64 bytes from 165.227.216.233: seq=3 ttl=53 time=42.882 ms
64 bytes from 165.227.216.233: seq=4 ttl=53 time=44.323 ms
--- 0.us.pool.ntp.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 42.882/44.013/45.067 ms

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 tick.usshc.com
PING tick.usshc.com (199.102.46.70): 56 data bytes
64 bytes from 199.102.46.70: seq=0 ttl=54 time=37.310 ms
64 bytes from 199.102.46.70: seq=1 ttl=54 time=32.481 ms
64 bytes from 199.102.46.70: seq=2 ttl=54 time=33.308 ms
64 bytes from 199.102.46.70: seq=3 ttl=54 time=35.640 ms
64 bytes from 199.102.46.70: seq=4 ttl=54 time=35.859 ms
--- tick.usshc.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 32.481/34.919/37.310 ms

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 1.us.pool.ntp.org
PING 1.us.pool.ntp.org (206.55.191.142): 56 data bytes
64 bytes from 206.55.191.142: seq=0 ttl=53 time=33.257 ms
64 bytes from 206.55.191.142: seq=1 ttl=53 time=42.371 ms
64 bytes from 206.55.191.142: seq=2 ttl=53 time=33.681 ms
64 bytes from 206.55.191.142: seq=3 ttl=53 time=36.161 ms
64 bytes from 206.55.191.142: seq=4 ttl=53 time=35.561 ms
--- 1.us.pool.ntp.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 33.257/36.206/42.371 ms

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 2.us.pool.ntp.org
PING 2.us.pool.ntp.org (172.98.193.44): 56 data bytes
64 bytes from 172.98.193.44: seq=0 ttl=52 time=50.753 ms
64 bytes from 172.98.193.44: seq=1 ttl=52 time=42.847 ms
64 bytes from 172.98.193.44: seq=2 ttl=52 time=42.654 ms
64 bytes from 172.98.193.44: seq=3 ttl=52 time=42.459 ms
64 bytes from 172.98.193.44: seq=4 ttl=52 time=43.187 ms
--- 2.us.pool.ntp.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 42.459/44.380/50.753 ms

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 3.us.pool.ntp.org
PING 3.us.pool.ntp.org (163.237.218.19): 56 data bytes
64 bytes from 163.237.218.19: seq=0 ttl=40 time=28.584 ms
64 bytes from 163.237.218.19: seq=1 ttl=40 time=29.452 ms
64 bytes from 163.237.218.19: seq=2 ttl=40 time=28.356 ms
64 bytes from 163.237.218.19: seq=3 ttl=40 time=31.641 ms
64 bytes from 163.237.218.19: seq=4 ttl=40 time=27.087 ms
--- 3.us.pool.ntp.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 27.087/29.024/31.641 ms

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 time.cloudflare.com
PING time.cloudflare.com (162.159.200.123): 56 data bytes
64 bytes from 162.159.200.123: seq=0 ttl=56 time=20.674 ms
64 bytes from 162.159.200.123: seq=1 ttl=56 time=21.760 ms
64 bytes from 162.159.200.123: seq=2 ttl=56 time=24.900 ms
64 bytes from 162.159.200.123: seq=3 ttl=56 time=21.794 ms
64 bytes from 162.159.200.123: seq=4 ttl=56 time=26.759 ms
--- time.cloudflare.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 20.674/23.177/26.759 ms

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 time.cloudflare.com:1234
PING time.cloudflare.com:1234 (162.159.200.123): 56 data bytes
64 bytes from 162.159.200.123: seq=0 ttl=56 time=22.658 ms
64 bytes from 162.159.200.123: seq=1 ttl=56 time=24.038 ms
64 bytes from 162.159.200.123: seq=2 ttl=56 time=21.129 ms
64 bytes from 162.159.200.123: seq=3 ttl=56 time=22.357 ms
64 bytes from 162.159.200.123: seq=4 ttl=56 time=24.500 ms
--- time.cloudflare.com:1234 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 21.129/22.936/24.500 

@RT-AX88U-29F0:/tmp/home/root# ping -c 5 roughtime.cloudflare.com:
2002
PING roughtime.cloudflare.com:2002 (104.19.198.151): 56 data bytes
64 bytes from 104.19.198.151: seq=0 ttl=56 time=22.783 ms
64 bytes from 104.19.198.151: seq=1 ttl=56 time=20.418 ms
64 bytes from 104.19.198.151: seq=2 ttl=56 time=23.573 ms
64 bytes from 104.19.198.151: seq=3 ttl=56 time=22.482 ms
64 bytes from 104.19.198.151: seq=4 ttl=56 time=21.584 ms

--- roughtime.cloudflare.com:2002 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 20.418/22.168/23.573 ms

 

[sfx2000]

Is this from using your Rubidium Standard device?

As a reference, and my code confirms...

 

[sfx2000]

Again - ping time to a host doesn't matter...

Here's what does...

First column is NTP epoch days, second is time since midnight - third is time to/from server, the fourth is time inside the server to handle the request - 5th column is delta between internal clock and the NTP server clock in microseconds - next column is the server side dispersion reported from it (how much it might vary from real time) - last column is a nudge factor to correct the kernel using adjtimex

Like I mentioned - ping time itself doesn't matter with NTP, you need to look at the application itself, and how it interacts with the kernel timing and HW.

43636 72025.984     934.0     55.6     242.7  30639.6  -1653728
43636 72086.046     798.0     67.2     332.7  31539.9  -1653728
43636 72146.109    1038.0     57.3     301.6  32440.2  -1653728
43636 72206.170    1075.0     58.9     363.0  33340.5  -1653728
43636 72266.231    1000.0     59.9     363.5  34240.7  -1653728
43636 72326.292    1254.0     70.2     267.3  35141.0  -1653728
43636 72386.353    1159.0     59.3     325.5  36041.3  -1653728
43636 72446.414    1174.0     62.8     285.5  36941.5  -1653728
43636 72506.476    1104.0     59.7     188.4  37841.8  -1653728
43636 72566.543    1098.0     61.0     263.9  38742.1  -1653728
43636 72626.604    1066.0     59.8     261.6  39642.3  -1653728
43636 72686.665    1262.0     72.1     141.0  40542.6  -1653728
43636 72746.726     957.0     62.2     117.6  41442.9  -1653728
43636 72806.787    1137.0     59.7     189.1  42343.1  -1653728
43636 72866.847    1815.0     60.7     421.4  43243.4  -1653728
43636 72926.908    1228.0     57.8      72.6  44158.9  -1653728
43636 72986.969    1081.0     52.2     127.2  45059.2  -1653728
43636 73047.031    1119.0     50.7      41.9  45959.5  -1653728
43636 73107.091     965.0     57.0      45.7  46859.7  -1653728
43636 73167.153    1105.0     56.4      44.0  47760.0  -1653728
43636 73227.214     930.0     54.3      -9.0  48660.3  -1653728
43636 73287.275     966.0     66.4     -25.1  49560.5  -1653728
43636 73347.336    1000.0     68.2     -44.9  50460.8  -1653728
43636 73407.397    1179.0     60.5    -110.5  23651.1  -1653728
43636 73467.459    1177.0     56.9     -75.1  24551.4  -1653728
43636 73527.520    1067.0     63.1     -40.5  25451.7  -1653728
43636 73587.581     989.0     63.8    -118.5  26351.9  -1653728
43636 73647.642    1029.0     66.8    -123.2  27252.2  -1653728
43636 73707.703     999.0     60.3     -86.5  28152.5  -1653728
43636 73767.764    1081.0     65.8    -183.7  29052.7  -1653728
43636 73827.825    1119.0     64.5     -87.0  29953.0  -1653728
43636 73887.886    1276.0     53.5    -193.2  19027.7  -1653728
43636 73947.947    1010.0     52.0    -173.2  19928.0  -1653728
43636 74008.008    1079.0     52.5    -143.2  20828.2  -1653728
43636 74068.069    1184.0     55.1    -188.6  21728.5  -1653728
43636 74128.130    1095.0     57.2    -162.2  22628.8  -1653728
43636 74188.191    1238.0     58.9    -176.8  23529.1  -1653728
43636 74248.252    1272.0     54.9    -247.3  24429.3  -1653728
43636 74308.312     949.0     50.3    -239.3  25329.6  -1653728
43636 74368.378    6282.0     54.9   -2883.7  26229.9  -1653728
43636 74428.434     916.0     46.8    -317.5  27130.1  -1653728
43636 74488.495    1090.0     48.4    -200.4  28030.4  -1653728
43636 74548.555    1160.0     75.9    -350.8  28930.7  -1653728
43636 74608.616    1256.0     61.9    -274.7  29830.9  -1653728
43636 74668.677    1038.0     63.7    -224.4  30731.2  -1653728
43636 74728.738    1183.0     64.5    -315.7  31631.5  -1653728
43636 74788.798    1102.0     60.7    -266.9  32531.7  -1653728
43636 74848.858    1036.0     64.3    -321.0  33432.0  -1653728
43636 74908.918     969.0     51.2    -264.5  34347.5  -1653728
43636 74968.979    1077.0     52.3    -271.7  21896.4  -1653728
43636 75029.039     999.0     60.5    -256.4  22796.6  -1653728
43636 75089.100     987.0     62.5    -310.8  23696.9  -1653728
43636 75149.160    1133.0     61.5    -366.6  24597.2  -1653728
43636 75209.222    1407.0     59.3    -237.5  25497.4  -1653728

 

[Swistheater]

me@RT-AC86U:/tmp/home/root# ping -c 5 us.pool.ntp.org
PING us.pool.ntp.org (66.228.58.20): 56 data bytes
64 bytes from 66.228.58.20: seq=0 ttl=54 time=22.960 ms
64 bytes from 66.228.58.20: seq=1 ttl=54 time=22.330 ms
64 bytes from 66.228.58.20: seq=2 ttl=54 time=22.148 ms
64 bytes from 66.228.58.20: seq=3 ttl=54 time=22.109 ms
64 bytes from 66.228.58.20: seq=4 ttl=54 time=21.830 ms
--- us.pool.ntp.org ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 21.830/22.275/22.960 ms
me@RT-AC86U:/tmp/home/root# ping -c 5 time.cloudflare.com
PING time.cloudflare.com (162.159.200.1): 56 data bytes
64 bytes from 162.159.200.1: seq=0 ttl=59 time=2.154 ms
64 bytes from 162.159.200.1: seq=1 ttl=59 time=3.022 ms
64 bytes from 162.159.200.1: seq=2 ttl=59 time=2.768 ms
64 bytes from 162.159.200.1: seq=3 ttl=59 time=2.741 ms
64 bytes from 162.159.200.1: seq=4 ttl=59 time=2.629 ms
--- time.cloudflare.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 2.154/2.662/3.022 ms

Nice improvement!

This is my response to ping and ntp
https://www.snbforums.com/threads/r...-12-is-now-available.57220/page-5#post-499857
You are only seeing those good pings because they are apart of cloudflares any cast network and at any rate it does not equate to accuracy as much so as availability. Cloudflare uses Stratum 3

Stratum 3 is similar to the Stratum 2 clock system, but it tracks an input over a wider range. A Stratum 3 clock requires a minimum tracking range of 4.6 x 10-6. The short term drift for Stratum 3 is less than 3.7 x 10-7 in 24 hours. That's about 255 frame slips in 24 hours during holding.

reference is https://blog.bliley.com/what-you-should-know-about-stratum-system-levels .
so for its purposes, it makes since you would have better pings and less latency, but that does not always equate to better accuracy.
for the average home users it should be accurate enough, but i suppose using pool.ntp.org you would have a more wider rage of accuracy due to they are not strictly only stratum 3 .

here is information about stratum network frame slip

What Happens During a Stratum Network Frame Slip?
What happens when a frame slip occurs when a clock system is in a holdover condition? Does all the other network equipment stop working?

Voice related equipment tend to re-synchronize quickly. Sometimes a pop or a click will occur, but this is not typically an issue.

Data circuits may lose some bits...it all just depends on the data rate being transmitted and if forward error connection is being used or not.

Multiplex equipment that provides add and drop services might interrupt all outputs while a new source of synchronization is acquired. These interruptions can cause the entire network to be fully inoperable if due to circuit noise. A network slip in this case can be thought of like the domino effect. The slip leads to more slips down the chain of connections.

While there can be some circuit interruptions, a clock system provides a stable frequency source during times of circuit impairments. Connected equipment is not effected until the clock holdover drift results in a slip.

A high quality, stable clock will transform a network that experiences problems 2-3 times a day to a network that maintains timing even through major slips or outages. The network will continue to operate effectively until the outage is corrected (assuming the correction time is similar to the time of the 1st frame slip).

The best way to minimize the chances of frame slips occurring is to choose a high quality clock system and engineer the network correctly. With great reliability and maintainability, near perfect timing can be achieved.

 

[Swistheater]

this is my most recent information collection from the great ntpmerlin.

ntpq -4 -c rv | grep jitter
mintc=3, offset=0.300546, frequency=7.128, sys_jitter=0.171691,
clk_jitter=0.358, clk_wander=0.063, tai=37, leapsec=201701010000,

 ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.cloudflare .POOL.          16 p    -   64    0    0.000    0.000   0.002
 time.nist.gov   .POOL.          16 p    -   64    0    0.000    0.000   0.002
+2606:4700:f1::1 10.155.8.4       3 u    4   64  377    9.850    0.642   0.490
+2606:4700:f1::1 10.155.8.4       3 u   64   64  377   10.462    0.739   0.760
-2610:20:6f97:97 .NIST.           1 u  140  256  377   61.050    2.813   1.942
+162.159.200.123 10.155.8.4       3 u   14   64  377    9.839    0.729   0.617
*132.163.96.1    .NIST.           1 u   61  128  377   54.961    0.091   0.864
+162.159.200.1   10.155.8.4       3 u    1   64  377    9.821    0.171   0.614
-129.6.15.29     .NIST.           1 u  111  128  377   39.979    0.825   0.261
+132.163.97.3    .NIST.           1 u   90  128  377   55.982    0.035   1.478

you have to thank @Jack Yaz for his amazing scripts.

 

[bluepoint]

Cloudflare uses Stratum 3

I think cloudflare;s public NTP servers are Stratum 2's according to the author's blog.
https://blog.cloudflare.com/secure-time/

 All of our servers are synchronized with stratum 1 time service providers, and then offer NTP to the general public, similar to how other public NTP providers function.

 

[Dabombber]

And I'm also unsure how TLS will help you set up a clock that is not yet configured, as TLS requires an already accurate clock...

This also confuses me, since the very first process in the protocol draft is connecting to the key exchange server using TLS. I guess they assume Roughtime is being used first, but then that completely eliminates time based key attacks and the need for NTS in the first place.

The whole thing seems more like an intermediate step towards a complete time protocol which combines NTS and Roughtime.

 

[Swistheater]

I think cloudflare;s public NTP servers are Stratum 2's according to the author's blog.
https://blog.cloudflare.com/secure-time/

 All of our servers are synchronized with stratum 1 time service providers, and then offer NTP to the general public, similar to how other public NTP providers function.

Well they all appear to be reporting a 3u not a 2u, maybe they are linked off of stratum 2 servers which means when it gets to you it is a stratum 3 meaning they get their time source from a stratum 2 which makes them a stratum 3 source.
If their any cast got their time from a stratum 1, then by the time it got to you it would be stratum 2. Some where down the line they probably sync with a stratum 1 but their anycast is syncing with a stratum 2 reporting it as a stratum 3.

 

[Swistheater]

Here is a test for you

 

[Raphie]

long story short:
1. Ping to time server has NOTHING to do with clock accuracy
2. The clock is embedded in a 64bit message, that together with latency compensation, sets your local time to the microsecond
3. Clocking is not a continuous stream (though it can be) once the local clock is set, for prosumers it's already overkill to sync once every 24h as there probably no measureable drifts (maybe some picoseconds)

Conclusion: ANY timeserver will give you the same accurate LAN time.

 

[gattaca]

Great discussion. There's a wide range of needs, opinions, facts and speculations outlined in these nearly 60 posts. After working on/off with NTP for nearly 3 decades, I've encountered many misunderstandings about NTP and how to operate NTP effectively. I'll add the following comments for your Sunday AM entertainment. YMMV.

1. The NTP protocol / process to/from NTP server(s) and a requester was designed by the engineers to compensate for network delay within some acceptable tolerances. (I forget what the range is..).
   1. As often said earlier, do not get too hung up or obsessed about pings times reported.
2. The use of "large public pools/sandboxes" has always bothered me a bit but more below.
3. NTP was designed decades ago, to handle and disperse time via stratums and pooling nicely. I respect those engineers greatly for understanding the important of "time" in the very early days of computing communications.
4. The biggest gotcha I advise ITers is to always specify a minimum of 3 reliable and trusted NTP sources in their ntp.conf and other NTP control structures.
   1. That's one reason that single default of "time.windows.com" has always been WTH were they thinking (or not) or maybe the Windows NTP code does things to compensate for having a single entry...IDK 100% for sure. But I cannot remember anymore how many times I've explained this to IT folks and suggested they look up how to add multiple sources on the company's domain controllers!
5. Why? Generally by having less than 3 reliable NTP active and working sources opens the requester up to a "man-in-the-middle" attacks.
6. Typically, I prefer having 5-10 RELIABLE sources which are usually not the huge pools but I do use them.
   1. Then just let NTP do what it was designed to do - evaluate and hone in on the most reliable and accurate sources in the list!
7. Understand that with ntpd, the ntp.conf files are only parsed for the timeservers when ntpd is first started and clearly understand above.
   1. When NTP starts, and pools are configured, it requests an NTP server in that pool. From that point forward, the ntpd will be talking to that NTP server. Your ntpd is not going to magically rotate thru the pool until the NTPD is restarted - at least not that I've ever seen.. Maybe newer versions do?
8. When NTP's engineers designed for stratums, they were thinking longer term so that NTP could handle billions of requests. There's nothing wrong with using a RELIABLE NTP Stratum 3! The key everyone needs to understand what's backing that source and what impact that may have on a SLA or critical business process.
9. One of my favorites is so many networks are setup and source NTP via their switches and/or routers. These are leveraged as "good" timesources provided by IT. I cannot tell you the number of outages and problems this causes. Routers and PCs do not have the clock chips on their boards to be extremely accurate time-servers for critical business functions. Most home users - no, problem.
10. Is the source some "router" tucked away in a closet with relatively inaccurate oscillator or clock chip?
11. Is it a PC-class box which has a very inaccurate and drifting "clock chip" b/c these chipsets were never designed to keep accurate time, only "good-enough" time?
12. Is it a mainframe-class box which is designed to keep very accurate time? (Big, big difference from the above.)
13. Is it a very accurate NTP-type device which is designed to maintain accurate time and syncs with known GPS or other rock-solid source?...
14. FWIW, in one case, teams had setup multiple NTP servers in a private infrastructure on routers and PCs. They used a rotating DNS query to vary the IT list of internal NTP servers. I think the goal was to use a ntp.conf with a single entry timeservername.ZZZZ.com - good thought but this has caused countless gotchas / issues for many reasons stated above and below. If they would just use NTP.conf with multiple NTP servers as intended....
15. These forums and discussions are a great source of information for a large community.
16. If Cloudflare wants to offer a NTP time service, then what they are backing that service with matters. If ITers or home users add cloudflare for NTP, that's fine as long as they understand what that means.

Bottom line:

1. Understand and know who and what you are trusting to serve your business accurate time.
2. Use 5-10 trusted and accurate NTP timeservers or pools
3. Check/monitor periodically that the sources you have chosen remain viable.
4. Does your NTP setup meet all SLAs a/o requirements and are you protected from MIM attacks?

I often refer to the now-infamous "Star Trek:TNG" episode where the enterprise is battling the Borg. Piccard has been rescued but remains connected to the Borg. Piccard tells Data put the entire Borg collective "to sleep." While it's not a perfect example of how having the wrong time can foul up a corporate / enterprise, the point is it alludes to it and the man-in-the-middle trusting.

Having least 5-10 reliable NTP entries in ntp.conf is a good thing. So if Cloudflare's pool is one of them, then bravo! What occurs frequently is we have a lot of great people reading these forums. We then take what we learn and apply to our work lives or share with our work environments. So if your company is struggling with the many things that poor-NTP practices can cause, then our discussions are the best form of education I know. There are always people with more knowledge and experience. But never be afraid to ask questions or understand the why... Peace.

 

[Swistheater]

Great discussion. There's a wide range of needs, opinions, facts and speculations outlined in these nearly 60 posts. After working on/off with NTP for nearly 3 decades, I've encountered many misunderstandings about NTP and how to operate NTP effectively. I'll add the following comments for your Sunday AM entertainment. YMMV.

1. The NTP protocol / process to/from NTP server(s) and a requester was designed by the engineers to compensate for network delay within some acceptable tolerances. (I forget what the range is..).
   1. As often said earlier, do not get too hung up or obsessed about pings times reported.
2. The use of "large public pools/sandboxes" has always bothered me a bit but more below.
3. NTP was designed decades ago, to handle and disperse time via stratums and pooling nicely. I respect those engineers greatly for understanding the important of "time" in the very early days of computing communications.
4. The biggest gotcha I advise ITers is to always specify a minimum of 3 reliable and trusted NTP sources in their ntp.conf and other NTP control structures.
   1. That's one reason that single default of "time.windows.com" has always been WTH were they thinking (or not) or maybe the Windows NTP code does things to compensate for having a single entry...IDK 100% for sure. But I cannot remember anymore how many times I've explained this to IT folks and suggested they look up how to add multiple sources on the company's domain controllers!
5. Why? Generally by having less than 3 reliable NTP active and working sources opens the requester up to a "man-in-the-middle" attacks.
6. Typically, I prefer having 5-10 RELIABLE sources which are usually not the huge pools but I do use them.
   1. Then just let NTP do what it was designed to do - evaluate and hone in on the most reliable and accurate sources in the list!
7. Understand that with ntpd, the ntp.conf files are only parsed for the timeservers when ntpd is first started and clearly understand above.
   1. When NTP starts, and pools are configured, it requests an NTP server in that pool. From that point forward, the ntpd will be talking to that NTP server. Your ntpd is not going to magically rotate thru the pool until the NTPD is restarted - at least not that I've ever seen.. Maybe newer versions do?
8. When NTP's engineers designed for stratums, they were thinking longer term so that NTP could handle billions of requests. There's nothing wrong with using a RELIABLE NTP Stratum 3! The key everyone needs to understand what's backing that source and what impact that may have on a SLA or critical business process.
9. One of my favorites is so many networks are setup and source NTP via their switches and/or routers. These are leveraged as "good" timesources provided by IT. I cannot tell you the number of outages and problems this causes. Routers and PCs do not have the clock chips on their boards to be extremely accurate time-servers for critical business functions. Most home users - no, problem.
10. Is the source some "router" tucked away in a closet with relatively inaccurate oscillator or clock chip?
11. Is it a PC-class box which has a very inaccurate and drifting "clock chip" b/c these chipsets were never designed to keep accurate time, only "good-enough" time?
12. Is it a mainframe-class box which is designed to keep very accurate time? (Big, big difference from the above.)
13. Is it a very accurate NTP-type device which is designed to maintain accurate time and syncs with known GPS or other rock-solid source?...
14. FWIW, in one case, teams had setup multiple NTP servers in a private infrastructure on routers and PCs. They used a rotating DNS query to vary the IT list of internal NTP servers. I think the goal was to use a ntp.conf with a single entry timeservername.ZZZZ.com - good thought but this has caused countless gotchas / issues for many reasons stated above and below. If they would just use NTP.conf with multiple NTP servers as intended....
15. These forums and discussions are a great source of information for a large community.
16. If Cloudflare wants to offer a NTP time service, then what they are backing that service with matters. If ITers or home users add cloudflare for NTP, that's fine as long as they understand what that means.

Bottom line:

1. Understand and know who and what you are trusting to serve your business accurate time.
2. Use 5-10 trusted and accurate NTP timeservers or pools
3. Check/monitor periodically that the sources you have chosen remain viable.
4. Does your NTP setup meet all SLAs a/o requirements and are you protected from MIM attacks?

I often refer to the now-infamous "Star Trek:TNG" episode where the enterprise is battling the Borg. Piccard has been rescued but remains connected to the Borg. Piccard tells Data put the entire Borg collective "to sleep." While it's not a perfect example of how having the wrong time can foul up a corporate / enterprise, the point is it alludes to it and the man-in-the-middle trusting.

Having least 5-10 reliable NTP entries in ntp.conf is a good thing. So if Cloudflare's pool is one of them, then bravo! What occurs frequently is we have a lot of great people reading these forums. We then take what we learn and apply to our work lives or share with our work environments. So if your company is struggling with the many things that poor-NTP practices can cause, then our discussions are the best form of education I know. There are always people with more knowledge and experience. But never be afraid to ask questions or understand the why... Peace.

I concur, there is nothing wrong with stratum 3, my point of bringing it up was the article writer has you believing one thing, but what actually is there is another. Stratum 3 can be good while being used along with other servers. I use the option POOL in my .conf vs. Server for the failover options. While using Server works it will not stop trying to use that specified server if it fails , where as if you told it to pool it will allow it to break away from a failed connection and move onto a different one.

 

[Swistheater]

after running time.cloudflare.com for 24 hours along with another time source, i can effectively say, that for the average consumer it would be decently reliable time source.