[ntp:questions] ntpd

[Valera]

03.08.2011 23:42, Dave Hart пишет:
> On Wed, Aug 3, 2011 at 13:41 UTC, Valera<valera.sigaev at developonbox.ru>  wrote:
>> I did undef SO_TIMESTAMP for ntpd and execute again. The situation has
>> improved, because I see that offset calculates correctly. But I'm not sure
>> that the time is adjusted.
>> I have next information from ntpq utility:
>>
>> # /home/mpi/bin/ntpq -p 10.251.16.22
>>       remote           refid      st t when poll reach   delay   offset
>> jitter
>> ==============================================================================
>>   10.251.231.1    167.206.1.30     3 u    5   64  377    7.252   13.031
>> 1.329
>> # /home/mpi/bin/ntpq -p 10.251.16.22
>>       remote           refid      st t when poll reach   delay   offset
>> jitter
>> ==============================================================================
>>   10.251.231.1    167.206.1.30     3 u   49   64  377    8.143   11.555
>> 1.103
>> uname -a returns the next:
>>
>> # uname -a
>> Linux SamSTB 2.6.18-5.0 #4 Tue Feb 1 04:12:29 KST 2011 97459b0 unknown
> That is improvement.  SO_TIMESTAMP has worked for most people using
> Linux for ages, so either your embedded platform managed to break it,
> or your configure is not being run on the embedded platform and you're
> guessing/providing the wrong cross-compilation options to configure
> and getting something inappropriate in config.h
>
> When you say you're not sure time is being synched, you are making me
> feel like I'm doing your homework.  I wanted to suggest for you to
> move this discussion to the programming-oriented
> hackers at lists.ntp.org, but hesitate because you could use the help of
> questions at lists.ntp.org to understand how to interpret ntpq -p output.
>
I didin't see any software errors and any reasons to move this 
discussion to the programming-oriented section.
> The clock _definitely is not_ being synched because the first column
> of the ntpq -p output is not showing a * to indicate 10.251.231.1 is
> selected as the time source.  To further diagnose why, it is not
> productive to pore over your debug output log when ntpq will do.  Try:
>
> ntpq -c rv -p -c "rv&1" 10.251.16.22
>
> The output of "rv&1", the peer variables for your box's single
> source, will include a "flash=" that will tell you why the source is
> not being selected.
>
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
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


> As you are relying on me to teach you how to troubleshoot ntpd and
> help you port it to an embedded platform, e.g. have not done your
> homework, expect me to have declining interest in helping you.  I am a
> volunteer and I have to feed myself too, so I'm not going to do your
> job for you and let you collect the pay.
>

Thanks a lot for teaching. I'm not surethatmanywill get forthis 
job,buttheprofitscanbuy youa beer.
I'm just tryingto usethis listas a resourcefor sharing experiences,and 
nottocarry out myorders
> Cheers,
> Dave Hart
>