Странное поведение ntpd

Victor Sudakov написал(а) к All в Jul 15 15:14:09 по местному времени:

From: Victor Sudakov <vas@mpeks.tomsk.su>

Как так может быть, что peers показывает, что синхронизация есть, а
sysinfo показывает 16 стратум?


$ ntpdc -n -c peers
remote local st poll reach delay offset disp
=======================================================================
*10.14.140.111 10.14.140.38 3 64 376 0.00000 2.678927 0.01826
$ ntpdc -n -c sysinfo
system peer: 10.14.140.111
system peer mode: control
leap indicator: 11
stratum: 16
precision: -21
root distance: 0.00000 s
root dispersion: 0.01393 s
reference ID: [10.14.140.111]
reference time: 00000000.00000000 Thu, Feb 7 2036 12:28:16.000
system flags: bclient ntp kernel stats
jitter: 0.390671 s
stability: 0.000 ppm
broadcastdelay: 0.003998 s
authdelay: 0.000004 s
$

Вот еще для информации


$ ntpdate -d 10.14.140.111
11 Jul 17:59:41 ntpdate[32345]: ntpdate 4.2.4p5-a (1)
transmit(10.14.140.111)
receive(10.14.140.111)
transmit(10.14.140.111)
receive(10.14.140.111)
transmit(10.14.140.111)
receive(10.14.140.111)
transmit(10.14.140.111)
receive(10.14.140.111)
transmit(10.14.140.111)
server 10.14.140.111, port 123
stratum 3, precision -18, leap 00, trust 000
refid [10.14.140.111], delay 0.02713, dispersion 0.00003
transmitted 4, in filter 4
reference time: d94b8398.c40b75f7 Sat, Jul 11 2015 17:59:20.765
originate timestamp: d94b83ad.a696d0cd Sat, Jul 11 2015 17:59:41.650
transmit timestamp: d94b83ad.2a775b81 Sat, Jul 11 2015 17:59:41.165
filter delay: 0.02713 0.02715 0.02722 0.02716
0.00000 0.00000 0.00000 0.00000
filter offset: 0.483958 0.484000 0.484027 0.484027
0.000000 0.000000 0.000000 0.000000
delay 0.02713, dispersion 0.00003
offset 0.483958

11 Jul 17:59:41 ntpdate[32345]: adjust time server 10.14.140.111 offset 0.483958 sec
$
$

--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
--- ifmail v.2.15dev5.4

Andrew Kant написал(а) к Victor Sudakov в Jul 15 09:14:16 по местному времени:

Нello Victor!

Saturday July 11 2015 15:14, Victor Sudakov wrote to All:
VS> Как так может быть, что peers показывает, что синхронизация есть, а
VS> sysinfo показывает 16 стратум?


VS> $ ntpdc -n -c peers
VS> remote local st poll reach delay offset disp
VS> =======================================================================
VS> *10.14.140.111 10.14.140.38 3 64 376 0.00000 2.678927 0.01826

reach = 376 = 11 111 110

то есть когда-то она была, но на последнем цикле как раз связи уже не было.


VS> $ ntpdc -n -c sysinfo
VS> system peer: 10.14.140.111
VS> system peer mode: control
VS> leap indicator: 11
VS> stratum: 16
VS> precision: -21
VS> root distance: 0.00000 s
VS> root dispersion: 0.01393 s
VS> reference ID: [10.14.140.111]
VS> reference time: 00000000.00000000 Thu, Feb 7 2036 12:28:16.000
VS> system flags: bclient ntp kernel stats
VS> jitter: 0.390671 s
VS> stability: 0.000 ppm
VS> broadcastdelay: 0.003998 s
VS> authdelay: 0.000004 s
VS> $

VS> Вот еще для информации


