ntp server 'rejected'

[d***@bem.fki-et.com]

Hi,
I have a GPS based ntp server, and I am trying to sync a QNX based box
to it. I have good reachability:
# ntpq -p
remote refid st t when poll reach delay offset
jitter
======================================================
192.168.0.230 .GPS. 1 u 60 64 377 0.951 -105.64
4.979
172.16.151.4 .GPS. 1 u 52 64 377 0.953 -106.24
5.051

but the QNX box does not sync. The clock on the QNX box has about 80
ppm drift, as observed over a few days.
the Associations billboard :
# ntpq -c as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 7 9014 yes yes none reject reachable 1
2 8 9014 yes yes none reject reachable 1

So i can get to the server but it is being rejected. What does this
mean?
I have read all the documentation I can find, but I can figure it out.
The rv command does not show anything obvious (to me)
# ntpq
ntpq> rv 7
status=9014 reach, conf, 1 event, event_reach,
ntpq> srcadr=192.168.0.230, srcport=123, dstadr=192.168.0.7,
dstport=123,
leap=00, stratum=1, precision=-20, rootdelay=0.000,
rootdispersion=996.826, refid=GPS, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=6, ppoll=6, flash=00 ok, keyid=0, offset=-130.583,
delay=0.953, dispersion=1.411, jitter=4.886,
reftime=c7e8cdb9.b6cbfb15 Thu, Apr 13 2006 13:16:41.714,
org=c7e8cdc9.c74b2fa9 Thu, Apr 13 2006 13:16:57.778,
rec=c7e8cdc9.e8d846cf Thu, Apr 13 2006 13:16:57.909,
xmt=c7e8cdc9.e896bd9c Thu, Apr 13 2006 13:16:57.908,
filtdelay= 0.95 0.95 0.95 0.95 0.95 0.95 0.95
0.96,
filtoffset= -130.58 -125.70 -120.64 -115.66 -110.54 -105.64 -100.66
-95.69,
filtdisp= 0.49 1.43 2.41 3.37 4.36 5.30 6.26
7.22

Help please, I have been staring at this for a week!

thanks

Dave

[Richard B. Gilbert]

Post by d***@bem.fki-et.com
Hi,
I have a GPS based ntp server, and I am trying to sync a QNX based box
# ntpq -p
remote refid st t when poll reach delay offset
jitter
======================================================
192.168.0.230 .GPS. 1 u 60 64 377 0.951 -105.64
4.979
172.16.151.4 .GPS. 1 u 52 64 377 0.953 -106.24
5.051

Something seems very wrong with the above! Why do you have a 106
millisecond offset? It also appears that this box has not selected
either of the available servers as a synchronization source!!

Post by d***@bem.fki-et.com
but the QNX box does not sync. The clock on the QNX box has about 80
ppm drift, as observed over a few days.
# ntpq -c as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 7 9014 yes yes none reject reachable 1
2 8 9014 yes yes none reject reachable 1
So i can get to the server but it is being rejected. What does this
mean?

It means that the server you are trying to synchronize with is not,
itself, synchronized and therefore is not eligible to serve time!!

<big snip>

[Ronan Flood]

Post by d***@bem.fki-et.com
# ntpq -c as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 7 9014 yes yes none reject reachable 1
2 8 9014 yes yes none reject reachable 1
So i can get to the server but it is being rejected. What does this
mean?
I have read all the documentation I can find, but I can figure it out.
The rv command does not show anything obvious (to me)
# ntpq
ntpq> rv 7
status=9014 reach, conf, 1 event, event_reach,
ntpq> srcadr=192.168.0.230, srcport=123, dstadr=192.168.0.7,
dstport=123,
leap=00, stratum=1, precision=-20, rootdelay=0.000,
rootdispersion=996.826, refid=GPS, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=6, ppoll=6, flash=00 ok, keyid=0, offset=-130.583,

Hmm, the rootdispersion looks suspect; but then I'd expect that to
light one of the flash bits. Can you look at the servers with ntpq?
See maybe what "cl" and "rv" show on them?

