[ntp:questions] Re: Which public servers for adjustment?

Barry Bouwsma ntp-200203 at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Thu Dec 23 22:38:41 UTC 2004


> > Hmmm, what sort of network connection do you have?  And how loaded

> Broadband Cable, 512 Kbit up, 1024 down. Its not overloaded. Large 

That's better (in theory) than the bandwidth available to me, I think.
I see non-stop arp traffic at all times, with about 80kbit/sec devoted
to that, with the result that my first hop upstream (a 10.xxx address,
which I don't know if it refers to the Cabal Modem itself or something
elsewhere, which would then see much more traffic than just the isolated
arp broadcasts that make it to my interface, shows how little I know)
has ping times like 7.139/9.252/15.900/2.038 ms.  Not really fair, as
this machine isn't idle, with a good deal of disk activity with a CMD
640 <spit> controller, for those who know of hardware dinosaurs, and
this network interface connected with USB1.  And a switch in the way.
I forget how times looked with a directly-connected ISA network card.
I could probably even dig out a PCI card too, if I cared to get times
down a millisecond further.

Meaning that, while I see fairly consistent results from everything I
poke at compared with my cheap DCF77 reference, neither you nor I will
be able to say for certain that our clocks are showing the correct time
without a local calibrated reference, although the variance I see from
the DCF77 signals is roughly what I expect the absolute offset with this
type of connection to give me.  A millisecond here, a millisecond there,
pretty soon we're talking about real time.


> number of hops in the network of my provider. In Vienna traffic is 
> exchanged centrally at VIX www.vix.at, where most providers and large 
> organisations house their routers. Alternative international or overseas 
> routes may exist. I have 7 hops to VIX with ping
> rtt min/avg/max/mdev = 6.993/10.688/19.057/3.441 ms

I'm lucky that the ISP I'm using at the moment has fast direct connections
to a number of remote exchanges, as noted by a project I mention below.
Not that it makes you feel any better, but in spite of your 7 hops, your
paths shouldn't be that bad.  Unless your ISP is running its backbone at
98% of capacity.  Anyway, with my little experience of internet over
broadband cable, what you are seeing sounds pretty typical.

As far as the effect of traffic on ntpd offsets, I can refer back to the
times when I was first calibrating my radio clock references against
peers over dial-up at 28k, where the offset between an idle line (where
I calibrated things) and normal up/download activity, with roughly
identical traffic in both directions maxing out the link, would make
the remote references appear to be some 2 or 3 seconds off.  Or more.

Anyway, it would be of interest to me to see how far off a local calibrated
reference would appear compared to nearby networked server references,
and how traffic on typical DSL/Cabal connections affects the offset...
MTU sizes may also affect things at these speeds, depending on the
accuracy you're looking for.


> Thanks your hints I found some additional servers at universities.
> Around 10msec will be the best what I can get.

Don't forget to poke at all the routers along the way.  Sometimes, though
not as often as in the past, you'll find accurate servers that way.


