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/
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
@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:
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?
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.