[ntp:questions] Synchronisation lost with swisstime.ethz.ch
brad at stop.mail-abuse.org
Thu Aug 11 14:18:10 UTC 2005
At 2:08 AM -0700 2005-08-11, frank.olsen at steria.com wrote:
> The configuration is bascially on of the servers (all running HP-UX
> 11.00), that synhronise to an external server (swisstime.ethz.ch). This
> server does a broadcast on the local subnet. In addition each of the
> other servers also do broadcasts and have each other defined as peers.
Checking the server swisstime.ethz.ch, it appears to be running
as a Stratum 1 right now, and connected to a couple of Stratum 0
refclocks. But you would need to monitor this server over an
extended period of time to make sure that it's not occasionally going
> Up until this month we never had steps of more than around +/- 0.2
> We do have regular connection problems on the external network.
That is a serious problem for NTP.
> In trying to debug this problem I've been using ntpdate. I've also
> temporarily desactivated the "external" synchronisation (by commenting
> out server 22.214.171.124 in ntp.conf and restarting xntpd). Currently,
> ntpdate -d gives:
I recommend using ntpq instead of ntpdate. The command "ntpq -p"
for the server swisstime.ethz.ch currently shows this:
remote refid st t when poll reach delay offset jitter
LOCAL(0) LOCAL(0) 12 l 59 64 377 0.000 0.000 0.004
+GENERIC(0) .GPS. 0 l 39 64 377 0.000 0.014 0.013
oPPS(0) .PPS. 0 l 30 64 377 0.000 0.012 0.031
xntp1.ptb.de .PTB. 1 u 43 64 337 33.205 2.495 1.919
This tells you that it has currently selected the PPS(0) Stratum
0 driver as the syspeer, with the GENERIC(0) Stratum 0 driver that
also made it to the final candidate stage. However, I would be a bit
concerned about this machine, because it doesn't have enough other
peers to detect and eliminate falsetickers. They should either have
just one refclock which is always assumed to be correct, or enough
refclocks/servers/peers defined (i.e., at least four and preferably
at least five) so that they can detect and eliminate falsetickers.
Running with just three is kind of dangerous for a machine that is
supposed to be a well-known Stratum 1 timeserver.
The command "ntpq -c rv" for the server swisstime.ethz.ch
currently shows this:
assID=0 status=21f4 leap_none, sync_atomic/PPS, 15 events,
version="ntpd 4.2.0a at 1.1320-o Mon Feb 7 12:39:52 UTC 2005 (1)",
processor="i586", system="Linux/2.4.20-NANO", leap=00, stratum=1,
precision=-18, rootdelay=0.000, rootdispersion=2.547, peer=47270,
refid=PPS, reftime=c6a5da28.48b1ee24 Thu, Aug 11 2005 7:07:36.283,
poll=6, clock=c6a5da52.772f9873 Thu, Aug 11 2005 7:08:18.465, state=4,
offset=0.012, frequency=17.695, jitter=0.031, noise=0.005,
This also shows that they are sync'ed to the PPS interface, that
they are currently in the final "stable" state, their offset is low,
etc.... I wonder a bit about that root dispersion though -- that
seems a bit high for a Stratum 1 server.
> Can it be that the "stratum=13" appears whenever I loose the connection
> completely to 126.96.36.199? As the syslog showed, the server is
> normally stratum=1, but sometimes it jumps to stratus=13.
That could be the problem.
In your case, one thing I'd recommend using more than just the
one upstream time server. The page at
should provide some assistance in this area. If you want further
help from us, you'd need to post the ntp.conf files from your local
NTP server (the one currently configured to use swisstime.ethz.ch),
as well as your local NTP clients.
Brad Knowles, <brad at stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
More information about the questions