我有一个 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 分散以及如何控制它?这似乎是上游服务器时钟最大误差的量度。它的上升非常缓慢,这个过程已经持续了大约 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 服务器同步时间,其中根分散度低且恒定。我认为我在配置上没有做任何奇怪的事情,并且“上游时钟中的最大误差”稳步上升的想法闻起来有点不对劲。
这是正常的吗?
不它不是。虽然,它会比不运行任何 NTP 更好地调整已知漂移。
达到 0 意味着它有一段时间没有收到数据包。LastRx 83h 表示最后一个好的数据包是三天半前。
对于 Cloudflare 和某些池服务器而言,正常工作的 Internet 连接不太可能无法路由。检查任何防火墙的 123/udp。