[d***@bem.fki-et.com]

Post by Richard B. Gilbert

Post by d***@bem.fki-et.com
jitter
======================================================
192.168.0.230 .GPS. 1 u 60 64 377 0.951 -105.64
4.979
172.16.151.4 .GPS. 1 u 52 64 377 0.953 -106.24
5.051

Something seems very wrong with the above! Why do you have a 106
millisecond offset? It also appears that this box has not selected
either of the available servers as a synchronization source!!

I have assumed the 106 ms offset comes from the clock drifting due to
it not being sync'd by ntp? I brute force set the clock with an ntpdate
before i started the ntpd, but from then it drifts...
It not selecting a server to sync is the probelm I think, but Im afraid
I have no idea why?

Post by Richard B. Gilbert

Post by d***@bem.fki-et.com
but the QNX box does not sync. The clock on the QNX box has about 80
ppm drift, as observed over a few days.
# ntpq -c as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 7 9014 yes yes none reject reachable 1
2 8 9014 yes yes none reject reachable 1
So i can get to the server but it is being rejected. What does this
mean?

It means that the server you are trying to synchronize with is not,
itself, synchronized and therefore is not eligible to serve time!!

The servers diagnostics indicate it is happy, and I can sync a linux
(Fedora core 4) box to it ok.

Post by Richard B. Gilbert
Hmm, the rootdispersion looks suspect; but then I'd expect that to
light one of the flash bits. Can you look at the servers with ntpq?
See maybe what "cl" and "rv" show on them?

Ok, I set the host to the clockbox:

ntpq> host 192.168.0.230
current host set to 192.168.0.230, I have a xover connection to one
port on this server, so 192. is not as bad as it seems.

ntpq> cl
status=0101 clk_noreply, last_clk_noreply,
ntpq> device="SHM/Shared memory interface", timecode=, poll=17039,
noreply=3671, badformat=0, baddata=0, fudgetime1=0.000, stratum=0,
refid=GPS, flags=0

there seem to be a lot of no replys?

ntpq> rv
status=09f4 leap_none, sync_telephone, 15 events, event_peer/strat_chg,
ntpq> version="ntpd ***@1.1161-r Mon Oct 25 15:22:31 BST 2004 (14)",
processor="i686", system="Linux/2.4.20-8", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdispersion=996.710, peer=21093,
refid=GPS, reftime=c7e9cb1a.66643cc0 Fri, Apr 14 2006 7:17:46.399,
poll=4, clock=c7e9cb25.2c766c6d Fri, Apr 14 2006 7:17:57.173,
state=4,
offset=-0.001, frequency=-4.862, jitter=0.006, stability=0.000

I can see nothing suspicious here, apart from sync_telephone possibly?

Thanks for the help, this is an area I have not been in before.

Dave

[Ronan Flood]

Post by d***@bem.fki-et.com
The servers diagnostics indicate it is happy, and I can sync a linux
(Fedora core 4) box to it ok.

Interesting, perhaps a client version difference: what does "ntpq -crv"
show on your QNX box and your Linux box?

I gather your stratum-1 has two interfaces; have you tried the QNX
client with only one of the server's addresses configured?

Post by d***@bem.fki-et.com

Post by Ronan Flood
Hmm, the rootdispersion looks suspect; but then I'd expect that to
light one of the flash bits.

Forget the flash bit, that'd only light if rootdispersion was > 16000
(16 seconds) I think, on further investigation.

Post by d***@bem.fki-et.com
ntpq> host 192.168.0.230
current host set to 192.168.0.230, I have a xover connection to one
port on this server, so 192. is not as bad as it seems.
ntpq> cl
status=0101 clk_noreply, last_clk_noreply,
ntpq> device="SHM/Shared memory interface", timecode=, poll=17039,
noreply=3671, badformat=0, baddata=0, fudgetime1=0.000, stratum=0,
refid=GPS, flags=0
there seem to be a lot of no replys?

