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. 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. What embedded OS are you targetting? What CPU? Good luck, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
