CloudFlare now opens their time service, time.cloudflare.com, without leap smearing.
It also referenced Network Time Security (NTS), a proposed TLS layer for NTPv4 protocol.
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
Time.cloudflare.com
Hmm, someone added them to the Pool.
https://www.ntppool.org/scores/162.159.200.1
https://www.ntppool.org/scores/162.159.200.123
https://www.ntppool.org/scores/2606:4700:f1::1
https://www.ntppool.org/scores/2606:4700:f1::123
The IPv4 IPs are in the TH zone and the IPv6 IPs are in the US zone. 
Can y’all and Cloudflare work on that? Does the Pool software support adding anycast IPs to scores of different country zones?
(Were they even added with permission?)
All four IPs probably point to shared infrastructure; it might be better to have only one IPv4 IP and one IPv6 IP in the pool.
I compared their time on two of my servers and I was seeing a constant offset of ~2ms compared to my other sources… 
This, despite only a 0.867 ms ping time, traveling from Houston, TX to Monroe, LA on Level-3 (without having to change networks, obviously)…
I forgot location from my other server, ping time was about 27ms, same ~2ms offset…
Anyone else have any numbers to report?
Largely good news for me so far, including in Dallas.
Oddly, my ntpd clients use a poll interval of no more than 64 seconds for time.cloudflare.com.
The ping time from my location (Germany, ~40miles from Hannover) is about 7.6ms with a consant offset of ~1ms.
NTP delay is ~ 7ms
And yes, the poll isn’t going over 64
162.159.200.1 10.48.8.4 3 u 31 64 377 7.556 0.981 1.919
1 Like
@mlichvar figured out what’s going on with the poll interval.
In its responses, Cloudflare is setting the poll field to 0. This seems to cause ntpd clients to set the poll interval as close to 2⁰ seconds as minpoll allows it to.
(ntpd servers echo back whatever poll value the client sent in its query.)
He said that the RFC doesn’t specify what the response’s poll value should be, so what Cloudflare’s doing is legal.
He told Cloudflare about the issue.
TICK.NJ.LOGIPLEX.NET:
server 2606:4700:f1::123, stratum 3, offset 0.000139, delay 0.02728
server 2606:4700:f1::1, stratum 3, offset 0.000009, delay 0.02734
server 162.159.200.1, stratum 3, offset 0.000264, delay 0.02760
server 162.159.200.123, stratum 3, offset -0.000010, delay 0.02794
24 Jun 09:13:47 ntpdate[25283]: adjust time server 2606:4700:f1::123 offset 0.00 0139 sec
TICK.MONTREAL.CA.LOGIPLEX.NET:
server 2606:4700:f1::123, stratum 3, offset 0.001710, delay 0.03903
server 2606:4700:f1::1, stratum 3, offset 0.001594, delay 0.03889
server 162.159.200.123, stratum 3, offset -0.003170, delay 0.03923
server 162.159.200.1, stratum 3, offset -0.003142, delay 0.03995
24 Jun 09:58:01 ntpdate[1078]: adjust time server 2606:4700:f1::1 offset 0.001594 sec
TICK.HK.CHINA.LOGIPLEX.NET:
server 2606:4700:f1::1, stratum 3, offset -0.004195, delay 0.02679
server 2606:4700:f1::123, stratum 3, offset -0.004477, delay 0.02739
server 162.159.200.1, stratum 3, offset -0.004502, delay 0.02716
server 162.159.200.123, stratum 3, offset -0.004467, delay 0.02713
24 Jun 10:00:10 ntpdate[7171]: adjust time server 2606:4700:f1::1 offset -0.004195 sec
TICK2.HK.CHINA.LOGIPLEX.NET:
server 2606:4700:f1::1, stratum 3, offset -0.004521, delay 0.02701
server 2606:4700:f1::123, stratum 3, offset -0.004786, delay 0.02748
server 162.159.200.123, stratum 3, offset -0.004602, delay 0.02679
server 162.159.200.1, stratum 3, offset -0.004527, delay 0.02666
24 Jun 10:01:53 ntpdate[2717]: adjust time server 162.159.200.1 offset -0.004527 sec
The larger difference on the two Hong Kong servers is probably because they are OpenVZ while the other two are KVM, and I don’t know where that host syncs to. tick.nj.logiplex.net is realtime scheduled.
Noah
https://logiplex.net
No, and they’ve been disabled again (some hours ago) at the request of Cloudflare. (You can thank the users doing this sort of thing when you have to go through some verification step to add a server …).
Oh. 
I hope they’re added back with permission.
Personally, I think that the Cloudflare servers should be kept as monitoring only just like the time servers of most large networks like Apple, Google, Microsoft, etc.
If Cloudflare wanted to put them in the Pool, why not?
By the way, at least one of Apple’s IPs is in the pool for real:
1 Like
I suppose that it’s fine if they wanted them in the pool but at the moment it appears that they do not
Now that 162.159.200.1 and 162.159.200.123 (and their IPv6 counterparts) are in the pool again, and with a lot of zones binding. So it is intended and authorized this time?
1 Like
Hi @alica, I’ve not been involved but from what I can see on the management pages I would be reasonably confident that they are legit.
Yes, indeed! They worked with us on getting added appropriately.
3 Likes