Что такое дисперсия NTP и как я могу ее контролировать?
Мы развертываем серверы Ubuntu 14.04 в изолированных сетях, на которых запущен ntpd 4.2.6p5, настроенный на использование нескольких серверов NTP, предоставленных клиентами (без доступа к pool.ntp.org). Наши немые терминальные клиентские устройства используют старую версию BusyBox (1.00-rc2) и ntpclient 2010 от Ларри Дулиттла.
Эта установка отлично работала в течение многих лет, но недавно мы столкнулись с препятствием с новый покупатель. Они предоставили нам 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
Мои вопросы:
- Что такое дисперсия и что может изменить ее значение?
- Какие команды могут Я бегу, чтобы получить более подробную информацию от серверов NTP?
- Может ли ошибка быть на стороне сервера Ubuntu из-за неправильного
ntp. conf? На самом деле здесь нет ничего особенного. - Изменит ли что-нибудь в этом случае переключение на хрони?
Я вижу некоторую путаницу в ответах здесь. Для начала, ntpclient , по крайней мере, в режиме -s , не действует как полноценный клиент NTP, он только отправляет и принимает один пакет , поэтому есть нет "последних 8 полученных пакетов". На самом деле он вообще не оценивает свою собственную дисперсию.
Вместо этого значение, которое он выводит, представляет собой значение, называемое "корневой дисперсией" (rootdisp) в пакете, возвращаемом сервером, что является оценкой общего количества ошибок / разница между этим сервером и правильным временем. Это вычисляется довольно просто: каждый NTP-сервер получает время либо от внешних часов (например, радио или GPS-приемника), либо от другого NTP-сервера. Если сервер получает время по внешним часам, его корневая дисперсия является расчетной максимальной ошибкой этих часов. Если он получает свое время от другого NTP-сервера, его корневая дисперсия равна корневой дисперсии этого сервера плюс дисперсия, добавляемая сетевым соединением между ними.
Один момент путаницы заключается в том, что при отображении ntpq и chrony дисперсия и корневая дисперсия в секундах, на что люди привыкли смотреть, 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 или что-то еще, что показывает его время.
Просто частичный ответ на вопрос «Что такое дисперсия?»:
Типичный цикл приема-передачи NTP:
client | | server
t1 |------->| t2
t3 |<-------| t4
Это дает два значения: смещение (разница во времени между клиентом и сервером), и задержку (существенно время прохождения по сети) по следующим формулам:
offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)
Клиент выбирает текущее смещение из последних 8 полученных пакетов, выбирая пакет с наименьшей задержкой.
Те же 8 пакетов используются для расчета дисперсии путем выполнения средневзвешенного значения разницы этих 8 смещений с выбранным на последнем этапе, где задержка используется в качестве весового коэффициента, придание большего значения меньшим задержкам. Это мера «разброса» значений, используемая для расчета качества сервера времени, особенно если у вас есть несколько вариантов на выбор.
Согласно этой документации Cisco , " дисперсия , сообщаемая в секундах, является максимальная разница во времени, которая когда-либо наблюдалась между локальными часами и часами сервера ". С серверами ntp, которые не полностью сломаны, никогда не должно быть большого разброса. Единственный возможный сценарий - когда ваш клиент запускает ntp и пока что доступны только его локальные часы. И даже тогда такой высокий разброс, как вы сообщаете, соответствует тому, что часы отстают более чем на две недели .
Этого должно быть достаточно, чтобы убедиться, что локальные часы не слишком сильно отстают в начале (даже пара часов все равно будет приемлемой), либо настроив часы (и даже дату!) в BIOS, либо выполнив один раз ntpdate перед запуском ntpd на клиенте.
Ваша дисперсия и перекос огромны, есть очень большое смещение от локальных часов к этому узлу. Вы должны сравнить смещения с локальной датой и установить часы вручную.
Запустите ntpd и покажите ntpq -p с хоста, использующего все одноранговые узлы. Он выберет лучшие.