OK. But at the moment you have the situation where you could be providing very good time, from a root source (in my case better than 1ms accuracy). But, the monitor station 10k miles away says, nah, no good.
Meanwhile, someone with a terrible connection in LA, provides really good time to the monitoring station next door, but has absolutely terrible connectivity outside west coast is currently getting a solid 20.0. My point is, the current solution certainly isn't good, and your own reasoning says so. On 23 February 2017 at 22:21, Arnold Schekkerman <[email protected]> wrote: > On 23-02-17 16:12, 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. > > This is usually a temporary thing, affecting only a very limited number of > servers > (you can check the graphs like http://www.pool.ntp.org/zone/europe). > > > > 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. > > Doing an AND for each level is the only way to go in my opinion. That is, > if you > really, really want to put in the effort required for multiple monitors. > Do our > clients have any practical problem right now? > > What you are doing basically in this case is to set up multiple > independent pools > with their own local monitoring system. As far as I know, all software is > on > github, so you can test this relative easily. Ideally you deploy a monitor > in each > network of each company providing connectivity in that area. > > Note that this solution assumes connections are available from your central > scoring/DNS system to each monitor. This, while you know you have > connectivity > issues to an NTP server in the very same network. What do you do if you > lose one > monitor? Take down the whole area? > > Anyway, if you are willing to experiment, I am very curious to the > results! I > expect scores to actually drop faster than they do now. > > > > 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. > > This brings one other aspect to mind. How many clients will benefit from > this > approach? Most clients simply use the pre-configured vendor pool or the > global pool > 'pool.ntp.org'. The clients taking the trouble to configure their > (s)ntp-client > with a country or continental pool usually know what they are doing and > configure > some more known servers as well. They deploy some kind of continuous ntpd > process > that does not even know whether a server is temporary out of the pool, > unless they > lose connectivity... > > I guess the only situation that benefits from a local, independent pool > system is > within countries where network traffic is actively filtered at the border > (China, > N-Korea, etc.) > > Arnold > _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
