Re: Trace ntp sanity checks?

Hello Martin,

i already recorded the output you asked me for some days ago:

ntpq -p
remote refid st t when poll reach delay offset
jitter
==========================================================================*LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000
0.004
master1 10.212.70.11 4 - 32 64 377 0.447 547212. 69.790
master2 10.212.70.12 4 - 3 64 377 0.306 547235. 73.665

(the high offset is because the ntp-client lost synchronization a long
time ago)


ntpq> rv 8773
assID‡73 status14 reach, 1 event, event_reach,
srcadr=master1, srcport3, dstadr=0.0.0.0,
dstport3, leap\0, stratum=4, precision=0, rootdelay=0.000,
rootdispersion=0.000, refid.248.128.74, reach77, unreach=0,
hmode=8, pmode=5, hpoll=6, ppoll=6, flash\0 ok, keyid=0, ttl
=0,
offsetT9217.462, delay=0.447, dispersion™7.039, jitterX.874,
reftimeÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
orgÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
recÊf7bfcb.44055fbb Wed, Nov 28 2007 11:22:03.265,
xmtÊe54d0b.8746ed24 Wed, Nov 14 2007 11:31:39.528,
filtdelay= 0.45 0.45 0.45 0.45 0.45 0.45 0.45
0.45,
filtoffset= 549217. 549210. 549199. 549186. 549169. 549153. 549132.
549121.,
filtdisp= 1000.48 1000.96 1001.44 1001.92 1002.40 1002.88 1003.36
1003.84


i already tried to interpret this, but the only thing i figured out is
that the zero in 1014 means that the client is rejected because of
failed sanity checks.

many clients showing the problem are running ntp-version 4.2.0a@1.1196-r
on linux.
i once heard that the server is a Tardis product for windows - but i
cannot supply details about that.

the ntp-server and the network are not managed by myself.
because of that i would like to have enough knowledge of ntp to analyze
such problems on the client side (as far as possible).
i had these problems quite frequently, sometimes often, sometimes not at
all...

is there a way to trace down which sanity-check failed?


thanks a lot
Frank


-----Original Message-----
From: DE/SYS Routing - Linux, Team

Sent: Wednesday, December 05, 2007 11:50 AM
To: D1/OBT-ho Hornung, Frank; D1/OBT-ha Harle, Christoph
Subject: FW: Trace ntp sanity checks?


-------------------------------------------
From: questions-bounces+linux=stihl.de@lists.ntp.org on behalf of Martin
Burnicki[SMTP:MARTIN.BURNICKI@MEINBERG.DE]
Sent: Wednesday, December 05, 2007 11:32:04 AM
To: [email]questions@lists.ntp.org[/email]
Subject: Re: Trace ntp sanity checks?
Auto forwarded by a Rule

Frank,

[email]linux@stihl.de[/email] wrote:[color=blue]
> Hello,
>[/color]
[color=blue]
> we are having problems to synchronize linux & aix ntp-clients to a
> ntp-broadcastserver.
>[/color]
[color=blue]
> ntp-broadcast-packets are received by the clients, but all servers are
> rejected by the clients after a few minutes.
>[/color]
[color=blue]
> we found out, that the ntp-servers do not pass the sanity-checks on[/color]
the[color=blue]
> clients and get probably rejected because of that.
>[/color]
[color=blue]
> How can we further track down which of the sanity-checks fails and[/color]
why...

If the NTP on the client has been compiled with debug option then you
can
run ntpd with the -d option ans see what it prints on the console.

Otherwise, if the broadcast server is listed in the output of "ntpq -p"
you
can see details of the server association using the following commands.

Print billboard of the associations:

# ntpq -p
remote refid st t when poll reach delay offset
jitter
=====================================================================*gateway.py.mein .GPSi. 1 u 34 64 377 0.148 -0.011
0.362

Find out the association IDs:

# ntpq -c as

ind assID status conf reach auth condition last_event cnt
========================================================1 41266 9614 yes yes none sys.peer reachable 1

