[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