[ntp:questions] Re: Public servers?

Brad Knowles brad.knowles at skynet.be
Thu Jul 31 14:51:38 UTC 2003


At 1:27 PM +0000 2003/07/31, Tim Hogard wrote:

>  I generate a different list for everyone that hits the server.   The
>  only way its going to "discover" a limited access stratum one or
>  two server is if you run a web browser on that server.  All it does
>  it ask nearby routers for the time using an NTP version 1 packet.
>  If any of these routers are bothered by 300 packets per second,
>  they have many other problems.

	From what I can gather, it appears that you do a traceroute from 
your server to the IP address of the web browser, then do an NTP 
query to each IP address that appears in the list.  Is this correct?


	If this is correct, I don't see how this is really helpful.  It 
assumes that clients should be configured to get their NTP time sync 
from a router and not a server that has been explicitly set up for 
this task, and the router is likely to be very sub-optimal in this 
role.

	Moreover, it assumes that clients would be able to get this 
information from the servers, since you were able to get a response. 
However, since the clients are not likely to be using NTP version 1, 
this is not an accurate assumption.

	Finally, there is the issue of asymmetric routing -- just because 
you take a particular path getting from your server to their IP 
address doesn't mean that they would take the same path going out, or 
that the NTP query that you sent to a particular external interface 
would be accepted by the same device from an internal address.


	To get a really useful idea of what time servers should be used 
by a particular person, you need to know the network topological 
location of the user.  This is usually closely related to their 
geographical location, but there are places in the world where 
geographical next door neighbors may in fact each be closer to 
somewhere else on the network that is thousands of miles away, due to 
the vagaries of presence at exchanges, international network 
connectivity, etc....

	You also need to know what time servers are topologically close 
to them, what stratum they are, what their jitter is, how much their 
clock is offset, etc....  With NAT, tunneling, VPNs, differential 
routing between IPv4 and IPv6, and a whole host of other issues, this 
"topological distance" issue is actually a very tough problem to 
solve.


	I tried your tool at <http://www.abnormal.com/cgi-bin/findntp>, 
and it gave me the following information:

		194.78.0.170	Thu Jul 31 14:30:05 2003 (3)
		206.24.147.154	Thu Jul 31 14:30:05 2003 (3)
		206.24.146.62	No Time Server
		208.172.139.9	No Time Server
		208.172.130.103	No Time Server
		208.172.129.201	No Time Server
		144.232.8.245	No Time Server
		144.232.204.9	No Time Server
		64.39.2.39		Thu Jul 31 14:30:18 2003 (3)
		64.39.2.217		Thu Jul 31 14:30:18 2003 (3)
		64.49.222.130	Thu Jul 31 14:30:18 2003 (3)

	However, doing a traceroute from my machine to your server, I got 
quite a different list of IP address that should have been considered:

% traceroute www.abnormal.com
traceroute to www.abnormal.com (64.49.222.146), 30 hops max, 40 byte packets
  1  * * *
  2  1.200-200-80.adsl.skynet.be (80.200.200.1)  13.243 ms  83.441 ms  14.849 ms
  3  77.255-200-80.adsl.skynet.be (80.200.255.77)  20.396 ms  15.324 
ms  14.351 ms
  4  ae1-0.intlbnc3.skynet.be (194.78.0.142)  13.242 ms  13.108 ms 
ae0-0.intlbnc3.skynet.be (194.78.0.42)  12.964 ms
  5  gigabitethernet8-0.hsa2.brussels1.level3.net (212.3.234.21) 
15.102 ms  12.437 ms  16.18 ms
  6  unknown.level3.net (212.3.239.161)  13.112 ms  14.514 ms  102.35 ms
  7  so-3-0-0.mp1.amsterdam1.level3.net (212.187.128.14)  17.123 ms 
17.239 ms  16.616 ms
  8  gige1-0.core1.amsterdam1.level3.net (213.244.165.13)  17.877 ms 
18.346 ms  67.14 ms
  9  sl-bb20-ams-1-0.sprintlink.net (213.206.131.45)  20.735 ms 