VS> $ ntpdate -d 10.14.140.111
VS> 11 Jul 17:59:41 ntpdate[32345]: ntpdate 4.2.4p5-a (1)
VS> transmit(10.14.140.111)
VS> receive(10.14.140.111)
VS> transmit(10.14.140.111)
VS> receive(10.14.140.111)
VS> transmit(10.14.140.111)
VS> receive(10.14.140.111)
VS> transmit(10.14.140.111)
VS> receive(10.14.140.111)
VS> transmit(10.14.140.111)
VS> server 10.14.140.111, port 123
VS> stratum 3, precision -18, leap 00, trust 000
VS> refid [10.14.140.111], delay 0.02713, dispersion 0.00003
VS> transmitted 4, in filter 4
VS> reference time: d94b8398.c40b75f7 Sat, Jul 11 2015 17:59:20.765
VS> originate timestamp: d94b83ad.a696d0cd Sat, Jul 11 2015 17:59:41.650
VS> transmit timestamp: d94b83ad.2a775b81 Sat, Jul 11 2015 17:59:41.165
VS> filter delay: 0.02713 0.02715 0.02722 0.02716
VS> 0.00000 0.00000 0.00000 0.00000
VS> filter offset: 0.483958 0.484000 0.484027 0.484027
VS> 0.000000 0.000000 0.000000 0.000000
VS> delay 0.02713, dispersion 0.00003
VS> offset 0.483958

VS> 11 Jul 17:59:41 ntpdate[32345]: adjust time server 10.14.140.111 offset
VS> 0.483958 sec $ $

А ты уверен, что на 140.111 не было никаких скачков времени? Может причина в нём, а твой 140.38, имея единственного пира, подумал, что тот свихнулся и перестал ему доверять?


Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Victor Sudakov написал(а) к Andrew Kant в Jul 15 10:06:36 по местному времени:

Dear Andrew,

12 Jul 15 09:14, you wrote to me:

VS>> Как так может быть, что peers показывает, что синхронизация есть,
VS>> а sysinfo показывает 16 стратум?


VS>> $ ntpdc -n -c peers
VS>> remote local st poll reach delay offset
VS>> disp
VS>> =================================================================
VS>> ====== *10.14.140.111 10.14.140.38 3 64 376 0.00000
VS>> 2.678927 0.01826

AK> reach = 376 = 11 111 110

AK> то есть когда-то она была, но на последнем цикле как раз связи уже не
AK> было.

Это интересная информация. Но они в одной ЛВС, с чего бы связи не быть.

[dd]


AK> А ты уверен, что на 140.111 не было никаких скачков времени? Может
AK> причина в нём, а твой 140.38, имея единственного пира, подумал, что
AK> тот свихнулся и перестал ему доверять?

"Всю Одессу удовлетворяет..." в смысле с 10.14.140.111 много кто время берет, она шлет NTP broadcasts.

Сейчас попробую 10.14.140.38 перевести на unicast client и добавить пиров, о результатах сообщу.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Vova Uralsky написал(а) к Andrew Kant в Jul 15 17:32:56 по местному времени:

Нello Andrew!

12 Jul 15 09:14, Andrew Kant wrote to Victor Sudakov:

VS>> *10.14.140.111 10.14.140.38 3 64 376 0.00000 2.678927
VS>> leap indicator: 11
VS>> stratum: 16
VS>> precision: -21
VS>> root dispersion: 0.01393 s
VS>> jitter: 0.390671 s

VS>> offset 0.483958

AK> А ты уверен, что на 140.111 не было никаких скачков времени? Может

Были-были. jitter вона какой.

AK> причина в нём, а твой 140.38, имея единственного пира, подумал, что
AK> тот свихнулся и перестал ему доверять?

'*' перед алресом должна свидетельствовать об обратном? Меня смущает что ntpdc показывает оффсет 2.678927 милисекунд, а ntpdate видит почти полсекунды.

Подземный стук, который скорее всего, лечится рестартом ntpd.

Regards,
Vova

--- Msged/BSD 6.2.0

Andrew Kant написал(а) к Victor Sudakov в Jul 15 11:29:01 по местному времени:

Нello Victor!

Sunday July 12 2015 10:06, Victor Sudakov wrote to Andrew Kant:

VS>>> Как так может быть, что peers показывает, что синхронизация есть,
VS>>> а sysinfo показывает 16 стратум?


