Root delay异常大（>100ms）或Root dispersion过高（>1s）通常源于上游NTP服务器链路或服务问题，而非本地配置错误；需用chronyc sources/sourcestats验证，并优选地理邻近、stratum较低的可靠上游源。

chronyc tracking 显示 Root delay 异常大或 dispersion 高的上游问题 第1张

当 chronyc tracking 显示 Root delay 异常大（例如 >100ms）或 Root dispersion 过高（例如 >1s），通常说明 chrony 与上游 NTP 服务器之间的同步质量严重下降，根源大概率在上游链路或上游服务本身，而非本地配置错误。

Root delay 高的常见上游原因

Root delay 表示从本机到 stratum-1（或当前参考源）服务器的往返网络延迟估算值。该值持续偏高，往往不是本地网络问题，而是上游环节导致：

  • 上游服务器本身负载过高，响应 NTP 请求变慢；
  • 上游服务器位于跨洲际、高丢包或拥塞链路上（如某些公共池服务器在亚洲访问欧美节点）；
  • 上游是中继型 NTP 服务（stratum >1），中间跳数多，每跳累积延迟和抖动；
  • 上游启用了速率限制（rate limiting）或防火墙策略，人为拉长响应间隔。

Root dispersion 高反映时间不确定性加剧

Root dispersion 衡量的是当前参考源的时间可信度衰减程度，本质是上游时钟漂移 + 网络延迟抖动的累积误差。该值升高意味着：

  • 上游服务器自身时钟稳定性差（未接 GPS/原子钟，仅靠软件校准）；
  • 上游与它的上层源之间已存在高延迟或高抖动，误差沿层级向下传播；
  • 网络路径存在严重不对称延迟（asymmetric routing），chrony 的延迟估算失真；
  • 上游频繁切换参考源（如 GPS 失锁后切到网络源），导致 dispersion 突增。

如何快速定位是否为上游问题

不依赖猜测，用 chrony 内置命令交叉验证：

  • 运行 chronyc sources -v：观察各上游的 MS（测量状态）、NR（正常响应次数）和 delay 列。若多个源都显示高 delay 或 ? 状态，基本可判定是网络或上游问题；
  • 执行 chronyc sourcestats -v：重点关注 Offset 标准差（std dev）和 Skew。若 std dev > 5ms 或 skew > 100ppm，说明该源时间波动剧烈，不适合作为主要参考；
  • 临时更换为可信 stratum-1 源测试（如 time.apple.com、clock.isc.org 或本地局域网 NTP 服务器），对比 chronyc tracking 输出变化。

应对建议：优化上游选择策略

chrony 默认使用 pool 域名（如 pool.ntp.org），但这类 DNS 轮询机制无法保证每次解析到低延迟、高质量节点。更稳妥的做法是：

  • 在 /etc/chrony.conf 中避免直接使用 pool，改用明确的、地理邻近的 stratum-1 或 stratum-2 服务器列表；
  • 添加 offline 或 iburst 参数提升连接鲁棒性，例如：
    server ntp.example.org iburst minpoll 4 maxpoll 10；
  • 启用 makestep 1.0 -1 防止长时间失步后缓慢追赶，但需配合 rtcsync 保障硬件时钟同步；
  • 对关键系统，优先接入组织内部或云厂商提供的专用 NTP 服务（如 AWS Time Sync、阿里云 NTP），延迟和 dispersion 通常稳定在毫秒级。