Given I’ve seen a few posts/threads here and there about people wanting to help out, but perhaps in under-served regions, with possibly limited bandwidth, I’m curious if there has been any thought to allow people who add their servers to the pool to actually restrict it such that they ONLY appear in certain zones?
For example, I might want my servers to only appear in .us. or .north-america. pools, but not the global pool. (That is, allow the selection of a handful of zones - or at least the ability to exclude the default global zone)
I’d suggest that by default any server that is added, will still be added to the “global” pool, so that this would have to be a conscious decision to NOT provide time to the “#.pool.ntp.org” zone.
Perhaps this is counter to the whole ethos of the ntp pool project, but I figured if this were at least an OPTION, there might be some additional servers added to the more under-served regions?
(This may also not be feasible without a large undertaking or rewrite of the DNS setup, I have no idea )
Well, I’m not 100% sure how the geo dns is designed, but I would have to imagine that from time to time it will have to pick a random host if it’s unable to immediately determine an appropriate geo location for the requestor.
Even if this should be a minimal amount of traffic, there can surely be times when a node would prefer to have truly local traffic only, again perhaps when bandwidth is limited, etc.
Again - this would be a feature request/augmentation… the default behavior could simply be the way it works now.
Currently, edit your server’s bandwidth setting to 384kbps or 512kbps then your server will be removed from global pool. In really underserved regions, the bandwidth setting does not work at all… Your server can always get slammed no matter the setting.
What alicia said is correct AFAIK… I believe below a certain bandwidth setting your server is NOT included in the global / default pool… Only the local zones. Of course it doesn’t guarantee the person making the requests are in that geolocation, merely that’s what the client is configured for. The actual bandwidth setting I think is mentioned somewhere on the pool pages, but I didn’t see it quickly glancing on the “joining” or “manage” pages.
I believe Ask was going to make some code changes (eventually) so that the pool DNS would geo-target any requests instead of the need for people to manually configure their clients for whatever zone. This would help out a lot for pre-configured clients or hard-coded devices that might have been set with like the US or Europe, but end up elsewhere in the world. There was a lengthy discussion about some Android devices exclusively hitting the US pool when they were located all over the globe due to a hard-coded config.
As-is, the bandwidth settings are pretty well balanced. I started my server out low and slowly bumped it up monitoring the QPS. Once you figure out the baseline number, calculating out how much traffic you would get at a certain speed setting is quite trivial.
Also remember that NTP packets are only 48 bytes. So even at 1,000 QPS (which is about what my server is getting at 250Mb pool setting, US location), that’s only ~0.384 Mb/s of bandwidth up & down… When I had it at the 50Mb setting it was around 200 QPS, or about 77Kb/s bandwidth…
It’s hard to really say how many QPS you would get at the real low rates (i.e. 1Mb or below). In theory it would be single-digit queries per second, if all the clients were well behaved. Except I’ve found a very very small percentage (~0.4% to be precise) of misbehaving clients that like to continually query 1/s (or faster)…
Yes, I get traffic from all over the world, I posted a chart in another thread (link below). About 78% of my traffic was US, next highest was CN at almost 8%, and RU at almost 3%…
Yeah, I realize this isn’t normally a big deal, but I had been sifting through the forums and noticed at least a couple posts about this sort of thing, and figured I would create a post to make sure it’s obvious this sort of thing had been asked (not in so many words) before.
Is the “set your bandwidth really low and you’ll only be advertised to your local pool” documented anywhere? I would have expected something like that to be shown at least in the right-side “help” when Adding/Managing servers.
Yes, obviously I see the ‘@’ disappear when at 512-or-lower, but I am also not sure if most people know what the ‘@’ means, when they are first signing up.
That said, I could still see situations where someone might want to be ONLY listed in their hyperlocal pool, and not even in the 2nd level one (e.g. “Europe” or “North America”, etc)
Special arrangement (opt-out default cc zone, opt-in other cc zone, etc) should be mailed to the address listed under the management page. If the admins read them in time though.
Besides, this is what you may see in a really underserved zone:
My weak server can only stable output at about 6k pps. Around 8am, some other server failed and my loading bumped, causing my server being kicked out of the pool in one hour. Then the whole day of score up and down, sometimes bad trans-pacific route also played a role. Any zone with ≦ 4 servers will face similar problem, because all these servers will receive at least 25% of requests in its zone, no matter the original bandwidth setting. A server registered with 384kbps will receive equal traffic like its 1000mbps friends. You will need a rather strong server and unlimited connection to survive this.
I browsed over some of the pages on the pool site and couldn’t find any references. I know it used to be there. It might have accidentally been edited out (or even intentionally removed for reasons unknown). Probably best to ask Ask.
I don’t know if the code is designed for a “country only” configuration. You can look (and contribute) to both projects on Github: abh (Ask Bjørn Hansen) · GitHub (geodns & ntppool).
While it would be cool to have a very local target level (i.e. city level), it’s just not practical due to the limited number of servers (and underserved or even empty zones) and overall global demand. Even then I’ve found that just because two points might be physically close, the actual network path between the two could travel an absurd distance just to reach a point to switch between different network providers. Like I remember when I lived in Houston, to connect to another machine in Houston I did a traceroute and it went to Dallas, Chicago, DC, Atlanta… Like a huge loop across half the country, even though the other machine was maybe only 5 miles away.
Like I said before, I know Ask was considering switching to a geo-targeted setup so no matter what zone a person configured, they would get servers based on their IP’s geo-location. That should help localize traffic better, but there will still be overflow to help cover the underserved areas.
)