Just wanted to say that I had a lot of fun setting up this project and tuning my server deployment and dashboards. Time servers really do produce some fun Grafana data to look at.
I know it’s said that the pool can always use more servers, but I wanted to ask the project operators a few questions about the current geographic needs. Where does the project actually need more servers today? Does adding more nodes in the same general location as existing ones just to take more queries still contribute additional value from the project’s point of view? I assume either way, more geodiversity is strictly better, so also just wondering if there is a list of coverage map that could help operators know where more servers would have the most impact.
Thanks!
EDIT: Related threads helped me find the search button, so I found the answer
I have the IPv4 for it so I will try to add some more nodes.
Short answer is that more servers is better! There are some countries that are “more underserved” than others, but typically those are ones where it’s more difficult or expensive to run a server and realistically we’re more likely to serve them better from other countries anyway.
No idea where you are.
But there are countries that need extra servers to support them.
Like Belgium, but there are many more.
However, you better check your own load/country first before adding your server to other countries.
Simple method, check number of people in your country divide it by the number of IPv4 servers (IPv6 is mostly dual-stack).
Belgium has about 12mln people / 41 servers = so each server roughly does 292K people.
Then e.g. Netherlands 17mln people / 200 servers = 85K people to serve.
Germany 83mln / 559 servers = 148K
I know it shouldn’t be calculated like this, but it gives a rough idea how poor it is for some and very good for others.
Would be nice if the pool could make an estimate list of servers versus population (or DNS-requests), then we know what countries have little servers and could expect a high load on them.
Maybe it’s already in place, don’t know. But it would help.
@Bas this is assuming that each from these 292k people have only one NTP querying the time. You can safely double or triple that value as many have TVs, phones, tablets, routers, etc, all of which query some NTP server in the pool
I created a page showing some countries and the number of active ipv4 and ipv6 pool servers in each compared to the population of that country. It ranges from China and India with about 0.03 servers per million to Liechtenstein with about 268 pool servers per million people - 11 servers for 41,000 people gives some big numbers.
As others have said this is in no way scientific but may be useful to show people where servers may be needed, and possibly may not be needed. Enjoy.
It is a PDF file because that was the easiest way to get it from the spreadsheet to the web.
I was looking at the “Count” values reported for NTP servers in the current API. It seems to reset once per day, but it doesn’t start at 0. I assume it’s the number of DNS responses containing the IP address of the server.
I compared the rates at which these counts are increasing for my 10 servers in the pool with their actual measured NTP packet rates. The ratio seems fairly consistent, about 1:13 to 1:21, with one outlier of 1:60 in Singapore. I tried this only for IPv4.
Assuming this NTP by DNS approximation works reasonably well for all countries, from the server that has the maximum reported “Points” (in permyriad) in each country (ignoring servers that are in multiple zones), I get the following top 20 most busiest zones:
CC
Max points
Avg. points
cn
49.4
12.2
br
32.7
20.0
mx
29.2
18.0
jp
28.2
4.2
sg
27.6
3.1
ph
26.3
10.3
ar
25.0
9.4
in
24.0
7.2
us
18.4
5.5
nz
18.1
4.7
co
16.3
12.2
vn
16.2
12.9
id
15.9
6.5
tw
15.4
6.1
hk
14.9
4.1
th
13.4
5.3
tr
13.2
3.1
ir
12.6
5.8
kr
11.9
6.5
it
11.7
4.7
The max values compare the load of the most busiest server in the zone. The average values compare the average load, but there can be a long tail of servers that are not set to their maximum acceptable speed, so I’m not sure how meaningful that is.
I would say, stop focusing on location and number of servers. NTP is all about accuracy. Lots of servers in one location, it does not matter if time given is blah.
We need a new way to measure how good NTP is in a location.
Yes and no. Yes, NTP as such is about accuracy. At the same time, the pool is about capacity and coverage. As it says on the website, “this project is about load distribution mostly”, also based on how the project came about.
The pool is now default in so many devices, that load needs to be handled somehow, else the remaining servers, however accurate, will simply get overwhelmed. Not an issue in some places, but definitely an issue in many, if not most places.
Then, many if not most clients don’t even care that much about accuracy (think door bells, toaster ovens, printers, Linux distributions that use timesyncd as default time daemon, …). I am not saying accuracy is irrelevant, but capacity and coverage are more important, with a decent level of accuracy - as the monitoring ensures, and then is in the responsibility of the client to pick the best upstream.
And as others pointed out before, if someone has specific requirements, they wouldn’t/shouldn’t use the pool, but rather pick specific upstream servers that serve their need. Or even run their own stratum 1 server, with a range of options as to how elaborate, and thus accurate and resilient the solution can be.
Beware that IPv6 servers are for 99,99999% the same servers as the IPv4.
So in short, you only need to look at the IPv4 servers and count all IPv4+IPv6 requests together to see how many requests ALL servers get.
Also, in the export you get, the speed-limit’s should be given, else the requests/server is useless.
If e.g. China has 10 max-gigbit-servers and redirect ALL ntp-traffic to those servers, then it may look bad, but in fact it’s not. They can do this, without the pool knowing about it.
Where in Belgium this doesn’t happen and I can’t set my speed to the max as I get a DDOS on my NTP-server within hours. Just because we don’t have enough servers.
It will be hard to deduct from the pool-numbers. As the pool only knows the DNS-requests, not if they are proxied or altered to have a longer TTL.
From where do you get this number? There’s certainly many servers that provide services both via IPv6 and IPv4. But just as there are many servers that provide services over IPv4 only, there is already a significant, and ever-growing number of IPv6-only servers. Be it because those are often cheaper to obtain nowadays than servers with IPv4, be it that the IPv4 side of things is too challenging in some zones so dual-stack servers are enabled for IPv6 only, or for other reasons (e.g., shared IPv4 address only but dedicated IPv6 address(es)). There’s even zones that provide services only via IPv6, just as there are zones that only provide services via IPv4.
What is certainly true is that overall, IPv4 traffic certainly is in the majority. But while most underserved zones suffer primarily from too much IPv4 traffic, there are a few with high IPv6 adoption rates where also the IPv6 side of things can be quite challenging, e.g., India, Pakistan, Bangladesh, to name a few, or some in South America. So a differentiating approch is needed.
I don’t really understand yet what you mean by that, but it certainly needs to be given some thought as to how to account for the mix of IPv6 and IPv4 traffic, and that the load on some/many servers comes from the combination of both.
I think as a starting point, it could make sense to consider the two independently, and see as one digs through the data as to whether a clearer picture emerges as to how best to combine the two into a single picture. Also considering that the “net speed” setting is separate for the two protocols for servers that support both, so a server operator can tweak them to their need to get an overall traffic volume/rate that matches their capacity.
Whatever the detailed DNS behavior, the observations described by @mlichvar, and the derived estimated ratios, are good enough to work with, I think. Trying to look at this bottom-up, i.e., looking at individual DNS queries, and how they are cached, or not, and impact of TTL values etc., and trying to derive from such a detailed view and modeling the resulting NTP packet rate, severely risks that one misses the forest for all the trees.
How do you know it’s not bad? How do you know that those servers aren’t struggling? Why aren’t there more, smaller server then, if the big ones who can take a bigger load choose to do so, but smaller ones cannot join because even at 512 kbit setting, there is too much traffic?
I know your experience has been almost traumatic, but the situation in the BE zone is child’s play compared to what is going on in many other zones around the world.
Well, not sure where you get all your strange and mostly unfounded claims from, but I do (in cooperation). And there are a sufficient number of reports in this forum, including numbers. Just have to read them, and grasp what they say and mean.
Not sure what you think this adds to the discussion, sounds more like advertisement or AI slop to me, but without any apparent bearing on the subject of this thread whatsoever.
