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

Barry Bouwsma ntp-200203 at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Tue Dec 21 01:02:59 UTC 2004


Serwoas!
Helmut Wollmersdorfer schrieb:

> Each of my two servers has 3 radio clock receivers (DCF77, HBG75, MSF60).

> Here is a typical result of ntpq -d one hour after restart and more 
> -192.168.0.10    ...  1 u  115  128  377    0.227   -3.985   0.140
> *SHM(0)          ...  0 l   91  128   77    0.000    1.035   0.495
> +SHM(1)          ...  0 l   20   64  373    0.000    0.739   2.203
> +SHM(2)          ...  0 l   87   64  376    0.000   -0.637   1.000
> -nav.metrologie. ... 14 u   24   64  377   15.396  -13.001   9.449
> xmbox.eunet.at   ...  2 u   22  128  377   12.494   43.665   5.553
> -orfroufh5.apa.n ...  2 u   16  128  377   14.235  -14.594   7.367

> What's the correct time?

See my headers, then add the propagation delay via NNTP to your
site!  But seriously, ...

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

I suspect your other server is 192.168... given its closeness, but
I'd hope to see other references that are not so far away as the
ca. 15msec to what appear to be austrian sites.  Further, the jitter
given by those nearby sites is pretty bad, suggesting you see a lot
of traffic on your link which is probably relatively slow to start
with anyway.

How do traceroutes look to your peers?  Can you find any that are
even closer to you, and which show up with both a low reach and
jitter value?

I'm at the moment on a Cabal Modem, with a mostly-inactive link,
and here's what I see from the next-hop upstream which happens to
be serving ntpd:
-PPS(2)          .PPS.            0 ?    1   16  377    0.000    1.478   1.780
+SHM(1)          .DCFa.           0 ?   45   64  217    0.000   -0.210   0.092
+Cabal-GW        62.2.22.61       3 u    6   64  377    7.711   -0.447   4.244

I'm not too concerned about precise times, but to get this with the
cheap DCF77 consumer clock I have, I'm using 30,3msec correction,
and I haven't tried any other references.  Good enough for me.

Once your server is stable (and it looks that it is, with your local
refclocks close to 0msec offset), you can poke at other servers and
see how far off they are from yours without needing to add them to
your list of ntpd peers, using `ntpdate -q', with results like:
server 129.132.2.21, stratum 1, offset -0.000338, delay 0.03511

I don't have a symmetrical line, but it's good enough to keep me
happy.  A traceroute to this peer shows that the return path is not
too far different from the path to it, as I'd expect from the actual
physical distance to it.

Try doing traceroutes to sites that you feel are close, and do `ntpq -p'
queries at the routers along the way -- often they'll be set up to
serve data that is more accurate for you than a more distant public
reference -- and if you find a short path without too much inconsistency
on the return times, poke the peers with `ntpdate -q' to see what your
apparent offset is.

And if you have a bandwidth-limited line, try to do this with as little
traffic on the line as you can manage, and if you have an asymmetrical
line (say, 10Mbit down/64kbit up), then you're not going to be able to
get as accurate a time from a remote peer as from another well-calibrated
local reference clock like GPS.

Also, poke your peers with `ntpq -p' as well to see to what they are
locked and how far off from their references they are.  The nearby
site that appeared to be 338usec away from my machine shows
+GENERIC(0)      .GPS.            0 l   15   64  377    0.000   -0.010   0.020
oPPS(0)          .PPS.            0 l   62   64  377    0.000    0.004   0.010
+ntp1.ptb.de     .PTB.            1 u   58   64  377   38.181    0.172   0.136

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.
Oh, check that, the EUnet machine is locked to the mahcine whose
peers I just quoted, but has a noticeable offset, and is not good
right now as a reference without a good grain of salt:
ntpq -p mbox.eunet.at.
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-chronos.cru.fr  .GPS.            1 u  502 1024  377   67.528   -7.560   2.029
+clock.isc.org   clepsydra.dec.c  2 u  509 1024  377  185.982  -20.805  20.025
 clock.llnl.gov  0.0.0.0         16 u    - 1024    0    0.000    0.000 4000.00
 ntp0-rz.rrze.un 0.0.0.0         16 u    - 1024    0    0.000    0.000 4000.00
