We are running 3 NTP Stratum 2 server with IPv6 in AT pool.
I see, most traffic is coming from Germany. Why ?
I didn’t see any servers under the account with your address. If you email the server-owner-help address (or send me a message here or just post the server IPs in this thread) then we can check they are mapped correctly. Assuming they are my next guess would be that there are some DNS servers in Germany with many IPv6 clients that are mapped to Austria (or an ISP with a DNS server in Austria used by many servers in Germany?).
I built a new tool recently that tracks how often a server IP is returned in DNS answers for each country.
My guess is because Fritz!Box CPE-routers are quite populair in Germany (and so is IPv6) and I believe they have 2.europe.pool.ntp.org configured by default.
Dear All,
sorry for late response but I was on leave.
I manage these 3 server with my github account “github@ma.yer.at” The servers have the following IP addresses: 2001:628:21f0:80::80:29 , 2001:628:21f0:80::80:35 and 2001:628:21f0:80::80:160
The names are entp3.iiasa.ac.at , entp1.iiasa.ac.at and entp2.iiasa.ac.at
… I built a new tool recently that tracks how often a server IP is returned in DNS answers for each country.
And how does it work ? Can you check it for my servers ?
I could send you this endless long “mrulist” with IP addresses as /128 or if you want as unique /32 with counts for each entry.
Resolving names for this “mrulist” takes forever.
This graph, I sent in my initial posting, comes from NetFlow. The internet access router sends its flow data to a central ELK stack server. There I can filter for NTP service and beside lot of other information I get this GeoIP graph just for NTP.
// Hans
I just made it available on the website. Each of your servers is included in about 10% of the DNS queries from Austria (and about 0.5% of queries from Germany).
As mentioned in the other post this doesn’t take into account users in Germany explicitly asking for Austrian servers. At a glance it’s not clear that’d be a meaningful difference for at / de though. (In the last ~28 hours the system has counted 20 million queries a day from users in Germany explicitly asking for another country zone and ~2.5 million from Austria; out of 365 million and 47 million queries overall from those countries).
It is probably because some Austrian servers are much closer in roundtrip times than many German servers, at least from some parts of Germany. Best example is ts1.aco.net, this is less than 9 ms away for my stratum 2 server in Karlsruhe, while the official PTB servers in Braunschweig are more than ten ms away, and very often the routing into the German academic network DFN gets screwed up, which adds up to four additional ms roundtrip time and leads to asynchronous paths, and therefore to large errors.
The four best stratum 1 sites for me are Apple’s Frankfurt servers, University of Erlangen, UUNET NL, and ACO. Everything else in DFN follows behind that, and even ESA’s server is more stable and has shorter roundtrip times than many German universities.
Dear Ask, you wrote “made it available”. Maybe I am blind but can can’t find it. I see the “NTP Check” but nothing which points to “Server Points” or similar.
But independent of that, many thanks for this statistics. Interesting that you see about 10% from Austria. As there are 15 NTP servers available in AT it should be less ( around 7% ) per server.
Also interesting the client distribution: AT 1031 %oo DE 6%oo
When I look for the last 24 h into netflow for NTP client traffic I see 74.3 % Germany, 16.9% Austria and the biggest of the rest is 2.6%
Of course, it’s not necessary that the DNS queries are reflected to the traffic. Maybe some clients do once a DNS query, keep this information for long time and do NTP requests in short intervals and other DNS clients do less queries but with longer NTP intervals.
Dear Sebi, how does the RTT reflect to the selected server. A DNS server gives some random results if there are more than one IPs defined. Typically it does not know about the RTT between the client and the offered NTP server.
This is from one of my 3 stratum-1 servers
oPPS(0) .PPS. 0 l 13 16 377 0.000 +0.003 0.009
*SHM(0) .GPS. 0 l 11 16 377 0.000 +0.171 0.275
dcf77a.iiasa.ac .DCFa. 1 u 28 64 370 0.609 -8.810 2.104
+zeitgebaer.cc.u .PZF. 1 s 43 64 377 1.157 +0.177 0.037
+taktgebaer.cc.u .GPS. 1 s 45 64 377 1.552 +0.011 0.032
178.189.127.147 .ATOM. 1 u 62 256 377 3.754 -0.120 2.204
178.189.127.148 .ATOM. 1 u 72 256 377 3.700 -0.134 0.033
178.189.127.149 .ATOM. 1 u 1 256 377 3.651 -0.069 0.046
Bundesamt fuer Eich und Vermessungswesen is 178.189.127.*
takt+zeit/gebaer are peering stratum-1 server at ACOnet ( we at IIASA use ACOnet as provider )
Braunschweig I am not using since long time, only DCF77 over the air.
// Hans
@HansMayer , see the bottom of the server score page, eg. pool.ntp.org: Statistics for 2001:628:21f0:80::80:35
As I understood the question, he was talking about total traffic, not only about initial requests from new clients. Since NTP will keep good servers and drop the bad ones after a while (if you had enough servers at the start), it does not seem strange that he would see much traffic from IPv6 clients in Germany that kept his server for a long time, after being offered the address during a DNS query. Add to that the people who manually configured their NTP, and realised how close many servers in AT are in network topology.
And since many of the big providers in Germany no longer offer proper IPv4 to their users (or you have to specifically ask for it), instead doing all the IPv4 traffic over gateways, using IPv6 servers is the best hope these customers have for stable time. In that situation, you might want to use e.g. 2.de…, 2.at.…, and 2.nl… to get enough initial addresses from the pools for the selection process to work properly, or you have to add servers manually (which is a very good reason for the pools to offer a couple more IPv6 addresses, not only those in 2.*). Also, as someone already wrote, Fritz!Box routers seem to use the europe pool, which will also offer servers in AT.