ntptrace returns stratum 16, ntpq -p shows sync with stratum 2 server.

ntptrace returns stratum 16, ntpq -p shows sync with stratum 2 server.

Post by usene » Wed, 28 Jun 2006 01:10:33

I've googled for this problem and generally it seems to be caused by a
networking problem, although I can't see anything that would indicate
that. I'm running ubuntu , with only a couple of changes from the
default configuration... uncommenting the pool NTP server, and adding a
local ISP ntp server. I've been playing with this all afternoon, and
I've come against a dead end. I'll probably realise I've done something
stupid as soon as I send this off :-)

to start off:

# ntptrace
localhost.localdomain: stratum 16, offset -0.025048, synch distance

# ntpq -p
remote refid st t when poll reach delay offset
*fortitude.route 2 u 56 64 377 10.235 -105.53
+fiordland.ubunt 2 u 60 64 377 11.248 -95.855
xclock-b.develoo 2 u 53 64 377 564.283 -348.56
LOCAL(0) LOCAL(0) 13 l 55 64 377 0.000 0.000

# ntpq -c rv
assID=0 status=c624 sync_alarm, sync_ntp, 2 events,
version="ntpd 4.2.0a@1:4.2.0a+stable-8-r Fri Sep 9 16:44:48 UTC 2005
processor="i686", system="Linux/2.6.12-9-386", leap=11, stratum=16,
precision=-19, rootdelay=0.000, rootdispersion=13.275, peer=7780,
refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000,
poll=6, clock=0xc84a82b7.98087442, state=3, offset=-25.048,
frequency=0.000, noise=36.622, jitter=22.695, stability=0.000

and here's my ntp.conf

# /etc/ntp.conf, configuration for ntpd

# ntpd will use syslog() if logfile is not defined
#logfile /var/log/ntpd

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

# You do need to talk to an NTP server or two (or three).
server ntp.keme.net iburst #isp's ntp server
server ntp.ubuntulinux.org

# pool.ntp.org maps to more than 100 low-stratum NTP servers.
# Your server will pick a different set every time it starts up.
# *** Please consider joining the pool! ***
# *** < http://www.yqcomputer.com/ #join> ***
server pool.ntp.org

# ... and use the local system clock as a reference if all else fails
# NOTE: in a local network, set the local stratum of *one* stable
# to 10; otherwise your clocks will drift apart if you lose
fudge stratum 13

# By default, exchange time with everybody, but don't allow
# See /usr/share/doc/ntp-doc/html/accopt.html for details.
restrict default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict nomodify

# Clients from this (example!) subnet have unlimited access,
# but only if cryptographically authenticated
#restrict mask notrust

# If you want to provide time to your local subnet, change the next
# (Again, the address is an example only.)

# If you want to listen to time broadcasts on your local subnet,
# de-comment the next lines. Please do this only if you trust everybody
# on the network!
#disable auth

ntptrace returns stratum 16, ntpq -p shows sync with stratum 2 server.

Post by Richard B. » Wed, 28 Jun 2006 05:27:42


Stratum 16 says you are not synchronized.
The "*" beginning the above line says that fortitude.route.??? has been
selected as the synchronization source. The offset of -105.53
milliseconds says that you are not yet close to being synchronized.

The above line says that fiolrdland.ubunt??? is a member of the
selection set. The offset of -95.855 milliseconds is more or less in
agreement with fortitude.route.??? So say that your local clock is
about 100 milliseconds off.

How long has this been running? Did you start ntpd with the -g option?
That would tell it to set the clock on startup. The maximum rate at
which ntpd can slew the clock is 500 PPM or 0.5 milliseconds per second.
At that rate, a 100 millisecond offset will be corrected in about 200
seconds. Ntpd will probably overshoot and correct the other way,
overshoot again and correct. Eventually, it will pull in to something
resembling tight synchronization. If you are cold starting ntpd, it can
take quite a while to tweak all the knobs to their proper settings.

