I personally agree with the majority of this. I mean we have DNS doing a
similar thing (localized registration isn't too dissimilar from
localized monitoring) in the form of ccTLDs so why should the pool not
follow along especially when the pool suffers due to only having one
monitoring node and the unreliable nature of peering issues and routing
issues in general? Though there is one problem that I forsee with this:
DNS zone control. You'd still need these trusted stations to communicate
to the main monitoring node in some API-like fashion to tell it "hey,
add/remove this IP address to/from the round-robin DNS for my
country/region please." Is it probably a simple thing to do? Simpler
than dealing with the issues currently presented at least, yes. Very
easy? Not a chance in hell unfortunately. Although I suppose local score
cache aggregation (make it so the server trying to be added to the RR
DNS has to maintain a score >=10 for at least 3-5 additional checks to
get confirmed as good and have API communication to have it added occur)
could be considered a viable solution to decreasing overhead on this.
Another issue is that it's no small feat to coordinate this and, more
than likely, we'd need to adjust the code base for monitoring so that
all monitoring nodes talk to each other providing an aggregate weight
based on location and connectivity for NTP servers and the monitoring nodes.
Just my two cents here.
Lucas
On 2/23/2017 9:12 AM, Peter wrote:
But, in this case could it not be smarter? We have separate pools for
worldwide, europe, country level already. Now, it seems to me that around
Europe my str 1 server provides very good timekeeping. Outside of Europe
not so much.
What would be the problem (aside from the effort to set it up) to have an
"AND" system in tiers. So for example you have a monitoring station
(trusted people with good connectivity can donate their server by running
it as a process) in at least all continents and preferably at the country
level. So, for country level you need to have a good rating with any
monitoring stations in your country that checks you. At continent level you
must have a good rating for any in your continent that tests you, and at
global pool level, you must always present a good result, whichever station
probes you.
That way, any server in the global pool, you know is on a well connected
host. But, those that have bad transatlantic peering could still be
providing really good results more locally.
On 23 February 2017 at 14:04, Tim Bray <[email protected]> wrote:
On 23/02/17 10:38, Rob Janssen wrote:
It depends on where the routing problems actually are. When the
problem is in some
transatlantic link, there is no issue for the server to be in European
pools.
Well, lets say you host a website. This website pays your bills.
You have 1 monitoring system, and it says your website is down sometimes.
So you blame the monitoring system, and install a second monitoring
system on another ISP. This always reports site up.
So you say `My website is up if either monitoring system thinks it is up`.
Well, then you are wrong, because actually what you are saying is.
`My website is up for half the internet, and down for half the
internet` For most people, that is a problem. Some people can't get
to your website.
(ok, there are some truly crap ISPs around with naff connectivity,
peering disputes, full ports, .... Can't be helped)
Does this apply to the pool?
To me, if a pool server is visible from half the internet, but not the
other half. Somebody puts pool.ntp.org into their computer with an SNTP
client. DNS gives them an inaccessible client. The time doesn't set.
Their conclusion is `The NTP pool is broken`
This is even though the same server might be serving other users fine.
Tim
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
