I have no grievances, but he makes no sense.
Like we are responding to a chatbot.
Everybody can setup an NTP-server and monitor.
I fail to see the problem.
What does this even mean?
Ok, so you set up your monitors all by yourself, without any support whatsoever from anyone else, including Ask? So you were able to set up the monitor yourself to send data to Ask’s systems, and they would accept the data you sent, and list your monitors without anything having to be done by Ask? Or you needing any specific configuration information that is not available in public sources?
That even if one sets up the software all by oneself, Ask (or maybe some other admin) will have to do just a little bit at least so that the monitor is integrated with the system, e.g., exchange and configure a public/private key pair or related certificate, or otherwise make the monitor known to the system, let it send data to the system, and consider it in the scoring mechanism. And that they are asking for someone to do those things for them that can only be done by Ask or some admin, whatever those things are.
1 Like
Ask doesn’t allow you to setup a monitor if you don’t have a stable NTP-server first.
And anyone can setup an NTP-server, you need no admin for that.
Proof you are able to maintain a good NTP-server, then after time you can apply for monitor-duties.
I’m pretty sure he won’t make you a monitor if he doesn’t have data of your server being stable and provide good numbers.
And here we may have the catch 22, to prove you have a stable server without the current monitors outside of China assigning a low score 
And maybe then solving the eventual next problem of reliably shipping monitoring information outside of China with the great firewall in place 
But maybe the whole “servers in China/more monitors in china” topic should be split from the initial thread in my opinion.
2 Likes
Upto now I have not seen any NTP-server in China that is monitorred.
So start one there and show it’s there.
I fail to see your complaint as there is no proof China is hindered by the pool.
We can not fix China is China is the problem itself. Put one up there, then let us test it. Can’t be too hard now is it?
Have you even looked? If so, you would have found several, I count at least 15 that are active right now. And the point is that there would be even more when the monitoring wouldn’t supposedly be so prone to kicking servers out frequently (note the noticeable fluctuations in total numbers throughout the day).
And to me, asking fellow pool server operators to prove to you that they are operating NTP servers, or to insinuate there are no servers in China, or that it is too hard for someone to operate a server in China, seems rather disrespectful.
1 Like
Still again, no proof of servers running in China.
I have looked at the .cn pool, looked at some of the servers.
Found none that referred back to .cn
So please, show us the China servers. Nothing disrespectful about.
Your constant complaining and not showing servers in China…that is…you figure it out.
Which tool did you use for that screenshot? It looks interesting.
1 Like
I doubt it will make a difference, but let’s see… Based on Maxmind’s GeoLite2-Country-CSV_20240705 and informatively enriched with respective configured zones:
1.117.63.30 GeoIP Country Edition: CN, China asia cn
101.133.146.204 GeoIP Country Edition: CN, China asia cn
110.42.98.138 GeoIP Country Edition: CN, China asia cn
111.203.6.13 GeoIP Country Edition: CN, China @ asia cn
111.230.189.174 GeoIP Country Edition: CN, China @ asia cn
117.80.112.205 GeoIP Country Edition: CN, China asia cn
117.80.231.60 GeoIP Country Edition: CN, China asia cn
120.24.166.46 GeoIP Country Edition: CN, China @ asia cn
124.222.84.253 GeoIP Country Edition: CN, China @ asia cn
124.65.131.109 GeoIP Country Edition: CN, China asia cn
139.199.214.202 GeoIP Country Edition: CN, China @ asia cn
139.199.215.251 GeoIP Country Edition: CN, China @ asia cn
202.112.29.82 GeoIP Country Edition: CN, China @ asia cn
202.112.31.197 GeoIP Country Edition: CN, China @ asia cn
202.118.1.130 GeoIP Country Edition: CN, China @ asia cn
202.118.1.81 GeoIP Country Edition: CN, China @ asia cn
211.68.71.118 GeoIP Country Edition: CN, China asia cn
211.68.71.26 GeoIP Country Edition: CN, China asia cn
219.216.128.25 GeoIP Country Edition: CN, China asia cn
39.105.209.124 GeoIP Country Edition: CN, China asia cn
43.136.79.196 GeoIP Country Edition: CN, China asia cn
I am confident that at the end of the day, people willing to help regarding this topic will not need proof that there are native NTP servers in the China zone.
1 Like
I have a somewhat interesting server-client distribution.
I set this server to the lowermost bandwidth (512k) possible, so it should not receive traffic beyond Asia clients. But in fact it receives MUCH MORE traffic in TW (almost 200x) and some traffic from the other side of the Earth (US & BR). Pretty broken.
Getting traffic from outside a server’s country zone can happen when users from outside the zone explicitly configure any of those. Doesn’t seem very useful to configure zones from the other side of the globe (as compared to using a zone that is much closer to ones own location), so while possible perhaps less likely.
Or when the pool system believes, erroneously, that the client is within the country zone. This can happen with bad GeoIP data - I had a server in Singapore assigned to the US zone until I had the GeoIP data corrected. Or when using a privacy-minded anycast DNS service such as Quad9 or 1.1.1.1. In my tests from a vantage point in Singapore, I observed DNS server backend IP addresses mostly located in Singapore or Asia, but occasionally from as far away as Germany, or Finland, or the US (or maybe, again, the GeoIP data this determination is based on is simply inaccurate).
So I think the rather low percentage (actually, fractions of a permyriad) could be caused by such factors outside the NTP Pool’s system control, rather than the system being broken regarding this aspect.
I noted something similar with my server in Singapore, as well as others I looked at, though the discrepancy isn’t as big in those cases as what you see. My hypothesis is that this discrepancy is caused by the DNS response percentage fraction going into that metric being the result of averaging over a longer period of time (two or three days, IIRC), while the percentage of overall configured netspeed for the country is an instantaneous value (albeit seeing up to half an hour delay from when changes actually occur until they are used for the calculation of the ratio).
In underserved zones, where some servers oscillate out of and back into the pool due to overload (as is my hypothesis happens, e.g., in Singapore, based on my observations) or other reasons, this means that the overall netspeed is high, reflecting all servers nominally active in the zone at one point in time. But since the netspeed does not translate into an instantaneous proportion of a server being included in DNS responses, but the proportion is realized via time share fraction, that may mean that a server moving out of and back into the pool frequently simply might not get its “fair” share of being included in DNS responses, but less. And those servers that are continuously in the pool get a bigger share of being included in DNS responses than corresponds to their configured netspeed portion. (This ties in with a previous discussion elsewhere that the pool system was designed to distribute load over a “large” server population, and that it works sub-optimally when the server population is “small”.)
Not sure though how to verify, or disprove, this hypothesis, or whether it even makes sense. But that is what I have come up with so far.
1 Like
Should be normal when a zone is underserved as i remember
1 Like
Any theory as to why that is?
The aforementioned server was offline for 9 days, and came back online after a broken video card was replaced. After that I observed the share climb slowly but steadily back to ~200x, in accordance to your speculation. 
1 Like
Just to answer your original question in this thread: Yes, I started work on this a while ago!
There are a bunch of use cases for this.
I think one of the things I got stuck on was how to calculate the actual net speed over time for the “client distribution” feature.
A simple first solution could be to do a linear interpolation between 10 and 20 with the current score.
At a score of exactly 10, the effective netspeed is 0. At a score of 20, the effective netspeed is equal to the one set by the server operator. At 15, the effective netspeed is half the set netspeed.
netspeed = netspeed_target * ( score - 10 ) / 10
That calculation could be done every time the score gets updated in the database.