Root dispersion过高表明上游NTP源不稳定或路径存在严重抖动、丢包等问题，导致时间同步质量不可靠；需用chronyc sources/sourcestats定位问题源，通过offline或pool+maxdelay配置屏蔽高dispersion源。
chronyc tracking 显示 Root dispersion 过高意味着什么
Root dispersion 是 chrony 用来衡量本地时钟与原始参考时钟（即 stratum 0 源，如原子钟或 GPS）之间累积误差的指标，单位是秒。它不是瞬时偏差，而是整个同步链路上所有中间 NTP 服务器引入的不确定性总和。当 chronyc tracking 输出中 Root dispersion 超过 100ms（常见阈值），尤其达到几百毫秒甚至秒级，说明上游 NTP 源本身不稳定，或路径中存在严重延迟抖动、丢包、非对称路由等问题。
它不直接反映你本机时间不准，但预示着：即使当前 offset 很小，时间质量不可靠；chronyd 可能因 dispersion 过大而拒绝切换到该源，或降低其权重；长期看，同步精度和稳定性都会下降。
如何快速定位是哪个 upstream NTP 源导致 Root dispersion 偏高
chronyc sources -v 和 chronyc sourcestats -v 是关键命令。前者显示每个源的状态（reach、last rx、stratum），后者给出长期统计（offset、std dev、skew、root distance）。重点关注：
-
Root distance 字段（在 sourcestats 中）——这是该源自身上报的 root dispersion，chronyd 会将其纳入本地计算；若某源此项持续 >50ms，基本可判定为问题源
- 对应源的
Stratum 值异常高（如 stratum 3+ 且无合理理由），说明它离权威源太远，中间跳数多、误差易放大
-
Reach 值为 0 或频繁波动，表明网络连通性差，chronyd 实际无法稳定测量其特性
- 对比多个源的
Offset standard deviation：若某源标准差远高于其他（比如 20ms vs 其他 2ms），说明其响应延迟极不稳定，会显著抬高 root distance
Root distance 字段（在 sourcestats 中）——这是该源自身上报的 root dispersion，chronyd 会将其纳入本地计算；若某源此项持续 >50ms，基本可判定为问题源Stratum 值异常高（如 stratum 3+ 且无合理理由），说明它离权威源太远，中间跳数多、误差易放大Reach 值为 0 或频繁波动，表明网络连通性差，chronyd 实际无法稳定测量其特性Offset standard deviation：若某源标准差远高于其他（比如 20ms vs 其他 2ms），说明其响应延迟极不稳定，会显著抬高 root distance别只看 tracking 的最终数值——它取的是所有活动源中最大的 root distance，所以单个坏源就能拖垮整体评估。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
chrony.conf 中屏蔽高 dispersion 上游源的实操配置
不能靠“等它自己恢复”，chronyd 不会自动剔除 root dispersion 高的源，必须人工干预。核心方法是用 offline 或 pool + iburst + maxdelay 组合控制：
- 对已知有问题的 IP 或域名，在
server 行后加 offline，例如：server bad-ntp.example.com offline
—— 这会让 chronyd 保留配置但不发起请求，也不参与同步计算
- 改用
pool 指令替代硬编码 server，并设置 maxdelay（单位秒）限制接受的 root distance 上限：pool pool.ntp.org iburst maxdelay 0.05
—— 此配置下，chronyd 仅将 root distance ≤ 50ms 的 pool 成员视为有效候选
- 避免混用
server 和 pool：混合模式下，server 行不受 maxdelay 约束，仍可能拉高全局 root dispersion
server 行后加 offline，例如：server bad-ntp.example.com offline—— 这会让 chronyd 保留配置但不发起请求，也不参与同步计算
pool 指令替代硬编码 server，并设置 maxdelay（单位秒）限制接受的 root distance 上限：pool pool.ntp.org iburst maxdelay 0.05—— 此配置下，chronyd 仅将 root distance ≤ 50ms 的 pool 成员视为有效候选
server 和 pool：混合模式下，server 行不受 maxdelay 约束，仍可能拉高全局 root dispersion改完记得 sudo chronyc makestep 强制重同步，并用 chronyc tracking 确认 Root dispersion 是否回落到 10–30ms 合理区间。
为什么某些公共 NTP 池（如 pool.ntp.org）偶尔出现 Root dispersion 突增
这不是配置错误，而是底层机制决定的：pool.ntp.org 返回的是 DNS 轮询结果，每次解析可能得到不同地理位置、不同 stratum、不同硬件质量的服务器。其中部分边缘节点可能：
- 运行在虚拟机中，时钟源本身漂移大
- 上联链路拥塞或使用低质量 ISP，导致 NTP 包往返时间（RTT）抖动剧烈
- 未正确配置
ntpd 或 chronyd，遗漏 makestep 或 rtcsync，造成本地 clock drift 积累
- 被大量客户端轮询，资源不足，响应延迟升高
ntpd 或 chronyd，遗漏 makestep 或 rtcsync，造成本地 clock drift 积累因此，单纯换一个 pool 域名没用；真正有效的做法是限定 pool 解析范围（如指定国家码子域 cn.pool.ntp.org）、配合 maxdelay 过滤、并定期用 sourcestats 审计实际接入节点的质量。分散风险比依赖单一“看起来权威”的源更可靠。
