root delay异常大（>100ms）或root dispersion过高（>1s）通常源于上游ntp服务器链路或服务问题，而非本地配置错误；需用chronyc sources/sourcestats验证，并优选地理邻近、stratum较低的可靠上游源。
当 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 通常稳定在毫秒级。