> > For what it's worth, I can't get an `ntpq' report from your EUnet
> > peer, but from here, it claims to be 20msec off from my machine.

> Copied from my old confs. They had good quality, but financial problems, 
> good staff left.

*google google*  Hmm, so I see.  I should probably think about sending
out some Weihnachtskarten for last year, or three years ago, Real
Soon Now...

Anyway, the lesson to be learned from that machine is that one
cannot assume that a stratum gives any indication of the quality
of data being served, and that one can use the same tools that one
uses on the local server to poke remote servers for their health.
This should be the first thing one looks at when a peer starts to
look strange.


> > For example, if you
> > were to be in the west of austria, you could try ns.tele.net, 

> They are at VIX too, but with a bottleneck at hop 10, pingtime ~25ms 
> which is nearly the same as to their timeserver.

I suspect that hop ten is the hop from Wien to Vorarlberg.  Based
on my traceroutes from here, those machines are likely located
just outside of Bregenz.  My RTTs from them are just 4msec more
than those from my first-hop router.  At the time I first replied,
it was not clear to me that you were in or near Wien, or elsewhere.


> > This shows two GPS peers of interest, both of which show here as well
> > under 1msec off -- CESnet and tt126.RIPE.  Check your paths to them --
> > you may have a fast direct path via Wien to Praha and CESnet.

> tt126.ripe is directly connected to tele.net with hop distance of 12, 
> thus ~25ms.

And here is my Real Reason for following up to this post, rather
than just letting the matter die.  I was intrigued by a hostname
like ``tt126'' and a single GPS reference, and wondered to myself,
could ``tt'' mean something like timeticker, and why would a RIPE
machine be around the Rheintal?

With a bit of searching, I found the following as part of an
explanation of what these machines -- Test Traffic Measurement
boxen -- are for:

   I need a NTP time server. Where can I find one?
   Install a NTP server on your local network or look at www.ntp.org for
   a public NTP time server in the geographical proximity.
   
   If you are interested in installing a NTP server, then it might be of
   interest knowing that the Test Traffic Measurements service's probes,
   the "Test-Boxes", have a GPS clock and can therefore be used as
   stratum-0 NTP servers. For more information, go to 
   www.ripe.net/test-traffic .
   
   Please do NOT use RRCs as NTP servers, they were not intended for this
   purpose.

(RRCs -- Remote Route Collectors -- and TTMs are different, with the
latter having the GPS clock, if you haven't figured it out.)

Interesting.  I didn't find a list of all the geographical locations
of the machines out there, but a few random traceroutes confirmed
their scatteredness.  I don't know how open these machines are for
outsiders to use, which is why I don't want to publicize them too
much, but...

In your case, you would be well served by being able to access such
machines at VIX or nearby, like to CESnet.  So I thought, why not find
where these machines are?  And so, I did traceroutes.

Not all machines are reachable to the outside world.  For example,
TDC Danmark hides tt16 at Slet where I cannot reach it via traceroute,
`ntpq -p' or `ntpdate -q'.  A fair number of machines do not exist at
present.  tt116 and tt83 are not likely to be reached by anyone other
than the people directly attached to their networks, hmmm.

It would probably be useful for me to summarize the various TTM boxen
by country, city, and network, based on my traceroutes, but I'm not
sure how kosher that would be, because I don't want anyone to start
pounding them all.  One or two `ntpdate' queries should be okay, I
would hope, but adding them to peer lists of ntpd might be pushing
things too far, to cause more of them to become hidden.

Anyway, for you, there's one of these boxes at ACOnet:
$ ntpdate -q tt73.ripe.net.
server 193.171.23.106, stratum 1, offset -0.001436, delay 0.06430
`ntpq -p' shows it as being 6usec off from its GPS reference.

I hope you have a direct hop from Wien to Bratislava/Pressburg,
where tt22 is located, also known as ntp.bts.sk, so it may well be
intended as a not-so-private ntp reference.

A little bit further, but hopefully via a direct path from Wien,
is Hungary, where tt118 can be found.  This one takes a roundabout
path from here, showing as 8msec off from my machine, probably due
to an asymmetrical return, if not loaded lines, with the austrian
hop RTT being twice that of a path to most destinations in Wien.

I have a hard time guessing where tt108 is -- the Czech Republic?
There are a few sites in der Schweiz, if you see a fast path from
your provider to switch.ch, as well as in Frankfurt/Main, although
these are probably further removed than you would like, and by then
we're already in the lands of better-maintained public timeservers.

The good thing to note from this is that in pretty much every
european country, you can find a GPS-based ntp server that can be
used for testing your offset, if you have doubts about other ntp
servers you may be using.

And as noted, unless I hear from RIPE or someone that these servers
can be used for more than private use, you should not use them for
more than a one-off `ntpdate' test.  Some of them are already hidden
from public prying, so the fact that others are reachable should not
be taken to mean they are open for the public to abuse.


the usual disclaimer, as I don't know what I'm doing
bouwsma barry




More information about the questions mailing list