03.08.2011 14:12, Dave Hart пишет:
On Wed, Aug 3, 2011 at 08:32 UTC, Valera<[email protected]> wrote:
No. It's real pc. But as I clearly understand sntp-client shows other
offset:
vvs@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@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@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@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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
