Is there any good reason not to let users select the region of their NTP servers? What about letting people set their desired zones during the process of adding a server to the pool? It’d be nice to show some dropdown menus allowing to set regions and countries, instead of letting the system choose based solely on IP addresses. It’d also take the load off the people that answers e-mails sent to do just that.
By the way, if someone could change the zone of my NTP server from north-america to south-america and from US to BR, it’d be great!
I already sent an e-mail but no reply or change so far. I know this is a volunteer service so I’m not complaining or anything, I can only thank everyone involved.
Why would you want to do this?
As the there is no point in seeking a server on a large distance because the inaccuracy will increase.
This because the timing of the internet routing will become more and more unstable.
As such your time-accuracy will only suffer by doing that.
It does try to compensate the time, but if your routing-time is changing all the time, it needs some other way to keep the time stable.
If you use only 1 source, the other source is often the internal timer of the computer, but that timer is far from stable itself. It can vary a lot.
So the other way to compensate that problem is adding more then 1 time-server to poll time from.
This will make time-servers work a lot harder as all clients should start polling more then 1 time-server.
For this reason we have stratum-time-servers (proxies) that use multiple time-sources so the client can use 1 close by server and get the correct time.
Have a look, at the beta system for one of my servers:
The thing is sometimes people want to serve another zone, that may be underserved for example. Or the IP is from another place and the system allocates according to where the IP points. Like my public IP is from Ashburn but the server is actually located at Brazil northeast. That’s why I want to change zones in my case.
This all may be an unorthodox setup but happens. I hope that in the future I can get an Brazilian IP but currently this is it.
That will automatically route them to the nearest (and hopefully) fastest route to a good NTP-server.
If you want to serve the world, you can up the speed-limiter for your server so it get’s more requests.
You are not the only one that is worried about under-served countries, while in fact this is not the case.
There are plenty servers, it’s just that some countries have more and others have less servers.
This does not mean they are starving for time
The system will just select the next best server to serve e.g. Brazil.
In fact, some servers are faster from outside the country then within, as you never know (unless you test) what route the server and client have to follow.
I know that some routes inside Belgium are faster via France then via Germany if a direct routing inside the country doesn’t exists.
Not all ISP’s peer to each other or use peers inside the country.
The reason of splitting the server in the NTP pool by country is to localize the traffic (less hop count and less delay) so probably giving better reachability and better time quality. As your exit IP is routed in the US (Hetzner?), it has smaller delay in the US than in Brazil. The theoretical NTP clients in Brazil should route to US where your IP is located. Then, probably through some kind of cloud VPN the packets are forwarded to your sever in Brazil. The NTP reply packets are taking the same path backward. Overall, it is not the geography that counts, but the network topology. I suggest you to wait till you get a public IP address that is really routed inside Brazil to server the NTP clients in South-America.
Yes, I have a home lab with a server that hosts a multitude of things, including the NTP Chrony server. It’s physically located in Brazil northeast and due to hardware limitations and fixed IP costs, I’m using a Hetzner VPS as public IP via Wireguard. It’s not the best but the latency is around 90ms from my ISP. The deal breaker is that Hetzner is generous with traffic while other providers usually limits to 1 TB in the cheapest plans (it’s only used as a tunnel so I don’t need much RAM or vCPU).
I’m still looking for a solution with an IP from my country or I may test again with the ISP’s fixed IP service to see if now my network can handle. The last time I used it, I had a Raspberry Pi and now is a Ryzen 5 with 32 GB of RAM and NVMe.
Anyway, I started this NTP server to provide time mostly to Brazil and South America (and Global, too), but things get complicated when the external IP is from the US. My server is also in the Global zone but most clients are from North America, as expected.
Oh, but the point with the more powerful server is not about time-accuracy but to handle the number of connections. When I used an RPi, I couldn’t get past 50 Kbps without everything fall apart. At the time I was serving Brazil and South America so there are less servers and more connections per server so I couldn’t handle. This time with a more powerful server I’ll see if the problem is with the computer itself or with something else in the network like the ISP’s ONU.
Again, consumer grade stuff can crawl serving even dozens of UDP connections per second. An NTP server in the pool should be able to respond to hundreds of packets per second. You should consider using commercial grade gear. As is, with consumer grade network gear, no suitable IP address, your contribution to the pool will fall short of being effective, regardless of which country pool you join.
Well, someone changed the zone of my server to Brazil and South America as asked but then some volunteer saw the e-mail I sent the other day and undid the change
@ebahapo I requested a static IP from my ISP to test during February and see how things go. But if it fails (wouldn’t be a surprise), I’ll continue with the Hetzner VPS for now and later spin up something in my country. I guess a commercial grade gear is not viable right now, specially if the bottleneck is the FiberHome thingy. I suppose things works via Wireguard due to how everything arrive locally via a single tunnel connection and then the router and ONU can handle just fine.