[ntp:questions] ntpd

Dave Hart hart at ntp.org
Wed Aug 3 11:17:10 UTC 2011


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.

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



More information about the questions mailing list