[ntp:questions] ntpd

Valera valera.sigaev at developonbox.ru
Wed Aug 3 10:40:13 UTC 2011



03.08.2011 14:12, Dave Hart пишет:
> On Wed, Aug 3, 2011 at 08:32 UTC, Valera<valera.sigaev at developonbox.ru>  wrote:
>> No. It's real pc. But as I clearly understand sntp-client shows other
>> offset:
>>
>> vvs at sigaev:~$ ~/work/ntp-4.2.6p3/sntp/sntp 194.190.16.51
>>        2 Aug 19:59:25 sntp[18295]: Started sntp 2011-08-02 19:59:25.052161
>> (-0300) +0.315752 ± 0.018951 secs
> That's the same 315 millisecond offset (sntp is reporting seconds,
> where ntpq is reporting milliseconds.  Clearly, ntpd 4.2.6p3 is not
> working correctly for, or it would be able to bring the offset much
> lower, typically lower than the delay to the source (18 milliseconds
> here).
>
>>>> Btw: After that I downloaded development version 4.2.7... and this
>>>> version also synchronizes pc fine.
>>> We are close to releasing 4.2.6p4, please consider repeating your test
>>> with 4.2.6p4-RC1.  There's still time to fix bugs in it before 4.2.6p4
>>> is released.
>> I'll be waiting.
> I'm afraid we're having a problem communicating.  If you wait for
Sorry I'm inattentive.
> 4.2.6p4 to be released, we will have missed the opportunity to fix the
> problem you are seeing with 4.2.6p3.  You write that ntpd 4.2.7 is
> able to synchronize the clock well (I presume to an offset much lower
> than 315 msec).  You show ntpq and sntp output indicating ntpd 4.2.6p3
> is synchronized, but has far too large an offset.  I am asking you to
> try 4.2.6p4-RC1, to see if it also has problems, because if it does, I
> would like to try to fix them before 4.2.6p4 is released.  You can
> download it from:
>
> http://www.ntp.org/downloads.html
>
> specifically:
>
> http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.6p4-RC1.tar.gz
>
> I'm happy to hear 4.2.7 is working well for you, but I want our
> upcoming 4.2.6p4 to work comparably well.
>
It works fine.

    vvs at sigaev:~$ ~/work/ntp-4.2.6p4-RC1/ntpq/ntpq -p
          remote           refid      st t when poll reach   delay  
    offset  jitter
    ==============================================================================
      gw.promodev.ru  173.201.38.85    3 u   65   64    7   10.313 
    388.537   0.076
      218-32-169-193. 194.149.67.129   3 u   63   64    7   14.952 
    389.889   0.021
      lugh.chelraboch 195.2.64.5       2 u   61   64    7   84.867 
    398.852   0.097
      ground.corbina. 131.188.3.223    2 u   58   64    7   22.554 
    393.767   0.306
      europium.canoni 193.79.237.14    2 u   59   64    7   47.538 
    383.264   0.077
    vvs at sigaev:~$ ~/work/ntp-4.2.6p4-RC1/ntpq/ntpq -p
          remote           refid      st t when poll reach   delay  
    offset  jitter
    ==============================================================================
      gw.promodev.ru  173.201.38.85    3 u    8   64    1   10.435  
    -0.127   0.000
      218-32-169-193. 194.149.67.129   3 u   10   64    1   15.353   
    0.834   0.000
      lugh.chelraboch 195.2.64.5       2 u   11   64    1   85.294   
    9.671   0.000
      ground.corbina. 131.188.3.223    2 u   11   64    1   22.397   
    5.068   0.000
      europium.canoni 193.79.237.14    2 u   11   64    1   47.834  
    -5.768   0.000
    vvs at sigaev:~$


But the goal to run ntpd on pc is an intermediate.
The final goal of running the version on a device.
I built a package based on version 4.2.7 and have the following problem:

    read_network_packet: fd=19 length 48 from 10.251.231.1
    fetch_timestamp: system network time stamp: 1312362541.175773
    fetch_timestamp: timestamp delta: 0.001328514 (incl. prec fuzz)
    ...
      3 Aug 09:10:08 ntpd[216]: select(): nfound=-1, error: Interrupted
    system call
    sendpkt(19, dst=10.251.231.1, src=10.251.16.22, ttl=0, len=48)
    transmit: at 68 10.251.16.22->10.251.231.1 mode 3 len 48
    poll_update: at 68 10.251.231.1 poll 6 burst 0 retry 0 head 62 early
    2 next 67
    read_network_packet: fd=19 length 48 from 10.251.231.1
    fetch_timestamp: system network time stamp: 1312362544.763918
    fetch_timestamp: timestamp delta: 63.415279052 (incl. prec fuzz)
    ...
      3 Aug 09:11:12 ntpd[216]: select(): nfound=-1, error: Interrupted
    system call
    sendpkt(19, dst=10.251.231.1, src=10.251.16.22, ttl=0, len=48)
    transmit: at 132 10.251.16.22->10.251.231.1 mode 3 len 48
    poll_update: at 132 10.251.231.1 poll 6 burst 0 retry 0 head 62
    early 2 next 67
    read_network_packet: fd=19 length 48 from 10.251.231.1
    fetch_timestamp: system network time stamp: 1312362545.412136
    fetch_timestamp: timestamp delta: 126.762424757 (incl. prec fuzz)
    ...
      3 Aug 09:12:16 ntpd[216]: select(): nfound=-1, error: Interrupted
    system call
    sendpkt(19, dst=10.251.231.1, src=10.251.16.22, ttl=0, len=48)
    transmit: at 196 10.251.16.22->10.251.231.1 mode 3 len 48
    poll_update: at 196 10.251.231.1 poll 6 burst 0 retry 0 head 62
    early 2 next 67
    read_network_packet: fd=19 length 48 from 10.251.231.1
    fetch_timestamp: system network time stamp: 1312362546.034024
    fetch_timestamp: timestamp delta: 190.140930640 (incl. prec fuzz)
    ...

As I see ntpd got the same time from ntp-server or it looks like they 
got the same time. Where I could locate this issue?
ps: The pc-version got the valid timestamps.
> Cheers,
> Dave Hart
>



More information about the questions mailing list