«Корневая дисперсия» хрони продолжает неуклонно расти с течением времени, несмотря на точную синхронизацию времени

«Корневая дисперсия» хрони продолжает неуклонно расти с течением времени, несмотря на точную синхронизацию времени

У меня есть система Debian 10, которая использует chronydдля синхронизации своих часов. Конфигурация довольно проста:

pool 2.debian.pool.ntp.org offline iburst

bindaddress ::1
bindaddress 127.0.0.1
bindcmdaddress 127.0.0.1

allow 127
deny

keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
log tracking measurements statistics

maxupdateskew 100.0

directive.
hwclockfile /etc/adjtime

rtcsync
makestep 1 3

Он успешно синхронизирован:

# chronyc sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- time.panq.nl                  2   6     0   83h  -1247us[-1191us] +/-   26ms
^* time.cloudflare.com           3   6     0   83h  +1343ns[  +58us] +/- 2669us
^- metronoom.dmz.cs.uu.nl        2   6     0   83h    -63us[  -63us] +/-   25ms
^- .                             3   6     0   83h  +2171us[+2171us] +/-   64ms

Однако «корневая дисперсия» продолжает неуклонно расти.Что такое дисперсия NTP и как ее контролировать?похоже, это мера максимальной ошибки в часах сервера upstream. Она растет довольно медленно, процесс был запущен около 70 часов или около того, и она составляет 22,5 с. Я знаю по опыту, что она будет расти до chronydперезапуска.

# chronyc tracking
Reference ID    : E1FE1EBE (time.cloudflare.com)
Stratum         : 4
Ref time (UTC)  : Sun Jan 26 23:19:16 2020
System time     : 0.000000005 seconds fast of NTP time
Last offset     : +0.000056495 seconds
RMS offset      : 0.000056495 seconds
Frequency       : 79.909 ppm slow
Residual freq   : +17.510 ppm
Skew            : 56.420 ppm
Root delay      : 0.004632703 seconds
Root dispersion : 22.573289871 seconds
Update interval : 1.6 seconds
Leap status     : Normal

Мне это кажется необычным. У меня есть куча других систем, которые синхронизируют время с сервером Stratum 1, где корневая дисперсия низкая и постоянная. Я не думаю, что я делаю что-то странное в конфигурации, и идея о том, что «максимальная ошибка в восходящих часах» постоянно растет, немного дурно пахнет.

Это нормально?

решение1

Он удачно синхронизирован.

Нет, это не так. Хотя он лучше подстроится под известный дрейф, чем если бы не было никакого NTP.

Reach 0 означает, что пакет не был получен некоторое время. LastRx 83h указывает на то, что последний хороший пакет был три с половиной дня назад.

Маловероятно, что работающее интернет-соединение будет немаршрутизируемым как на Cloudflare, так и на некоторые серверы пула. Проверьте любой брандмауэр на наличие 123/udp.

Связанный контент