On Thu, Aug 4, 2011 at 16:17, Valera <[email protected]> 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 [email protected] 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
