服务器收到的时间戳即使如实记录了时间，也仍会有把自身时钟校错的风险，因为应答在网络上传输需要时间。即便某次校正准确，也仍会遇到机器时钟再次漂移的情况。理解 chrony，要沿着测量、估算和校正这几个环节看下去：它如何把这些工作分开，每一步又留下什么问题，交给下一步处理。[1][2]

后台进程 chronyd 可以依据网络时间服务器或直接连接的参考时钟来同步计算机时间，也可以为其他计算机授时。配套工具 chronyc 则展示守护进程当前的估算和运行状态。本文以 4.7 版手册为固定参照。[1][4]

一次报文往返带来四个时间戳

在一次基本的网络时间协议（NTP）交互中，客户端记录发出请求和收到应答的时间，服务器给出收到请求和发出应答的时间。有了这四个时间戳，客户端就能从总耗时中减去服务器的处理时间，得到网络往返延迟，同时估算两端时钟的偏移量。[2]

问题在于去程和回程各自花了多久。设想一个简化的例子：时间戳完全准确，两端时钟也已一致。请求用 2 毫秒到达服务器，应答用 8 毫秒返回，按通常的 NTP 公式计算，服务器时钟会被估算为比客户端慢 3 毫秒，恰好是两程耗时之差的一半。这组数值仅用于演示协议公式的计算，未涉及 chrony 的实测结果：往返路径耗时不均，也会表现为时钟偏差。[2]

因此，chrony 在评估偏移量的同时也评估延迟。它为测量值赋予权重，并可剔除延迟异常的应答；maxdelay 则明确设定往返延迟的上限。[3] 一份迟到的应答，在用于校正时钟之前，要先经过评估。

在两次应答之间掌握时钟的漂移规律

连续测量能够揭示单次交互无法看出的变化：时钟是否一直在走快或走慢。在 chronyc sourcestats -v 的输出中，NP 表示保留的样本数，Span 表示这些样本覆盖的时间跨度。chrony 对这些样本做线性拟合，估算偏移量和漂移。拟合效果变差时，它可以舍弃较早的样本，再次拟合。[4]

以振荡器误差为百万分之 20 的情况为例，一小时就会积累 72 毫秒的偏差：百万分之 20 乘以 3,600 秒。校正昨天的偏移量之后，走时速率的误差仍在，到了明天又会积累出新的偏差。掌握这个速率，守护进程就能在两次测量之间作出补偿。

driftfile 指令把估算的走时速率及其不确定度保存下来，供重启后使用。下一次运行时，即使新的观测数据尚未积累充分，chrony 也已有一个起始估计值。[3] 项目的常见问题解答还建议避免定期运行一次性校时命令 chronyd -q 来替代持续运行的守护进程：这种做法会让时间跳变，时钟频率的误差则依然保留。[5]

多个时间源带来另一类证据。常见问题解答建议至少使用三或四台合适的服务器，让 chrony 能够识别错误时间并合并测量结果。[5] 从同一台服务器收到更多应答，可以积累与它之间的测量记录；观测其他服务器，则能看出各时间源之间的分歧。

估算的时间与显示的时间

chronyc tracking 的输出揭示了一个重要区别：chronyd 维护着一个软件 NTP 时钟，系统时钟则跟随它调整。System time 字段报告两者之间尚余的差值。守护进程已经得到准确估计时，应用程序读取的系统时钟仍会处于追赶这一估计值的过程中。[4]

通常采用的校正方式是 slew（渐进校正），即暂时改变系统时钟前进的速率；step（跳变校正）则立即改动时钟读数。下面这段配置示例给出了具体的校正策略：

makestep 1.0 3

这项配置允许在 chronyd 启动后的前 3 次时钟更新中，对超过 1 秒的误差采用跳变校正。其中的限制按更新次数计算，与经过多少秒无关。重启守护进程后，允许跳变的更新次数会重新计算，因此配置需要符合应用程序对时间跳变的容忍程度。[3]

这是一项会影响运行的选择。渐进校正会让残余误差延续一段时间，立即校正则会造成时间不连续。对小型运维团队来说，先明确依赖校时的服务何时可以启动，比照抄一个适用时机尚未弄清的跳变阈值更有用。

chronyc waitsync 60 0.01 最多可以等待约十分钟，直到同步完成且剩余校正量降到 10 毫秒以下。命令成功，只能说明 chrony 报告的状态符合条件；绝对精度还需要外部验证。[4]

测量仍需独立验证

Facebook 工程师在 2020 年 3 月发表的 chrony 测试文章，让这一差别有了具体呈现。他们把守护进程的估计值与实际脉冲测量结果、外部实验室仪器的读数作了对照。结果说明，报告的偏移量很小，实际测得的误差仍可大得多。他们还测试了硬件时间戳，让报文的时间记录位置更靠近网络接口。这些结果来自他们受控的数据中心环境，对所有网络作出性能承诺超出了这项测试的范围。[6]

团队在排查普通服务器的时间戳问题时，首先要看可用时间源是否一致、走时速率的估计是否已经稳定，以及还剩多少校正量。如果团队承诺为实验或分布式基础设施严格限定时间误差，就需要更多测量专业知识，以及独立检验这些误差限值的手段。出错的后果越大，验证所需达到的要求也越高。

对 chrony 的独立审视还涉及另一个方面。LWN 在 2017 年 10 月报道 NTP 安全审计时，转述了审查者对 chrony 功能集精简集中的肯定。[7] 这份历史评估讨论的是软件安全，具体部署的校时精度仍需另行验证。

这套架构的价值，正在于每个阶段都可以检查。报文延迟、走时速率估计不稳定、系统时钟仍在校正，这几种情况各有各的排查方向。分开查看这些环节，运维人员就能把“时钟不准”落实到具体的问题位置。

来源

1. chrony 项目，chronyd(8)，4.7 版——守护进程的职责与运行模式。
2. David Mills 及合作者，RFC 5905，2010 年 6 月，第 8 节——NTP 时间戳交换、偏移量和往返延迟的计算公式。
3. chrony 项目，chrony.conf(5)，4.7 版——测量延迟、driftfile 与 makestep 配置。
4. chrony 项目，chronyc(1)，4.7 版——sourcestats、tracking、软件 NTP 时钟与 waitsync。
5. chrony 项目，常见问题解答——第 2.7 和 2.8 节，关于时间源选择与一次性同步；核查日期：2026 年 10 月 7 日。
6. Oleg Obleukhov，《NTP：在 Facebook 的规模下建设更准确的时间服务》，2020 年 3 月 18 日——独立的物理测量与硬件时间戳实验。
7. Jonathan Corbet，《三种 NTP 实现的安全审查》，LWN，2017 年 10 月 1 日——当时对安全审查的独立报道。
8. NIST，《F2 原子钟》，2014 年 4 月 3 日，编号 14PML013——Steve Jefferts 和 Tom Heavner 与 NIST-F2 的合影；图片来源：NIST。