Що таке дисперсія NTP і як я можу це контролювати?

Ми розгортаємо сервери Ubuntu 14.04 в ізольованих мережах, на яких працює ntpd 4.2.6p5, налаштований на використання декількох серверів NTP за наданими клієнтами (немає доступу до pool.ntp.org). Наші німі термінальні клієнтські пристрої мають стару версію BusyBox (1.00-rc2) та ntpclient 2010 від Larry Doolittle.

Ця установка працювала чудово протягом багатьох років, але нещодавно ми потрапили в блокпост із новим замовником. Вони надали нам 5 власних адрес NTP-серверів, які, здається, працюють чудово самостійно, наскільки ntpdate-debianце стосується сервера Linux. З боку BusyBox, однак, ntpclientскаржиться на "Дисперсія зависока". З виводу налагодження ntpclientотримує "1217163.1" з сервера NTP, але максимальне значення, яке він підтримує, абсолютно (65536).

$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
  -c probe_count 1
  -d (debug)     1
  -g goodness    0
  -h hostname    10.17.162.250
  -i interval    15
  -l live        0
  -p local_port  0
  -q min_delay   800.000000
  -s set_clock   1
  -x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0  VN=3  Mode=4  Stratum=4  Poll=4  Precision=-20
Delay=60745.2  Dispersion=1346801.8  Refid=10.31.10.21
Reference 3668859928.942079
(sent)    3668859928.708371
Originate 3668859928.708371
Receive   3668859928.963271
Transmit  3668859928.963369
Our recv  3668859928.708371
Total elapsed:      0.00
Server stall:      93.09
Slop:             -93.09
Skew:          255443.94
Frequency:             0
 day   second     elapsed    stall     skew  dispersion  freq
42463 56728.708  rejected packet: abs(DISP)>65536

Це всі пристрої в одній локальній мережі, відверто кажучи, я вражений. Аґаст навіть.

Ось ntpq -pnвихід із сервера Ubuntu 14.04:

user@host:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 1025   64    0    0.000    0.000   0.000
 10.17.162.249   10.17.6.10       5 u   23 1024   37    0.865  1381.07 697.260
 10.31.10.22     .LOCL.           1 u 1044 1024   17   29.586  -838.06 397.342
 10.17.6.10      10.31.10.21      4 u 1065 1024   17    0.366  105.245 402.999
*10.31.10.21     132.246.11.238   3 u    5 1024   37   29.418  794.292 616.796
 10.17.6.11      10.31.10.21      4 u 1038 1024   17    0.408  120.030 381.058

Мої запитання:

1. Що таке дисперсія і що може змінити її значення?
2. Які команди я можу запустити, щоб отримати більш детальну інформацію про сервери NTP?
3. Чи може помилка лежати на стороні сервера Ubuntu з неправильним ntp.conf? Справді немає нічого особливого.
4. Чи змінює щось перехід на хронію в цьому випадку?

Я бачу певну плутанину у відповідях тут. Для початківців, ntpclientпринаймні в -sрежимі, він не діє як повний клієнт NTP, він надсилає та отримує лише один пакет , тому немає "останніх 8 пакетів, отриманих". Це насправді взагалі не оцінює власну дисперсію.

Натомість значення, яке він друкує, - це значення, яке називається "кореневою дисперсією" (rootdisp) у пакеті, поверненому сервером, що є оцінкою загальної кількості помилок / дисперсії між цим сервером та правильним часом. Спосіб цього обчислення досить простий: кожен сервер NTP отримує свій час від зовнішнього годинника (наприклад, радіо чи GPS-приймача), або від іншого сервера NTP. Якщо сервер отримує свій час від зовнішнього годинника, його коренева дисперсія - це приблизна максимальна помилка цього годинника. Якщо він отримує свій час з іншого сервера NTP, його кореневою дисперсією є коренева дисперсія сервера плюс дисперсія, додана мережевим зв’язком між ними.

Один з моментів плутанини тут полягає в тому, що, хоча ntpq і хронічні дисперсії та кореневі дисперсії відображаються за секунди, на що люди звикли дивитись, ntpclient відображає це в мікросекундах . Незважаючи на це, значення 1217163 все ще досить високе. Хороший сервер NTP знає час протягом декількох мілісекунд; поганий протягом кількох десятків чи сотень мілісекунд. Ваш говорить вам, що його час можна довіряти лише за +/– 1,2 секунди.

Ви насправді можете отримати ntpclient для синхронізації на цьому сервері, будь-ласка, передавши параметр -x 0або -t(залежно від версії ntpclient), який відключає перевірку стану безпеки NTP. Якщо вам потрібен лише приблизно точний час (до декількох секунд), це може бути досить добре. Однак, ntpclient досить розумно відмовляється синхронізуватися на такий поганий сервер. Ваш ntpqвихід на машині ubuntu демонструє тремтіння сотень мілісекунд для всіх його серверів, навіть якщо вони мають малу затримку, що вказує або на дуже ненадійну мережу, змову всіх серверів на надання нестабільного часу, або на базовий проблема хронометражу на самому сервері.

Мене також хвилює те, що сервер 10.31.10.22 рекламує повернення LOCL(недисциплінований локальний годинник), але має прошарок 1. Зазвичай локальний годинник розміщується до шару 10, щоб він використовувався лише як джерело синхронізації в останню чергу. щоб стадо не розпливалося. Або 10.31.10.22 неправильно налаштовано та надає поганий час для решти мережі, або його привласнюють до гарного часу якоюсь програмою, що не перебуває під контролем NTP LOCL. це має бути скасовано, наприклад, для того, GPSщоб забезпечити його час.

Лише часткова відповідь "Що таке дисперсія?":

Типовий туди-назад:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

Це дає два значення, зміщення (різниця у часі між клієнтом та сервером) та затримка (важливо час в дорозі мережі) за такими формулами:

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

Клієнт вибирає поточне зміщення з останніх 8 отриманих пакетів, вибираючи той з найменшою затримкою.

Ті ж 8 пакетів використовуються для обчислення дисперсії , роблячи середньозважене значення різниці цих 8 зсувів до вибраного на останньому кроці, де затримка використовується як коефіцієнт зважування, надаючи більшу вагу меншим затримкам. Це показник "поширення" значень і використовується для обчислення якості сервера часу, особливо якщо у вас є кілька варіантів.

Ваша дисперсія та перекос величезні, з місцевого годинника до цього однолітка дуже велике зміщення. Слід порівняти компенсації з місцевими dateта встановити годинник вручну.

Запустіть ntpd і покажіть ntpq -pвід хоста, використовуючи всіх однолітків. Він вибере кращих.

Згідно з цією документацією на cisco , " дисперсія , яка повідомляється за секунди, - це максимальна різниця в тактовому часі, яка коли-небудь спостерігалася між локальним та серверним годинником". З ntp-серверами, які не повністю розбиті, висока дисперсія ніколи не повинна відбуватися. Єдиний здійсненний сценарій - це коли ваш клієнт вводить ntp і поки що доступний лише його локальний годинник. І навіть тоді дисперсія настільки висока, як ви повідомляєте, відповідає годинникам, які вимикаються більше ніж на два тижні .

Це повинно бути достатнім для того, щоб локальний годинник не був занадто заздалегідь (навіть пару годин все одно було б прийнятним), або регулюючи годинник (і навіть дату!) В BIOS, або видаючи ntpdateодин раз перед запуском ntpdна клієнта.