clock-b.develoo.??? I assume is the server assigned by the pool. It is
a poor choice for your location. Note the delay of 564.283
milliseconds! The offset is ridiculous and the jitter is high! It's
not the server, it's the network between your site and clock-b. The "x"
at the beginning of the line says that ntpd has pronounced this server
"insane"! Again, it's the network not the server.

You can ask for a pool server by region; e.g. US, Europe, etc. An
appropriate choice of region should get you a server better suited to
your location. I don't use pool servers myself and can't tell you
exactly how so you'll need to see the documentation to find the
available regions and the correct syntax. In selecting non-pool
servers, look for servers close to you in network space. Such servers
will necessarily be close to you physically (0-300 miles) but the
converse is not necessarily true.

You should use the "iburst" keyword in all of your server statements for
faster startup. Iburst gets you the necessary information to start
synchronizing your clock in something like 20 seconds versus a little
more than five minutes without.

Finally, you have either too many or too few servers. With three
configured and one declared insane you wind up with two, the worst
possible configuration. With one server ntpd will synchronize with it,
right or wrong. With two, ntpd has no way to tell which one is more
nearly correct or if both are hopelessly wrong. Three servers
degenerate too easily to the two server case. With four well chosen
servers, your system should be a lot happier.

<big snip>


ntptrace returns stratum 16, ntpq -p shows sync with stratum 2 server.

Post by Ulrich Win » Wed, 28 Jun 2006 20:03:09


"state=3" (I might be wrong) means that the client has detected a frequency
spike and is further monitoring time samples before it does any
adjustments. Usually you should see "state=4".



ntptrace returns stratum 16, ntpq -p shows sync with stratum 2 server.

Post by Charles El » Thu, 29 Jun 2006 10:23:38

t may be a mistake to use the pool servers; I never had worse time
resolution until I tried them.

I modified a program that I found on the Internet : "NTPClient is a C# class
designed to connect to time servers on the Internet.
/// The implementation of the protocol is based on the RFC 2030."

and rewrote it in Java to read the time from many stratum 1 and 2 servers
for several days at 60 second intervals in round-robin fashion and then
picked the servers that consistently had the lowest delay times and the
highest precision. This is much better than the pool servers becasue with
them you cannot control either precision or delay time.

< XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


ntptrace returns stratum 16, ntpq -p shows sync with stratum 2 server.

Post by usene » Fri, 07 Jul 2006 19:08:28

Thanks for all of the responses

Just a followup on the situation (I always feel that not enough people
say exactly what happened in the end on usenet posts like these)

I think it was just down to having too few servers, and NTP not being
confident about which ones to synchronise with. I didn't actually
change the setup as it was at the end of the day. I came back about 18
hours later, and everything was running fine.

as for the burst option... I only used burst with the ISPs ntp server,
because we're paying them. I didn't want to do a DLink! :-)

When I have another look at the ntp configuration, I'll pick out 4 or
so good servers which are nearby on the network, and to avoid the pool.

Thanks all!

ntptrace returns stratum 16, ntpq -p shows sync with stratum 2 server.

Post by Maarten Wi » Fri, 07 Jul 2006 21:32:54


Burst, or iburst?

Nobody minds iburst. Nobody needs burst[0].

Maarten Wiltink

[0] Unless you do. But as a rule, nobody does.

ntptrace returns stratum 16, ntpq -p shows sync with stratum 2 server.

Post by Richard B. » Sat, 08 Jul 2006 04:36:19

I believe that burst is a special purpose hack with a few, very few,
legitimate uses. Unfortunately, the documentation fails to explain
under what circumstances it might be legitimately used!

When in doubt, DON'T!!

ntptrace returns stratum 16, ntpq -p shows sync with stratum 2 server.

Post by Maarten Wi » Sat, 08 Jul 2006 05:23:57


One set of circumstances was mentioned here once. It's possible for
ARP cache entries to sometimes expire between polls of a server on
the local network. In that case, some polls will and others will not
incur a delay while the MAC address is retrieved, increasing jitter.
Burst can alleviate that.

This is not a problem for most people.

Good advice.

Maarten Wiltink