18.077 ms  37.061 ms
10  sl-bb21-bru-14-0.sprintlink.net (213.206.129.46)  85.764 ms 
20.952 ms  20.806 ms
11  sl-bb20-bru-15-0.sprintlink.net (80.66.128.41)  30.778 ms  21.757 
ms  191.756 ms
12  sl-bb22-lon-13-0.sprintlink.net (213.206.129.41)  25.014 ms 
46.221 ms  26.593 ms
13  sl-bb20-lon-12-0.sprintlink.net (213.206.128.52)  24.543 ms 
34.189 ms  24.777 ms
14  sl-bb21-lon-15-0.sprintlink.net (213.206.128.38)  24.408 ms 
25.508 ms  25.639 ms
15  sl-bb21-tuk-10-0.sprintlink.net (144.232.19.69)  332.334 ms 
153.984 ms  326.642 ms
16  sl-bb23-pen-10-3.sprintlink.net (144.232.20.118)  94.485 ms 
188.57 ms  94.02 ms
17  sl-bb22-pen-14-0.sprintlink.net (144.232.8.178)  92.233 ms 
138.388 ms  232.409 ms
18  sl-bb21-fw-15-0.sprintlink.net (144.232.9.31)  164.889 ms 
269.093 ms  137.888 ms
19  sl-gw40-fw-8-0.sprintlink.net (144.232.8.246)  138.824 ms 
188.795 ms  212.009 ms
20  sl-racks-2-0.sprintlink.net (144.232.204.10)  198.247 ms  144.478 
ms  144.715 ms
21  vl130.core1.sat.rackspace.com (64.39.2.33)  280.645 ms  144.153 
ms  145.634 ms
22  vlan907.aggr7.sat.rackspace.com (64.39.2.218)  147.487 ms 
143.479 ms  143.166 ms
23  0.abnormal.com (64.49.222.146)  158.925 ms  197.75 ms  149.171 ms


	In fact, Skynet (a service of the former PTT Belgacom) uses NTP 
servers provided by Belbone.be (a backbone network service that I 
believe is provided by a different arm of Belgacom).  The official 
servers are ntp1.belbone.be and ntp2.belbone.be (Stratum 2), both of 
which sync from ntp0.belbone.be (Stratum 1, and not publicly 
accessible).

	All Belgacom customers of one form or another should be using 
these two NTP time servers, either directly or indirectly (if they 
set up their own NTP server(s) to slave and redistribute time 
information locally), or they are welcome to set up their own NTP 
Stratum 1 time servers.

	If you check the list of public servers at 
<http://www.eecis.udel.edu/~mills/ntp/clock2a.html>, you would note 
that the belbone servers are the only public servers listed for 
Belgium.

	However, you would not necessarily have any way to associate me 
with Belgacom or Belgium, unless you looked at the topological 
network location and routing maps (e.g., from BGP peering), or maybe 
you were able to obtain useful information from WhoIs or maybe 
radb.ra.net regarding my IP address, who the network owner is, what 
other networks they might also own, etc....


	All this aside, for large providers, it might be best to point me 
towards an NTP server that is outside of their network, as opposed to 
one that is on their network but very far away from me.


	The only real way to resolve this issue is to run a tool on the 
client side to try to find out this kind of information, or perhaps 
to query pool.ntp.org and try to find out which of the returned 
servers have good Stratum values, low jitter, and low offset, and 
then do a "sort | uniq" of the IP addresses on that list, and then 
feed that to NTP.  Of course, that list might change next week, so 
this is something that should be periodically checked and updated.

	My understanding is that client-side tools of this nature are 
already under development.

>                                    They figure they are a little
>  unimportaint site and set things up to talk to a stratum 1 server wihout
>  asking.  Sometimes they even put the IP address into a device and
>  then ship a few hundred thousand.  Thats what we both want to stop.
>
>  You also have the people who figure stratum two is ok but stratum
>  1 must be better.  After reading "In most cases the accuracy of the
>  NTP secondary (stratum 2) servers is only slightly degraded relative
>  to the primary servers and, as a group, the secondary servers may
>  be just as reliable.", they are more likly to use a stratum 1 server.
>  Degraded time and lower reliabilityto the average person means the
>  clocks could be minutes slow as opposed to miliseconds off.

	Agreed.  That is bad.  End users should definitely be discouraged 
from hitting Stratum 1 time servers, and should probably be 
discouraged from hitting Stratum 2 timeservers.  They should be 
encouraged to contact their provider first, who should be able to 
answer these questions.

	Organizations setting up their own time servers to redistribute 
time information locally should be pointed at the Stratum 2 time 
servers, and/or encouraged to set up their own Stratum 1 time server.


	However, I don't see how your tool helps us do any of this.  I 
mean, your tool is interesting, but it seems to me that it is trying 
to solve the problem from the wrong end.

>  I would like to see your page have some wording along the lines of:
>  If your tring to sync your pc network so that the time is within a
>  second or so, please consider looking here for a server with a link
>  to pool.ntp.org.

	Speaking only for myself, I think that would be a good 
improvement to the documentation.

>  I would also think it would be a good idea to put the wording like
>  "Do no use any of these as default servers in software package or
>  hardware device without first contacting the server operator and
>  obtaining permission"

	Also agreed.

-- 
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 questions mailing list