In this case the association ID is 41266. Use the ID to find more
details on
the association:

# ntpq -c "rv 41266"
assIDA266 status–14 reach, conf, sel_sys.peer, 1 event, event_reach,
srcadr=gateway.py.meinberg.de, srcport3, dstadr2.16.3.27,
dstport3, leap\0, stratum=1, precision=-18, rootdelay=0.000,
rootdisp=0.580, refid=GPSi, reach77, unreach=0, hmode=3, pmode
=4,
hpoll=6, ppoll=6, flash\0 ok, keyid=0, ttl=0, offset=-0.659,
delay=0.163, dispersion=2.055, jitter=0.307,
reftimeË00fb6b.000192a7 Wed, Dec 5 2007 11:26:51.000,
orgË00fb71.b05ff1d8 Wed, Dec 5 2007 11:26:57.688,
recË00fb71.b0814599 Wed, Dec 5 2007 11:26:57.689,
xmt\0000000.00000000 Thu, Feb 7 2036 7:28:16.000,
filtdelay= 0.18 0.19 0.16 0.23 0.20 0.23 0.19
0.21,
filtoffset= -0.42 -0.61 -0.66 -0.76 -0.88 -1.04 -1.14
-1.06,
filtdisp= 0.01 1.00 1.97 2.96 3.92 4.90 5.86
6.85

You should not interpret the output above. It's just a quick test to
show
how to proceed.


If you post your output of the ntpq -p and ntpq -c "rv ..." commands
here
then we may be able to help.

And, the versions of NTP on the server and on the clients might be
interesting ...

Martin
--

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

_______________________________________________
questions mailing list
[email]questions@lists.ntp.org[/email]
[url]https://lists.ntp.org/mailman/listinfo/questions[/url]

___________________________________________________________________

This E-Mail is confidential. If you are not the intended recipient, you must
not copy, disclose or use its contents. If you have received it in error,
please inform us immediately by return E-Mail and delete the document.


Diese E-Mail ist vertraulich. Wenn Sie nicht der rechtmäßige Empfänge
r sind,
dürfen Sie den Inhalt weder kopieren, verbreiten noch benutzen. Sollten S
ie
diese E-Mail versehentlich erhalten haben, senden Sie sie bitte an uns
zurück und löschen sie anschließend.


Cet e-mail est confidentiel. Si vous n'etes pas le destinataire de ce
message, vous ne devez pas copier, divulguer ou utiliser le contenu. Si vous
avez recu cet e-mail par erreur, veuillez nous informer en retournant ce
message a l'expediteur et detruisez-le.


Esta mensagem, e qualquer de seus anexos, eh confidencial e privilegiada.
Caso voce nao seja o destinatario, nao esta autorizado a reproduzir ou
divulgar a terceiros o conteudo desta mensagem e de qualquer anexo da mesma
e deve apagar com os seus respectivos anexos.

___________________________________________________________________

ANDREAS STIHL AG & Co. KG
Kommanditgesellschaft mit Sitz in Waiblingen, HRA 260269, Amtsgericht Stutt
gart

Persönlich haftende Gesellschafter: Hans Peter Stihl und STIHL Aktiengese
llschaft
mit Sitz in Waiblingen, HRB 263722, Amtsgericht Stuttgart
Vorstand der STIHL AG: Dr. Bertram Kandziora (Vorstandsvorsitzender),

Dr. Peter Dürolf, Jürgen Steinhauser, Wolfgang Zahn
Vorsitzender des Aufsichtsrats der STIHL AG: Hans Peter Stihl

>>> In article <154E3348CEF56F4188CA1F05332CED20FA50AC@de00srvmes011r1.emea.dir>, [email]linux@stihl.de[/email] writes:

linux> ntpq -p

remote refid st t when poll reach delay offset jitter
==========================================================================
*LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000 0.004
master1 10.212.70.11 4 - 32 64 377 0.447 547212. 69.790
master2 10.212.70.12 4 - 3 64 377 0.306 547235. 73.665

