03.08.2011 15:17, Dave Hart пишет:
On Wed, Aug 3, 2011 at 10:40 UTC, Valera<[email protected]> 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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