-ntp0.NL.net     .GPS.            1 u 1011 1024  377   32.505  -18.427   0.146
-hora.cs.tu-berl .PPS.            1 u 1010 1024  377   26.625  -19.976   0.880
+ntp0-rz.rrze.un .GPS.            1 u  432 1024  377   25.590  -20.654   2.456
*swisstime.ee.et .PPS.            1 u  742 1024  377   15.854  -20.589   0.230
-ntp2.ien.it     .IEN.            1 u  502 1024  377   42.697  -10.139   8.710
-Time1.Stupi.SE  .PPS.            1 u 1006 1024  377   38.264  -18.806  10.303

Your ORF/APA peer shows up here as 10msec off.  Its `ntpq -p' output
looks better, but still not optimal:
+ns3.univie.ac.a Time2.Stupi.SE   2 - 1008 1024  377   82.470    4.263   7.580
+holem.belnet.be ntp1.belnet.be   2 -  731 1024  377  106.810    2.637   5.050
-ns4.univie.ac.a Time2.Stupi.SE   2 -  591 1024  377   54.780   18.757  19.150
*ntp1-rz.rrze.un .DCFp.           1 -  550 1024  377  120.900    5.127   7.230

You might want to poke Uni-Wien -- ns3 shows up here as 365usec offset,
although it gives me no billboard.  ns4, though, gave only a few dozen
usec offset and has a decent -- though not local refclock -- set of peers:
+ns2.univie.ac.a ntp2.ptb.de      2 u   69 1024  367    0.789    0.516   0.048
 ns3.univie.ac.a ns4.univie.ac.a  3 u  228 1024  377    0.462    0.202   0.025
 tunamea.tuwien. 0.0.0.0         16 u    - 1024    0    0.000    0.000 4000.00
-tunameb.tuwien. tunamea.tuwien.  2 u  596 1024  377    1.469    2.288   0.924
-uhura.kom.tuwie ntp1.ptb.de      2 u  453 1024  376    6.855   -3.163   1.065
+time.nist.gov   .ACTS.           1 u  588 1024  377  147.425    1.649   0.276
*Time2.Stupi.SE  .PPS.            1 u  577 1024  377   35.901    0.396   0.094


Of course, if you're not in eastern austria, you will want to see
what a more local university has to offer, in order to avoid any
round-trip asymmetry-induced delays, if it's topologically closer
to you seen by traceroute.


In summary, if you poke nearby sites with `ntpdate -q' and `ntpq -p',
armed with traceroute, you can get a feel for how good a peer you can
expect them to be.  In your case, EUnet is out, Uni-Wien is decent,
at least seen from here.

Try that -- or poke a closer university or ISP.  For example, if you
were to be in the west of austria, you could try ns.tele.net, which is
some 2msec off from my machine:
+tt126.ripe.net  .GPS.            1 u  504 1024  377    1.159   -2.705   0.013
+metasweb01.admi ntp-p1.obspm.fr  2 u  502 1024  377   13.977   -3.744   0.170
-swisstime.ee.et .PPS.            1 u  536 1024  377   17.311   -8.059   0.365
*tik.cesnet.cz   .GPS.            1 u  569 1024  377   21.506   -2.877   0.295

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.


The peers shown above are not meant to be used by sites not close to
Austria unless they're in a list of public servers to be used, but are
given as an example of how to look for a quality peer that's nearby
(net-wise).  The Uni-Wien  peering with PTB Braunschweig and Stupi.SE
show good values because the above sites have high-bandwidth fast paths,
which you, as an end-user, may not see on the unpleasant side of an
ADSL link.  The shorter a hop to your peers, the better, as they may
well have a much better path to a distant peer than your ISP can offer.
It should be okay to poke the peers once or twice to see how well they
are, without adding them to your list of ntp.conf peers.  Usual
disclaimer, blah blah.  I'd hope you can find a DCF/GPS peer close to
you as well, as not all the so-called references are worth much, as
you see above where stratum and quality do not track.  Hope this is
somehow helpful...


barry bouwsma




More information about the questions mailing list