Yes, possible problem there; but that shouldn't affect the client
syncing to it.

Post by d***@bem.fki-et.com
ntpq> rv
status=09f4 leap_none, sync_telephone, 15 events, event_peer/strat_chg,
processor="i686", system="Linux/2.4.20-8", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdispersion=996.710, peer=21093,
refid=GPS, reftime=c7e9cb1a.66643cc0 Fri, Apr 14 2006 7:17:46.399,
poll=4, clock=c7e9cb25.2c766c6d Fri, Apr 14 2006 7:17:57.173,
state=4,
offset=-0.001, frequency=-4.862, jitter=0.006, stability=0.000
I can see nothing suspicious here, apart from sync_telephone possibly?

That, and there's the rootdispersion again. What does "ntpq -crv 21093"
show? (adjust for current peer assoc id).

What is your GPS clock? Is this a Galleon NTP server, by any chance?
I see similar behaviour with what I have been told is one of those,
from an ntp-4.0.99k client.

[d***@bem.fki-et.com]

Post by Ronan Flood

Post by d***@bem.fki-et.com
The servers diagnostics indicate it is happy, and I can sync a linux
(Fedora core 4) box to it ok.

Interesting, perhaps a client version difference: what does "ntpq -crv"
show on your QNX box and your Linux box?

The linux box shows:

ntpq> lpe
remote refid st t when poll reach delay offset
jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 32 64 377 0.000 0.000
0.004
*172.16.151.4 .GPS. 1 u 354 1024 377 1.467 1.698
0.004


ntpq> as

ind assID status conf reach auth condition last_event cnt
===========================================================
1 53012 9014 yes yes none reject reachable 1
2 53013 9614 yes yes none sys.peer reachable 1


ntpq> rv 53013
assID=53013 status=9614 reach, conf, sel_sys.peer, 1 event,
event_reach,
srcadr=172.16.151.4, srcport=123, dstadr=172.16.20.117, dstport=123,
leap=00, stratum=1, precision=-20, rootdelay=0.000,
rootdispersion=996.750, refid=GPS, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=10, ppoll=10, flash=00 ok, keyid=0, ttl=0, offset=1.698,
delay=1.467, dispersion=14.844, jitter=0.004,
reftime=c7f0bd31.269da597 Wed, Apr 19 2006 14:44:17.150,
org=c7f0bd3a.a7a0945f Wed, Apr 19 2006 14:44:26.654,
rec=c7f0bd3a.a7616723 Wed, Apr 19 2006 14:44:26.653,
xmt=c7f0bd3a.a6fdfc19 Wed, Apr 19 2006 14:44:26.652,
filtdelay= 1.47 1.52 1.48 1.51 1.58 1.55 1.51
1.46,
filtoffset= 1.70 1.70 1.74 1.61 1.65 1.63 1.66
1.73,
filtdisp= 0.00 15.39 30.77 46.13 61.49 76.86 92.24
107.61
ntpq>

Post by Ronan Flood
I gather your stratum-1 has two interfaces; have you tried the QNX
client with only one of the server's addresses configured?

Yes, I have tried each single port through a network, and a crossover.
both of them exhibit the same 'feature'


<<SNIP>>

Post by Ronan Flood

Post by d***@bem.fki-et.com
ntpq> rv
status=09f4 leap_none, sync_telephone, 15 events, event_peer/strat_chg,
processor="i686", system="Linux/2.4.20-8", leap=00, stratum=1,
precision=-20, rootdelay=0.000, rootdispersion=996.710, peer=21093,
refid=GPS, reftime=c7e9cb1a.66643cc0 Fri, Apr 14 2006 7:17:46.399,
poll=4, clock=c7e9cb25.2c766c6d Fri, Apr 14 2006 7:17:57.173,
state=4,
offset=-0.001, frequency=-4.862, jitter=0.006, stability=0.000
I can see nothing suspicious here, apart from sync_telephone possibly?