You are sync'd to your local machine, and your 2 "master" machines are now
far enough out that your local ntpd will not talk to them.

You have been thru:

[url]http://support.ntp.org/bin/view/Support/DesigningYourNTPNetwork[/url]

and

[url]http://support.ntp.org/bin/view/Support/ConfiguringNTP[/url]

right?

H
--
[url]http://ntpforum.isc.org[/url] - be a member!

In article <154E3348CEF56F4188CA1F05332CED20FA50AC@de00srvmes011r1.emea.dir>,
[email]linux@stihl.de[/email] wrote:
[color=blue]
> *LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000
> 0.004[/color]

One would normally not serve time from a machine synchronised by
broadcasts. Defining a local clock driver serves no useful purpose
on a pure client (and should only be done with full understanding on
a server). Too many packaging of ntpd configure a local clock driver
in their sample configuration.

Problems arise if the local clock is seen as the best available time source,
locally, or downstream. Both locally and downstream, the clock failure
will never be detected.

The software clock will retain is last known phase and frequency corrections,
even if ntpd fails to get valid replies. Local clock is only used if it
is important that downstream clients see the same, free running, time, rather
than slowly diverge from each other.
[color=blue]
> master1 10.212.70.11 4 - 32 64 377 0.447 547212. 69.790[/color]

Note that you are halfway to the drop dead error. If ntpd accepts an
offset less than twice this, it will commit suicide.

Too many packaging of ntpd configure a local clock driver[color=blue]
>in their sample configuration.[/color]

Does anybody know why that got started?

What urban legend do we have to stomp out before that practice will go away?


--
These are my opinions, not necessarily my employer's. I hate spam.

Hal Murray wrote:[color=blue]
> Too many packaging of ntpd configure a local clock driver
>[color=green]
>>in their sample configuration.[/color]
>
>
> Does anybody know why that got started?
>
> What urban legend do we have to stomp out before that practice will go away?
>
>[/color]

It's no worse than the people who just want to "synchronize clocks to
each other" without regard to what time it is. The local clock driver
is harmless as long as people configure it to stratum 10!

On 2007-12-07, Hal Murray wrote:
[color=blue]
>ATTRIBUTION DELETED wrote:
>[color=green]
>>Too many packaging of ntpd configure a local clock driver in their
>>sample configuration.[/color]
>
> Does anybody know why that got started?[/color]

The sample configuration files attempt to include as many configuration
options as possible. Unfortunately there is often insufficient, or just
plain misleading, explanation of what these options should be used for.
[color=blue]
> What urban legend do we have to stomp out before that practice will go
> away?[/color]

The problem is that the distribution does not contain good sample
configuration files. There should be sample configurations for:

Pool client
Leaf node
unicast
broadcast
multicast
manycast
LAN server
unicast
broadcast
multicast
manycast
and so on.

--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]

In article <4758C2A7.9080307@comcast.net>,
Richard B. Gilbert <rgilbert88@comcast.net> wrote:
[color=blue]
> The local clock driver
> is harmless as long as people configure it to stratum 10![/color]

This very thread demonstrates a case where it wasn't harmless!

What has happened here appears to be that it has provided a much more
attractive indication of the time than proper time sources. I'm not
exactly sure why that is in this case, but, in other cases people have
had more local clock derived sources than real sources, and, because
the reference implementation claims zero root delay and zero root
dispersion (because it assumes that the local clock is being disciplined
by some other means, rather than free running), an upstream local clock can
have a very low apparent error band, so it can be quite difficult for other
sources to fall within the same cluster.

The other basic problem is that downstream nodes don't receive any indication
that they are disconnected from real time, whereas an alarm condition
would be signalled by a server without a local clock driver.

Note that using stratum 10 doesn't prevent these problems, it simply
stops nodes that more than about 2 hops downstream from having problems
from that particular local clock driver; it limits the area subject to
harm.

As to the urban myth. Whilst a lot of it is simply copy and paste
programming, I think there is a significant myth that, without the local
clock driver, the software clock will revert to its natural frequency,
when it loses all time sources.