[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