That, and there's the rootdispersion again. What does "ntpq -crv 21093"
show? (adjust for current peer assoc id).

This is on the NTP Server:

ntpq> rv 21093
status=96f4 reach, conf, sel_sys.peer, 15 events, event_reach,
ntpq> srcadr=SHM(1), srcport=123, dstadr=127.0.0.1, dstport=123,
leap=00,
stratum=0, precision=1700881256, rootdelay=0.000, rootdispersion=0.000,
refid=GPS, reach=377, unreach=0, hmode=3, pmode=4, hpoll=4, ppoll=4,
flash=00 ok, keyid=0, ttl=0, offset=0.001, delay=0.000,
dispersion=996.348, jitter=0.002,
reftime=c7f0c2e1.ffffeed9 Wed, Apr 19 2006 14:08:33.999,
org=c7f0c2e1.ffffeed9 Wed, Apr 19 2006 14:08:33.999,
rec=c7f0c2e2.24c8cd63 Wed, Apr 19 2006 14:08:34.143,
xmt=c7f0c2e2.24c79f66 Wed, Apr 19 2006 14:08:34.143,
filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00,
filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00,
filtdisp= 1000.00 1000.27 1000.53 1000.80 1001.04 1001.28 1001.52
1001.76

ntpq>

Is this just the dispersion forn the GPS source? It doesnt have a very
good view
of the sky, but the diagnostics claim all is healthy and ok, and the
Linux box
isnt complaining...

Post by Ronan Flood
What is your GPS clock? Is this a Galleon NTP server, by any chance?
I see similar behaviour with what I have been told is one of those,
from an ntp-4.0.99k client.

It is a Galleon NTP Server. The QNX claims:
version="ntpd ***@1.786 Thu Mar 27 11:18:57 EST 2003 (3)" in its rv.
but the linux is much newer:
version="ntpd ***@1.1190-r Thu Apr 14 07:47:25 EDT 2005 (1)"


Interestingly I have an x86 based QNX box which seems to sync and then
lose sync periodically. An extract from its ntplog.txt:

19 Apr 01:56:34 ntpd[712743]: offset -0.000258 sec freq -28.507 ppm
error 0.000590 poll 10
19 Apr 02:46:34 ntpd[712743]: synchronisation lost
19 Apr 02:56:34 ntpd[712743]: offset 0.000135 sec freq -28.501 ppm
error 0.000548 poll 4
19 Apr 03:56:34 ntpd[712743]: offset -0.001126 sec freq -28.522 ppm
error 0.000490 poll 9
19 Apr 04:56:34 ntpd[712743]: offset -0.000500 sec freq -28.518 ppm
error 0.000502 poll 10
19 Apr 05:56:34 ntpd[712743]: offset 0.000274 sec freq -28.507 ppm
error 0.000493 poll 10
19 Apr 06:56:34 ntpd[712743]: offset -0.000152 sec freq -28.513 ppm
error 0.000565 poll 10
19 Apr 07:56:34 ntpd[712743]: offset -0.000387 sec freq -28.516 ppm
error 0.000653 poll 10
19 Apr 08:56:34 ntpd[712743]: offset 0.000184 sec freq -28.508 ppm
error 0.000564 poll 10
19 Apr 09:56:34 ntpd[712743]: offset -0.000261 sec freq -28.514 ppm
error 0.000605 poll 10
19 Apr 10:56:34 ntpd[712743]: offset 0.000227 sec freq -28.507 ppm
error 0.000541 poll 10
19 Apr 11:00:54 ntpd[712743]: synchronisation lost
19 Apr 11:56:33 ntpd[712743]: offset -0.000805 sec freq -28.515 ppm
error 0.000493 poll 9

where as the XScale box log looks like:

19 Apr 11:35:26 ntpd[335884]: offset 0.000000 sec freq 0.000 ppm error
0.000488 poll 4
19 Apr 12:35:26 ntpd[335884]: offset 0.000000 sec freq 0.000 ppm error
0.000488 poll 4
19 Apr 13:35:26 ntpd[335884]: offset 0.000000 sec freq 0.000 ppm error
0.000488 poll 4