VS>>> $ ntpdc -n -c peers
VS>>> remote local st poll reach delay offset
VS>>> disp
VS>>> =================================================================
VS>>> ====== *10.14.140.111 10.14.140.38 3 64 376 0.00000
VS>>> 2.678927 0.01826

AK>> reach = 376 = 11 111 110

AK>> то есть когда-то она была, но на последнем цикле как раз связи уже
AK>> не было.

VS> Это интересная информация. Но они в одной ЛВС, с чего бы связи не быть.

Была глупая идея, что такое могло быть после выхода из спячки и восстановлении времени из ненастроенных RTC, но эксперимент показывает, что ntpd в таком случае полностью очищает колонку reach, у тебя-же там есть единички, то есть пропало совсем недавно.

Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Victor Sudakov написал(а) к Andrew Kant в Jul 15 10:37:10 по местному времени:

Dear Andrew,

13 Jul 15 11:29, you wrote to me:
VS>>>> Как так может быть, что peers показывает, что синхронизация
VS>>>> есть, а sysinfo показывает 16 стратум?

[dd]
VS>> Это интересная информация. Но они в одной ЛВС, с чего бы связи не
VS>> быть.

AK> Была глупая идея, что такое могло быть после выхода из спячки и
AK> восстановлении времени из ненастроенных RTC, но эксперимент
AK> показывает, что ntpd в таком случае полностью очищает колонку reach, у
AK> тебя-же там есть единички, то есть пропало совсем недавно.

Перевел на уникаст и добавил еще пиров, результат такой (и рестартом ntpd разумется не лечится):

$ ntpdc -n -c peers
remote local st poll reach delay offset disp
=======================================================================
=10.14.140.125 10.14.140.38 3 64 377 0.00012 1.552297 0.04713
*10.14.129.72 10.14.140.38 3 64 377 0.00020 1.569088 0.03070
=10.14.129.73 10.14.140.38 4 64 377 0.00040 1.730840 0.03082

$ ntpdc -n -c sysinfo
system peer: 10.14.129.72
system peer mode: client
leap indicator: 11
stratum: 16
precision: -21
root distance: 0.00000 s
root dispersion: 0.00891 s
reference ID: [10.14.129.72]
reference time: d94e55db.29d48117 Mon, Jul 13 2015 21:20:59.163
system flags: ntp kernel stats
jitter: 0.863266 s
stability: 0.000 ppm
broadcastdelay: 0.003998 s
authdelay: 0.000000 s
$

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Vova Uralsky написал(а) к Victor Sudakov в Jul 15 21:14:04 по местному времени:

Нello Victor!

13 Jul 15 10:37, Victor Sudakov wrote to Andrew Kant:

VS>>>>> Как так может быть, что peers показывает, что синхронизация
VS>>>>> есть, а sysinfo показывает 16 стратум?
VS> Перевел на уникаст и добавил еще пиров, результат такой (и рестартом
VS> ntpd разумется не лечится):

VS> $ ntpdc -n -c peers
VS> remote local st poll reach delay offset
VS> disp
VS> =====================================================================
VS> ==
VS> =10.14.140.125 10.14.140.38 3 64 377 0.00012 1.552297
VS> 0.04713
VS> *10.14.129.72 10.14.140.38 3 64 377 0.00020 1.569088
VS> 0.03070
VS> =10.14.129.73 10.14.140.38 4 64 377 0.00040 1.730840
VS> 0.03082

Взглянул незамутнённым взглядом... Тебя не смущает оффсет в полторы секунды? Тебя не смущает что 129.73 отстоит от остальных на почти 0.2 секунды? Попробуй остановить ntpd, echo > /твой/ntp.drift, выставить время ntpdate и запустить ntpd снова. Или -x добавить.

<телепат>У тебя это не в виртуалке случаем творится? Для например вмвари есть например KB 1006427... Про FBSD там есть vmware-toolbox-cmd timesync disable ... Например...</телепат>

Regards,
Vova

--- Msged/BSD 6.2.0

Victor Sudakov написал(а) к Vova Uralsky в Jul 15 11:25:02 по местному времени:

Dear Vova,

