[ntp:questions] ntpd
Valera
valera.sigaev at developonbox.ru
Wed Aug 3 10:40:13 UTC 2011
03.08.2011 14:12, Dave Hart пишет:
> On Wed, Aug 3, 2011 at 08:32 UTC, Valera<valera.sigaev at developonbox.ru> wrote:
>> No. It's real pc. But as I clearly understand sntp-client shows other
>> offset:
>>
>> vvs at sigaev:~$ ~/work/ntp-4.2.6p3/sntp/sntp 194.190.16.51
>> 2 Aug 19:59:25 sntp[18295]: Started sntp 2011-08-02 19:59:25.052161
>> (-0300) +0.315752 ± 0.018951 secs
> That's the same 315 millisecond offset (sntp is reporting seconds,
> where ntpq is reporting milliseconds. Clearly, ntpd 4.2.6p3 is not
> working correctly for, or it would be able to bring the offset much
> lower, typically lower than the delay to the source (18 milliseconds
> here).
>
>>>> Btw: After that I downloaded development version 4.2.7... and this
>>>> version also synchronizes pc fine.
>>> We are close to releasing 4.2.6p4, please consider repeating your test
>>> with 4.2.6p4-RC1. There's still time to fix bugs in it before 4.2.6p4
>>> is released.
>> I'll be waiting.
> I'm afraid we're having a problem communicating. If you wait for
Sorry I'm inattentive.
> 4.2.6p4 to be released, we will have missed the opportunity to fix the
> problem you are seeing with 4.2.6p3. You write that ntpd 4.2.7 is
> able to synchronize the clock well (I presume to an offset much lower
> than 315 msec). You show ntpq and sntp output indicating ntpd 4.2.6p3
> is synchronized, but has far too large an offset. I am asking you to
> try 4.2.6p4-RC1, to see if it also has problems, because if it does, I
> would like to try to fix them before 4.2.6p4 is released. You can
> download it from:
>
> http://www.ntp.org/downloads.html
>
> specifically:
>
> http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.6p4-RC1.tar.gz
>
> I'm happy to hear 4.2.7 is working well for you, but I want our
> upcoming 4.2.6p4 to work comparably well.
>
It works fine.
vvs at sigaev:~$ ~/work/ntp-4.2.6p4-RC1/ntpq/ntpq -p
remote refid st t when poll reach delay
offset jitter
==============================================================================
gw.promodev.ru 173.201.38.85 3 u 65 64 7 10.313
388.537 0.076
218-32-169-193. 194.149.67.129 3 u 63 64 7 14.952
389.889 0.021
lugh.chelraboch 195.2.64.5 2 u 61 64 7 84.867
398.852 0.097
ground.corbina. 131.188.3.223 2 u 58 64 7 22.554
393.767 0.306
europium.canoni 193.79.237.14 2 u 59 64 7 47.538
383.264 0.077
vvs at sigaev:~$ ~/work/ntp-4.2.6p4-RC1/ntpq/ntpq -p
remote refid st t when poll reach delay
offset jitter
==============================================================================
gw.promodev.ru 173.201.38.85 3 u 8 64 1 10.435
-0.127 0.000
218-32-169-193. 194.149.67.129 3 u 10 64 1 15.353
0.834 0.000
lugh.chelraboch 195.2.64.5 2 u 11 64 1 85.294
9.671 0.000
ground.corbina. 131.188.3.223 2 u 11 64 1 22.397
5.068 0.000
europium.canoni 193.79.237.14 2 u 11 64 1 47.834
-5.768 0.000
vvs at sigaev:~$
But the goal to run ntpd on pc is an intermediate.
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?
ps: The pc-version got the valid timestamps.
> Cheers,
> Dave Hart
>
More information about the questions
mailing list