[ntp:questions] ntpd

Dave Hart hart at ntp.org
Thu Aug 4 18:45:47 UTC 2011


On Thu, Aug 4, 2011 at 16:17, Valera <valera.sigaev at developonbox.ru> wrote:
> I got the next result for command.
>
> # /home/mpi/bin/ntpq -c rv -p -c "rv &1" -c as 127.0.0.1
> associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
> version="ntpd 4.2.7.box Mon Aug 1 16:27:31 UTC 2011 (4)",
> processor="97459b0", system="Linux/2.6.18-5.0", leap=11, stratum=16,
> precision=-19, rootdelay=0.000, rootdisp=28.155, refid=INIT,
> reftime=00000000.00000000  Thu, Feb  7 2036  6:28:16.000,
> clock=d1e53cc3.7f6a4011  Thu, Aug  4 2011 15:44:03.497, peer=0, tc=3,
> mintc=3, offset=0.000, frequency=0.000, sys_jitter=2.142,
> clk_jitter=0.002, clk_wander=0.000
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
>  10.251.231.1    167.206.1.30     3 u   53   64  377    6.220  225.121
> 2.142
> associd=41168 status=9024 conf, reach, sel_reject, 2 events, reachable,
> srcadr=10.251.231.1, srcport=123, dstadr=10.251.16.22, dstport=123,
> leap=00, stratum=3, precision=-18, rootdelay=17.044, rootdisp=17.303,
> refid=167.206.1.30,
> reftime=d1e53bdc.c94bb80b  Thu, Aug  4 2011 15:40:12.786,
> rec=d1e53cd2.159a4162  Thu, Aug  4 2011 15:44:18.084, reach=377,
> unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=202, flash=00 ok,
> keyid=0, offset=224.975, delay=6.742, dispersion=0.996, jitter=2.075,
> xleave=0.252,
> filtdelay=     6.74    6.22    5.93    7.60    7.05    6.79    8.38    7.79,
> filtoffset=  224.97  225.12  225.34  226.58  226.68  226.86  228.15  228.27,
> filtdisp=      0.01    1.03    2.06    3.10    4.13    5.15    6.19    7.18
>
> ind assid status  conf reach auth condition  last_event cnt
> ===========================================================
>   1 41168  9024   yes   yes  none    reject   reachable  2
>
> I saw the strange fields refid=INIT, reftime=00000000.00000000  Thu, Feb  7
> 2036  6:28:16.000, but I think that it related to disabled ssl option in
> config.h(embedded linux didn't have crypto library). flash field has the ok
> status

refid=INIT means ntpd has never had a source selected.  leap=11 (leap
is displayed in binary) indicates ntpd is currently not synchronized.
If it were synchronized, leap would be 00 (no leap second pending), or
01 or 10 (leap second insertion or deletion is pending at the end of
the month).  The reftime is the timestamp at the ultimate (stratum 0,
refclock) source of the last clock update, all zeros is indicating the
same as refid=INIT, this ntpd hasn't been synchronized since startup.

The root cause of these is your single source is being rejected.  I
don't see the reason for the rejection in evidence, I'm sorry to say.

> But this situation observed only for this device. From other pc:
>
> associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
> version="ntpd 4.2.6p3 at 1.2290-o Wed Aug  3 15:37:34 UTC 2011 (19)",
> processor="i686", system="Linux/2.6.38-10-generic", leap=00, stratum=4,
> precision=-20, rootdelay=143.078, rootdisp=50.982, refid=10.251.231.1,
> reftime=d1e52a79.eb3c019b  Thu, Aug  4 2011 18:26:01.918,
> clock=d1e52a9a.7a932bc5  Thu, Aug  4 2011 18:26:34.478, peer=13053,
> tc=10, mintc=3, offset=2.909, frequency=26.002, sys_jitter=14.629,
> clk_jitter=7.429, clk_wander=0.603
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
> *10.251.231.1    167.206.1.30     3 u   33 1024  377  134.152    2.909
> 14.629
> associd=13053 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer,
> srcadr=10.251.231.1, srcport=123, dstadr=192.168.19.21, dstport=123,
> leap=00, stratum=3, precision=-18, rootdelay=8.926, rootdisp=16.769,
> refid=167.206.1.30,
> reftime=d1e5288e.b7c49d1b  Thu, Aug  4 2011 18:17:50.717,
> rec=d1e52a79.eb3c019b  Thu, Aug  4 2011 18:26:01.918, reach=377,
> unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=25, flash=00 ok,
> keyid=0, offset=2.909, delay=134.152, dispersion=16.195, jitter=14.629,
> xleave=0.063,
> filtdelay=   134.15  136.52  133.31  174.25  142.91  130.30  143.06  130.57,
> filtoffset=    2.91    2.51   -1.56  -25.68  -10.43   -4.83  -13.22   -9.86,
> filtdisp=      0.01   15.59   31.21   47.48   63.50   79.81   96.11  111.88
>
> ind assid status  conf reach auth condition  last_event cnt
> ===========================================================
>   1 13053  961a   yes   yes  none  sys.peer    sys_peer  1

I wish I could be more helpful, but I don't see a meaningful
difference between the results you see on the embedded platform and
what you see on a PC to explain why the peer is being rejected on the
embedded system.  Perhaps someone else here will see something I
missed.

Otherwise, in your position I'd try adding extra DPRINTF() calls to
ntp_proto.c to try to zero in on where the decision is taken to reject
the peer, and iterate testing and adjusting the extra debug output
until you identify the divergence between the PC and the embedded
system.

Good luck,
Dave Hart



More information about the questions mailing list