13 Jul 15 21:14, you wrote to me:
VU> Взглянул незамутнённым взглядом... Тебя не смущает оффсет в полторы
VU> секунды? Тебя не смущает

Меня прежде всего смущает, что напротив одного из пиров нарисован "*", что означает "the peer the server is currently synchronizing to." По моему убеждению, если с пиром что-то не так (оффсет большой или другая проблема), звездочки быть не должно. А если звездочка есть, значит пир устраивает и наш стратум никак не должен быть 16.

VU> что 129.73 отстоит от остальных на почти 0.2
VU> секунды? Попробуй остановить ntpd, echo > /твой/ntp.drift, выставить
VU> время ntpdate и запустить ntpd снова. Или -x добавить.

Зачистка ntp.drift не помогает. В запуске ntpdate смысла не вижу, т.к. ntpdsync_onstart="YES" (что подразумевает -g).

VU> <телепат>У тебя это не в виртуалке случаем творится?

Нет, обычная железная машина, хоть и не новая.
CPU: Intel(R) Pentium(R) 4 CPU 3.00GНz (3009.11-MНz 686-class CPU)

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Vova Uralsky написал(а) к Victor Sudakov в Jul 15 23:38:22 по местному времени:

Нello Victor!

14 Jul 15 11:25, Victor Sudakov wrote to Vova Uralsky:

VU>> Взглянул незамутнённым взглядом... Тебя не смущает оффсет в полторы
VU>> секунды? Тебя не смущает
VS> Меня прежде всего смущает, что напротив одного из пиров нарисован
VS> "*", что означает "the peer the server is currently synchronizing
VS> to." По моему убеждению, если с пиром что-то не так (оффсет большой

С чего бы вдруг? У нс есть более или менее здоровая тройка, из которой выбрали одного, с кого в данный момент получаем время. Оффсет -- это не проблема, вот если у пира вдруг резко изменился оффсет, подскочили jitter, dispersion, то есть причины перестать этому пиру доверять. Если такое стряслось со всеми пирами, то стоит перестать доверть себе, что и происходит.

VS> или другая проблема), звездочки быть не должно. А если звездочка
VS> есть, значит пир устраивает и наш стратум никак не должен быть 16.

Поскольку нам до этого пира как до луны, раздавать такое время нет смысла, так что 16 вполне соответствует.

VU>> что 129.73 отстоит от остальных на почти 0.2
VU>> секунды? Попробуй остановить ntpd, echo > /твой/ntp.drift, выставить
VU>> время ntpdate и запустить ntpd снова. Или -x добавить.
VS> Зачистка ntp.drift не помогает. В запуске ntpdate смысла не вижу,
VS> т.к. ntpdsync_onstart="YES" (что подразумевает -g).

Если оно срабатывает, откуда тогда такой безумный оффсет? Если три раза подрят сделать ntpdate к одному и тому же пиру, как будет при этом меняться оффсет? Я бы всё-таки посоветовал сделать то что я предлагал. Если оффсет останется таким же, тогда не в ntp дело.

VU>> <телепат>У тебя это не в виртуалке случаем творится?
VS> Нет, обычная железная машина, хоть и не новая.
VS> CPU: Intel(R) Pentium(R) 4 CPU 3.00GНz (3009.11-MНz 686-class CPU)

На разогнанном железе оно тоже бывает, как впрочем и на гнилом. У меня как-то Ultra-10 вдруг так побежала вперёд, что drift коррекции не хватало и xntpd пару раз в день ресетил время.

Regards,
Vova

--- Msged/BSD 6.2.0

Vova Uralsky написал(а) к Vova Uralsky в Jul 15 16:59:02 по местному времени:

Нello Vova!

15 Jul 15 23:38, Vova Uralsky wrote to Victor Sudakov:

VU> На разогнанном железе оно тоже бывает, как впрочем и на гнилом. У
VU> меня как-то Ultra-10 вдруг так побежала вперёд, что drift коррекции
VU> не хватало и xntpd пару раз в день ресетил время.

Мне тут напомнили, в те времена когда ультра была почти новой у меня так сдох ноут, работавший в то время говнороутером. :-D

Regards,
Vova

--- Msged/BSD 6.2.0