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

David L. Mills mills at udel.edu
Wed Aug 6 16:36:14 PDT 2003


Brad,

Tell me about international choke points. May well be true in some parts 
of the world, but clearly not with the swatch of 20 servers returned by 
pool.ntp.org. I have been running NTP with all 20 for a few weeks now 
and all are just as good and some even better than some of our campus 
servers. Nonetheless, we are very well connected to Internet swamps and 
your experience may vary.

I have no data to suggest nearer servers are better or worse than 
others, and quite a bit of data that suggest router hops and geographic 
coordinates and even roundtrip delay are universal metrics. Recently, 
reaching some servers in the UK required a satellite relay in 
California. There are more hops from here to New England than to California.

For kicks, I did a traderoute to servers in pool.ntp.net and a 
scattering of public stratum 1 servers. Sample results:

?    17   125
NZ   26   350  
SE   22   182
?    16   136
DK   16   142
?    25   150
UK   15   126
US   22   99
US   18   62
CH   13   400
IT   15   168
AU   20   280
CH   21   153
CL   23   204
HK   22   303
MX   21   568

Now, if the criterion is minimum hops, the best choice from here is 
Switzerland, not US servers found so far, and that shows a whopping 400 
ms delay. Mexico is only 21 hops away at huge 568 ms delay, while 
Switzerland is the same number of hops and only 153 ms delay. What's a 
poor manycast scheme to do?

What makes a huge difference in the academic community is the campus 
egress network, which from here is lightning fast for Internet II sites 
(Abilene 2.4 Gb/s) and rather slower for commercial sites (Voicenet 10 
Mb/s). Curiously, some overseas sites egress Abilene and some domestic 
academic sites egress Voicenet. So, the most useful art object I see 
here is a quick traceroute to each revealed destination that stops on 
selected egress routers and reports. If we don't egress via Abilene, go 
find another sucker.

You make some good points that should be tested and evaluated. I don't 
think it necessary to modify NTP at this time, but when it comes time 
for that, the Manycast scheme does most of the work. Just lift the 
multicast layer out ?nd plug in your crafted DNS. For the moment, how 
about a script that constructs/edits the configuration file. That's what 
I did manually in experimenting with pool.ntp.org.

Dave

Brad Knowles wrote:

> 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.
>




More information about the hackers mailing list