Что такое дисперсия 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

Мои вопросы:

1. Что такое дисперсия и что может изменить ее значение?
2. Какие команды можно запустить, чтобы получить больше подробностей от NTP-серверов?
3. Может ли ошибка лежать на стороне сервера Ubuntu, с ненадлежащим ntp.conf? Там действительно нет ничего особенного.
4. Изменит ли что-нибудь переход в хронологию в этом случае?

Я вижу некоторую путаницу в ответах здесь. Для начала, 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, и в этом случае неверная конфигурация заключается просто в том, что он рекламирует LOCLrefid; это должно быть отменено, например, GPSили что-то, что обеспечивает его время.

Просто частичный ответ на вопрос «Что такое дисперсия?»:

Типичное путешествие NTP туда и обратно:

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на клиенте.