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

[u***@jaloob.com]

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
0.012000

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

# ntpq -c rv
assID=0 status=c624 sync_alarm, sync_ntp, 2 events,
event_peer/strat_chg,
version="ntpd ***@1:4.2.0a+stable-8-r Fri Sep 9 16:44:48 UTC 2005
(1)"?,
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.pool.ntp.org/#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
server
# to 10; otherwise your clocks will drift apart if you lose
connectivity.
server 127.127.1.0
fudge 127.127.1.0 stratum 13

# By default, exchange time with everybody, but don't allow
configuration.
# 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 127.0.0.1 nomodify

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

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

# 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
#broadcastclient

[Richard B. Gilbert]

Post by u***@jaloob.com
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 :-)
# ntptrace
localhost.localdomain: stratum 16, offset -0.025048, synch distance
0.012000

Stratum 16 says you are not synchronized.

Post by u***@jaloob.com
# ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
*fortitude.route 82.96.64.2 2 u 56 64 377 10.235 -105.53
23.437

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.

Post by u***@jaloob.com
+fiordland.ubunt 193.79.237.14 2 u 60 64 377 11.248 -95.855
24.182

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.

Post by u***@jaloob.com
xclock-b.develoo 192.12.19.20 2 u 53 64 377 564.283 -348.56
47.912
LOCAL(0) LOCAL(0) 13 l 55 64 377 0.000 0.000
0.002

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>

[Ulrich Windl]

Post by u***@jaloob.com
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 :-)
# ntpq -c rv
assID=0 status=c624 sync_alarm, sync_ntp, 2 events,
event_peer/strat_chg,
(1)"?,
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,

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

[...]

Ulrich

[Charles Elliott]

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

CHE

Post by u***@jaloob.com
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 :-)
# ntptrace
localhost.localdomain: stratum 16, offset -0.025048, synch distance
0.012000
# ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
*fortitude.route 82.96.64.2 2 u 56 64 377 10.235 -105.53
23.437
+fiordland.ubunt 193.79.237.14 2 u 60 64 377 11.248 -95.855
24.182
xclock-b.develoo 192.12.19.20 2 u 53 64 377 564.283 -348.56
47.912
LOCAL(0) LOCAL(0) 13 l 55 64 377 0.000 0.000
0.002
# ntpq -c rv
assID=0 status=c624 sync_alarm, sync_ntp, 2 events,
event_peer/strat_chg,
(1)"?,
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.pool.ntp.org/#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
server
# to 10; otherwise your clocks will drift apart if you lose
connectivity.
server 127.127.1.0
fudge 127.127.1.0 stratum 13
# By default, exchange time with everybody, but don't allow
configuration.
# 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 127.0.0.1 nomodify
# Clients from this (example!) subnet have unlimited access,
# but only if cryptographically authenticated
#restrict 192.168.123.0 mask 255.255.255.0 notrust
# If you want to provide time to your local subnet, change the next
line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255
# 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
#broadcastclient

[u***@jaloob.com]

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!

[Maarten Wiltink]

<***@jaloob.com> wrote in message news:***@j8g2000cwa.googlegroups.com...
[...]

Post by u***@jaloob.com
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! :-)

Burst, or iburst?

Nobody minds iburst. Nobody needs burst[0].

Groetjes,
Maarten Wiltink

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

[Richard B. Gilbert]

Post by Maarten Wiltink
[...]

Post by u***@jaloob.com
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! :-)

Burst, or iburst?
Nobody minds iburst. Nobody needs burst[0].
Groetjes,
Maarten Wiltink
[0] Unless you do. But as a rule, nobody does.

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

[Maarten Wiltink]

"Richard B. Gilbert" <***@comcast.net> wrote in message news:RImdnWFw1a-u-***@comcast.com...
[...]

Post by Richard B. Gilbert
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!

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.

Post by Richard B. Gilbert
When in doubt, DON'T!!

Good advice.

Groetjes,
Maarten Wiltink