I have also tried setting the x86 QNX box as the server for the XScale,
though this
wont be possible in the final setup, but just to see if it could be
persuaded to sync,
that didnt work either :( Im getting to Hair pulling stage now, and no
one at QNX
seems to be home either!

Thanks for the continuing help

Dave

[Ronan Flood]

Post by d***@bem.fki-et.com
ntpq> rv 53013
assID=53013 status=9614 reach, conf, sel_sys.peer, 1 event,
event_reach,
srcadr=172.16.151.4, srcport=123, dstadr=172.16.20.117, dstport=123,
leap=00, stratum=1, precision=-20, rootdelay=0.000,
rootdispersion=996.750, refid=GPS, reach=377, unreach=0, hmode=3,

Similar rootdispersion, then.

Post by d***@bem.fki-et.com

Post by Ronan Flood

Post by d***@bem.fki-et.com
I can see nothing suspicious here, apart from sync_telephone possibly?

Upon further investigation reference clocks using the shared-memory
driver are always marked sync_telephone.

Post by d***@bem.fki-et.com

Post by Ronan Flood
That, and there's the rootdispersion again. What does "ntpq -crv 21093"
show? (adjust for current peer assoc id).

ntpq> rv 21093
status=96f4 reach, conf, sel_sys.peer, 15 events, event_reach,
ntpq> srcadr=SHM(1), srcport=123, dstadr=127.0.0.1, dstport=123,
leap=00,
stratum=0, precision=1700881256, rootdelay=0.000, rootdispersion=0.000,

That precision figure is nonsense.

Post by d***@bem.fki-et.com
refid=GPS, reach=377, unreach=0, hmode=3, pmode=4, hpoll=4, ppoll=4,
flash=00 ok, keyid=0, ttl=0, offset=0.001, delay=0.000,
dispersion=996.348, jitter=0.002,
reftime=c7f0c2e1.ffffeed9 Wed, Apr 19 2006 14:08:33.999,
org=c7f0c2e1.ffffeed9 Wed, Apr 19 2006 14:08:33.999,
rec=c7f0c2e2.24c8cd63 Wed, Apr 19 2006 14:08:34.143,
xmt=c7f0c2e2.24c79f66 Wed, Apr 19 2006 14:08:34.143,
filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00,
filtoffset= 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00,
filtdisp= 1000.00 1000.27 1000.53 1000.80 1001.04 1001.28 1001.52
1001.76
Is this just the dispersion forn the GPS source? It doesnt have a very
good view
of the sky, but the diagnostics claim all is healthy and ok, and the
Linux box
isnt complaining...

I think that says more about the Linux box than the server.
Those dispersion figures also look iffy.

Post by d***@bem.fki-et.com

Post by Ronan Flood
What is your GPS clock? Is this a Galleon NTP server, by any chance?
I see similar behaviour with what I have been told is one of those,
from an ntp-4.0.99k client.

On which I see

% ntpdc -nc "pstats x.x.x.x"
remote host: x.x.x.x (details not relevant)
local interface: y.y.y.y
time last received: 928s
time until next send: 97s
reachability change: 2790983s
packets sent: 3889
packets received: 3346
bad authentication: 0
bogus origin: 0
duplicate: 0
bad dispersion: 580833 <====
bad reference time: 0
candidate order: 0

Unfortunately that statistic is not gathered in later versions.

Post by d***@bem.fki-et.com
Interestingly I have an x86 based QNX box which seems to sync and then

What version of ntpd is that box running?

One thing you might try is marking the server prefer in ntp.conf, eg

server 172.16.151.4 prefer


Failing that (or anyone else's input ...) maybe the newer ntpd is
just more forgiving of "high" rootdispersion, so you might have no
choice but to upgrade ntpd to a later version.

(One thing I notice was changed in 4.2.0 from earlier versions,
in ntp_proto.c the comparison to root_distance changes from

root_distance(peer) >= MAXDISTANCE + 2 * ...

to

root_distance(peer) >= MAXDISTANCE + 2. * ...

Was that actually a bug-fix?)

[d***@bem.fki-et.com]

Ronan,
The QNX bods have finally replyed. They have reproduced the problem and
are 'looking into it'.
As they are paid a hefty sum by us for support Ill see what they come
up with, so for now ive moved
onto other (not quite related) matters.
Thanks for your help, Ill post the outcome here when it appears.

Dave

[Ronan Flood]

Post by d***@bem.fki-et.com
The QNX bods have finally replyed. They have reproduced the problem and
are 'looking into it'.
As they are paid a hefty sum by us for support Ill see what they come
up with, so for now ive moved
onto other (not quite related) matters.
Thanks for your help, Ill post the outcome here when it appears.

I look forward to it -- best of luck!
I think the real problem lies with the Galleon server's strange
dispersion figures; anything else is only working around that.

[Ronan Flood]

Post by Ronan Flood
I think the real problem lies with the Galleon server's strange
dispersion figures; anything else is only working around that.

I think I've sussed this: the refclock precision is actually set
to *zero*, which means the filter dispersion is approx 2^0 == 1.

That looks like a bug in whatever is feeding data to refclock_shm,
and possibly also an oversight in refclock_shm not checking that
it has a sensible precision value before passing it upwards.

This also exposes a long-standing bug in ntpq.c\decodeint(), where
"&val" is used (twice) instead of "val", which screws-up display
of a zero precision value; eg:

ntpq> rv &2
status=9624 reach, conf, sel_sys.peer, 2 events, event_reach,
srcadr=127.127.28.1, srcport=123, dstadr=127.0.0.1, dstport=123,
leap=00, stratum=0, precision=10, rootdelay=0.000, rootdispersion=0.000,
[...]
ntpq> raw
Output set to raw
ntpq> rv &2
status=0x9624,
srcadr=127.127.28.1, srcport=123, dstadr=127.0.0.1, dstport=123, leap=0,
stratum=0, precision=0, rootdelay=0.000, rootdispersion=0.000,
[...]

Compare decodeint() with decodeuint() ...

[Harlan Stenn]

Post by Ronan Flood
That looks like a bug in whatever is feeding data to refclock_shm,
and possibly also an oversight in refclock_shm not checking that
it has a sensible precision value before passing it upwards.

Please open an issue at bugs.ntp.isc.org for the ntp product and the
"refclock_shm" component if you believe this is a bug.

Post by Ronan Flood
This also exposes a long-standing bug in ntpq.c\decodeint(), where
"&val" is used (twice) instead of "val", which screws-up display

Please open an issue at bugs.ntp.isc.org for the NTP product and the "other"
component for this.

Thanks...

H

[Ronan Flood]

Post by Harlan Stenn

Post by Ronan Flood
and possibly also an oversight in refclock_shm not checking that
it has a sensible precision value before passing it upwards.

Please open an issue at bugs.ntp.isc.org for the ntp product and the
"refclock_shm" component if you believe this is a bug.

I don't think it's a bug as such: precision is a signed number
so values >= 0 are valid, I'm just not sure they're sensible;
especially in the light of the behaviour seen here.

Post by Harlan Stenn

Post by Ronan Flood
This also exposes a long-standing bug in ntpq.c\decodeint(), where

Please open an issue at bugs.ntp.isc.org for the NTP product and the
"other" component for this.

Righto.

[Harlan Stenn]

Thanks!

h

[d***@bem.fki-et.com]

Hi All,
I have finally got my QNX Box to sync. :) There were an couple of
issues in the BSP for the system, which has been resolved, and now the
box will sync to external NTP servers. I still cant get the local NTP
server to be accepted, but the current theory on that is it doesnt have
a good enough view of the sky, hence its precision and dispersion
figures are junk.

Im going to moe the ariel again, so fingers crossed.
Thanks for you help

Dave