[ntp:questions] ntpd

Valera valera.sigaev at developonbox.ru
Wed Aug 3 13:41:29 UTC 2011



03.08.2011 15:17, Dave Hart пишет:
> On Wed, Aug 3, 2011 at 10:40 UTC, Valera<valera.sigaev at developonbox.ru>  wrote:
>> It works fine.
> I'm relieved to hear that, thanks for testing 4.2.6p4-RC1.
>
>> 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?
> I see two problems, which may be related, or may not be.  First,
> you're logging an interrupted system call from select() each poll.
> Second, the SO_TIMESTAMP timestamps are advancing about 1 second for
> every poll, 64 seconds apart.  In your position, I'd pick one of
> those, try to figure it out, and if I stopped making progress, switch
> to looking at the other one for a bit.
>
I'm not sure that exactly understand what you mean. Should I minimize 
debug information or do smoething else?
> Regarding the interrupted system call, you have my sympathy.  The
> socket I/O code in ntpd is not easy to wrap your head around.  In case
> the two issues are related, you could try hacking on ntpd to not use
> SO_TIMESTAMP and see if the other issue remains.
>
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.231.1
          remote           refid      st t when poll reach   delay  
    offset  jitter
    ==============================================================================
    +167.206.1.103   10.248.0.195     2 u  765 1024  377   22.080  
    11.402   7.570
    *167.206.1.30    10.248.0.195     2 u  825 1024  377   13.310   
    5.769   6.030
    # /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
    # /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   64   64  377    6.083   
    9.458   1.914

But I know that the device's time runs forward. And I didn't see fast 
time adjustment.
Also I have the next log(in attachments)


> What embedded OS are you targetting?  What CPU?
>
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

> Good luck,
> Dave Hart
>


More information about the questions mailing list