Root dispersion过高表示从权威时间源到本地时钟的累计最大误差估计值过大（通常＞0.1s），说明NTP同步链路不可靠，可能导致chronyd拒绝校准或降权该源。
chronyc tracking 显示 Root dispersion 过高意味着什么
Root dispersion 是 chrony 计算出的“从权威时间源（root）到本地时钟”累计的最大误差估计值，单位是秒。它不是瞬时偏差，而是路径上所有 NTP 跳数（包括上游服务器自身时钟质量、网络抖动、处理延迟等）叠加后的保守上限。当 chronyc tracking 输出中该值持续 > 0.1s（尤其 > 1s），说明 chrony 认为当前同步链路不可靠，可能拒绝校准或降权该源。
常见现象包括：Leap status: Not synchronised、System time wrong by … 报错、chronyd 日志频繁打印 Selected source … is too inaccurate。
如何用 chronyc 快速定位问题上游
chrony 不会直接告诉你哪个上游导致了高 Root dispersion，但可通过组合命令缩小范围：
运行
chronyc sources -v查看每个源的详细状态，重点关注MS（Mode/State）、NR（NTP Reachability）、PPM（频率偏移）和Offset（当前偏差）。若某源NR长期为 0 或极低（如 000），说明它根本没应答，但其Root dispersion可能仍被计入（尤其配置了pool且未启用iburst或超时过长）运行
chronyc sourcestats -v，检查各源的RMSE（均方根误差）和Offset SD（偏差标准差）。高RMSE+ 高Root dispersion往往指向该源本身时钟漂移大或网络路径不稳定注意：chrony 默认对每个源独立计算
Root dispersion，但最终chronyc tracking显示的是所有可用源中最大值。所以哪怕只有一个源异常，整体会被拖累
chrony.conf 中影响 Root dispersion 评估的关键配置
chrony 对 Root dispersion 的累积和裁剪受以下参数控制，改错反而会掩盖真实问题：
makestep：仅控制是否允许大步调时，不影响Root dispersion计算逻辑rtcsync和hwclock：与硬件时钟同步有关，不参与 dispersion 累积-
真正关键的是：
offset、minpoll/maxpoll、polltarget，以及是否启用iburst- 若上游响应慢（如公共 pool 域名解析到高延迟节点），
minpoll 6（64 秒）可能导致首次同步耗时过长，期间Root dispersion持续增长 -
iburst能在启动时快速建立初始同步，显著降低初始 dispersion；没加它，chrony 可能花数分钟才拿到第一个有效测量 -
polltarget 4（默认）配合网络波动大的源，容易因丢包触发重试，间接拉高 dispersion 估算
- 若上游响应慢（如公共 pool 域名解析到高延迟节点），
建议配置片段：
server ntp.example.com iburst minpoll 4 maxpoll 6 # 避免使用无约束的 pool 域名，优先指定已知稳定的单个 IP 或 FQDN
排除上游 NTP 服务器自身问题的实操步骤
不要假设“只要能 ping 通、能收到 NTP 包，就一定可用”。很多公共 NTP 服务存在隐性缺陷：
- 使用
ntpdate -q或chronyc -a activity确认 chronyd 是否真在跟目标通信（At least one working source才可信） - 直接用
chronyc -a makestep强制校准后，再跑chronyc tracking—— 如果Root dispersion瞬间回落，说明之前是本地积累误差，而非上游问题 - 换一个已知可靠的上游（例如
time.cloudflare.com或内网 NTP 服务器）对比测试；若新源 dispersion 正常，基本锁定原上游质量差 - 检查上游是否返回了异常的
stratum（如 stratum 16 表示 unsynchronized）或leap indicator（如 11 表示告警），这些都会被 chrony 解析并放大 dispersion
真正难处理的是：上游服务器本身 stratum 合理、响应正常，但内部晶振老化或未接入 PPS/GPS，导致长期 drift 偏高 —— 这种情况 chrony 会如实反映，你只能换源，没有绕过办法。
