[ntp:hackers] Re: [ntp:questions] Re: Public servers?

Brad Knowles brad.knowles at skynet.be
Wed Aug 6 13:45:42 PDT 2003


At 4:03 PM +0000 2003/08/05, David L. Mills wrote:

>  The world is getting too complicated. Letting ntpd sift the candidates
>  for best quality is clearly a win and nothing you can do to better that
>  choice will improve the choices. Really believe that, in spite of router
>  hops, hidden networks, etc. On the other hand, your process may be to
>  sift a much wider choice of servers on other grounds, such as router
>  hops, traceroute, etc.

	Some people (e.g., Tim Hogard) are very concerned about only 
using servers that are "close" to them.  I'm guessing that they find 
that using servers that are topologically further away tends to cause 
too many problems with NTP, especially when you take into account 
international transit choke points, etc....

	Unfortunately, some areas of the world are very poorly served by 
pool.ntp.org.  We need to work on that.

	Moreover, because of the way ntpd works and the way the resolver 
code works, ntpd will usually only ever see one IP address for 
pool.ntp.org, and that may be a machine that has a very poor stratum 
rating, a bad clock, high jitter, and a whole host of other problems 
that may make it a very poor choice for use with NTP.


	Until we can modify the code for ntpd to be more DNS/IP aware, 
and see all the IP addresses returned by pool.ntp.org, and then check 
each and every one of them and take only the best, we've got a 
problem.

	Indeed, so long as we have way more IP addresses listed for 
pool.ntp.org than can possibly fit into a DNS 512-byte UDP packet, we 
will continue to have a problem even after ntdp becomes more DNS/IP 
savvy -- you don't really want all ntpd servers around the world 
constantly keeping tabs on all 78 servers listed in pool.ntp.org, do 
you?


	I imagine that pool.ntp.org will probably always return more 
servers than you realistically want to track on an ongoing basis, and 
towards that end we need to look at ways we can try to manage that 
process.  We can do that within the ntpd code itself, but until such 
time as that happens, we may need to have scripts and other tools to 
help us.

	My idea is that we should take the full list of IP addresses 
returned by pool.ntp.org, sort them by some selection of criteria, 
and then take the top ten or top five servers, and that is what we 
present to ntpd.

	This would be even better if we could have the script recognize 
the previous pool.ntp.org servers that had been listed, so that we 
can include them in the list of servers to be considered, and take 
the top ten or top five from that combined list.  This would give you 
something akin to a Newton-Raphson method of successive 
approximations in terms of finding the "best" servers (by whatever 
criteria you use for "best").


	Having a script of this sort which runs on a periodic basis (you 
decide what is appropriate) would avoid the problem of statically 
building in IP addresses of machines that are then buried when some 
vendor ships some new net.appliance, and depending on the selection 
criteria, should allow people to automatically find and start using 
new servers that are "better" than the ones that had previously been 
advertised.

	To avoid the static IP address issue, I don't see much alternative.

>                         This is bogus, unless you have in mind other
>  considerations such as service area, access controls, etc. I assume
>  that willingness to join pool.ntp.org is implicit statement of
>  willingness to provide synchronization regardless of access policy
>  and service area. In that case, letting ntpd choose among candidates
>  is the right approach.

	I want ntpd to choose amongst the candidates that we present to 
it, but in it's current form I don't want it using just one IP 
address for pool.ntp.org, nor do I want it trying to track all 78 
servers that are actually listed in pool.ntp.org.

	I'm trying to find some happy medium, and it strikes me that 
maybe we might want to use other criteria in terms of selecting the 
set of servers to present to ntpd, such as topological distance.

-- 
Brad Knowles, <brad.knowles at skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)



More information about the hackers mailing list