Я щойно випадково помітив, що у одного з моїх комутаторів Cisco 4500 годинник йде не так: він відстає більше ніж на 2 хвилини, незважаючи на функціональний ntp. На мою думку, навіть одну секунду не слід вважати прийнятною для залучених систем. Крім того, я б не помітив різницю від діагностики, якби не порівнював її з простою настінною годинником.
Деякі деталі
Ось ntp інформація для деяких моїх хостів (10.0.99.1, 10.0.99.2, 10.0.1.119, 10.0.99.241), які частково посилаються один на одного для резервного копіювання, але в основному все це повинно бути синхронізовано з 10.0.0.1, що знову тягне час ззовні. Тому розбіжність у часі не може бути результатом різних джерел часу. Оскільки спостереження зробили мене дещо параноїдальним, "має правильний час" у таких засобах: show clock(або date) створив висновок, який відповідає моєму настінному годиннику та моєму локальному системному годиннику (що добре за http://time.is ) з помилка, звичайно, менше 1 секунди (точність мене, коли я натискаю ENTER під час перегляду мого місцевого годинника)
10.0.1.119 (Ubuntu) має правильний час
$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
+10.0.99.1 10.0.0.1 3 u 855 1024 377 0.904 -2.658 0.113
*10.0.0.1 130.149.17.8 2 u 266 1024 377 0.253 0.909 0.127
10.0.99.241 (Cisco 2960) має правильний час
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.99.1 10.0.0.1 3 28 64 377 1.462 85.288 19.758
+~10.0.99.2 10.0.1.119 4 29 64 377 1.297 83.515 5.369
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.2 (Cico 4500) має правильний час
#sho ntp associations
address ref clock st when poll reach delay offset disp
+~10.0.99.1 10.0.0.1 3 6 1024 111 1.148 -1.618 42.875
*~10.0.1.119 10.0.0.1 3 31 1024 377 0.043 1.687 1.064
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
10.0.99.1 (Cisco 4500) відстає приблизно на 2 хвилини 6 секунд
#sho ntp associations
address ref clock st when poll reach delay offset disp
*~10.0.0.1 130.149.17.8 2 274 1024 377 15.625 3.681 30.403
+~10.0.99.2 10.0.1.119 4 415 1024 376 15.625 0.855 33.276
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
#sho ntp status
Clock is synchronized, stratum 3, reference is 10.0.0.1
nominal freq is 250.0000 Hz, actual freq is 249.9988 Hz, precision is 2**6
reference time is DAD8B428.54C6BAEA (20:36:24.331 MESZ Sat May 7 2016)
clock offset is 3.6818 msec, root delay is 32.80 msec
root dispersion is 71.74 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000004720 s/s
system poll interval is 1024, last update was 683 sec ago.
Запитання
- Чому 10.0.99.1 так далеко?
- Як правильні системи, які синхронізуються до 10.0.99.1?
- Як слід дізнатися з результатів
sho ntp status10.0.99.1, що годинник насправді повністю синхронізований (порівняно з усіма хостами та референтними годинниками, згаданими вsho ntp asso)? Для мене результат виглядає як дуже витончений "я цілком задоволений".
EDIT: За попитом населення, вихідsho clock detail
10.0.99.1
#sho clock detail
13:06:38.605 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.99.2
#sho clock detail
13:10:54.083 MESZ Tue May 10 2016
Time source is NTP
Summer time starts 02:00:00 MEZ Sun Mar 27 2016
Summer time ends 03:00:00 MESZ Sun Oct 30 2016
10.0.0.1). Але я не думаю, що жодне з моїх спостережень не може прямо пояснити причину вашої поточної проблеми.