Chris Perl 谈如何保持网络时钟同步

Ron Minsky 引出时钟同步这一话题：让网络中的时钟彼此一致，并与外部参考时间一致。他的嘉宾 Chris Perl 是 Jane Street 的系统工程师，重新设计了公司的同步系统。

Perl 解释，计算机通过振荡器和操作系统的计时机制获得时间。稳定的高质量振荡器可以相当准确地计时，但普通振荡器会随温度等条件变化。繁重的工作负载可能改变机器温度，进而改变时钟速率。

Minsky 指出，同步除了设定当前时间，还意味着修正速率。Perl 说，精确的振荡器可以买到，但价格昂贵。他见过约百万分之 50 的频率修正；当前服务器如果不加修正，每秒可能漂移约 50 至 100 微秒。

Perl 将同步定义为：如果在同一时刻查询，各个时钟报告的时间在指定误差范围内大致一致。Minsky 指出，与外部参考时间一致是另一项要求。

Perl 概述了参考时间的来源：实验室贡献用于确定时间的原子测量值，GPS 卫星再向接收器分发时间信号。网络运营者可以购买带屋顶天线的 GPS 设备；Perl 估计其精度约为 100 纳秒。在这次讨论中，两人将接收器视为外部参考。

金融监管机构可能需要还原不同市场参与者之间的事件顺序。Perl 说，当时钟对齐同一个参考时，时间戳可以比较；但间隔小于误差界限的事件未必能确定先后。同步时钟还有助于关联日志、支持分布式算法，以及服务 Kerberos 等容差宽松得多的协议。

Minsky 问通常如何实现同步。Perl 说，许多系统运行发行版提供的网络时间协议（NTP）守护进程，查询本地或互联网上的服务器。收敛可能需要几分钟，最终同步精度可能在几十毫秒量级。

为了满足更严格的要求，Perl 回到 David Mills 的论文，从基本原理研究 NTP。核心交换使用四个时间戳：客户端记录发送时间，服务器记录接收和发送时间，客户端再记录收到回复的时间。利用这些数据可以估算时钟偏移和网络延迟。

计算假设两个方向的延迟相等。Perl 说，不对称会引入误差：求解方程需要一个假设来关联两个未知的单向延迟。服务器上的两个时间戳则让估算的网络延迟扣除了处理请求所花的时间。

Minsky 指出，计算还假设交换期间时钟速率保持相当稳定。Perl 同意这种误差通常很小，尤其是在应用频率修正的情况下，不过突然的大幅温度变化可能影响修正效果。

Perl 解释，守护进程会采集许多样本，通常来自多个服务器，并过滤异常值。与先前样本相差很大的单次偏移可能是网络排队造成的“爆米花尖峰”。协议会尝试识别称为 false tickers 的不可靠时间源，并选择误差界限较小的较好来源。

守护进程通常通过加快或放慢时钟速率来校正，而不是突然设置时间。Minsky 指出，程序往往假定时间只向前走，如果时钟向后跳变就可能出错。渐进校时（slewing）在保留这一有用性质的同时逐渐消除偏移。

Minsky 回忆测量 Windows 机器时看到的锯齿形变化：时钟逐渐漂移，然后突然跳回同步状态。当时的时间服务配置为直接跳变校时，而非渐进校时。Perl 说，chrony 的默认设置约用 12 秒消除 1 秒误差，最大修正速率可以调整。

Jane Street 的旧系统使用 GPS 设备、NTP 时间服务器和客户端，但没有明确要求或测量最大误差。欧洲金融规则带来了新要求：证明时钟与 UTC 的偏差在 100 微秒以内。

现有系统的精度不够。Perl 说，机器经常偏离数百微秒，误差可能从约 150 微秒波动到 400 或 500 微秒。CPU 活动突然增加可能改变温度和振荡器频率，守护进程需要时间才能作出调整。

寻找解决方案时，Perl 接触到精密时间协议 PTP。常见说法是 NTP 达到毫秒级，而 PTP 能达到微秒级。他想弄清差异究竟来自哪里，而不是直接接受这一说法。

PTP 的消息流程不同，也使用组播，但 Perl 发现其基本计算仍依赖四个时间戳。他总结出三个实际优势：硬件时间戳、更频繁的更新，以及网络交换机的支持。

使用硬件时间戳时，网络接口卡在数据包到达时就记录时间，而不用等待中断、CPU 调度和应用处理。将时间戳采集位置移近网络线路，可以减少不确定性，提高所测路径对称的可能性。

Perl 说，PTP 通常每秒发送一次同步消息，而参考 NTP 守护进程的最短轮询间隔是 8 秒。支持 PTP 的交换机还可以计算自身转发延迟，减少沿途排队带来的不确定性。

不过，NTP 也能提高精度。有些网卡可以为 NTP 数据包或所有数据包生成硬件时间戳；chrony 可以更频繁地轮询，尽管收益会递减。Perl 听到的建议是，如果可能，应避免让交换机参与时间分发。

交换机参与后，责任会分散到多个团队，固件升级也会成为另一种可能导致计时故障的因素。Minsky 补充说，网络配置可能难以管理。Perl 看重 chrony 这样的开源系统，因为可以检查和调试其行为；黑盒越少，越容易调查无法解释的尖峰。

网卡有自己的硬件时钟，主机系统也有时钟。Perl 解释说，Linux PTP 项目中的 phc2sys 等工具可以在网卡和系统之间，或在不同网卡之间传递时间。

PTP 从一个主时钟分发时间，该时钟可以由最佳主时钟算法从多个候选者中选出。组播同步消息让客户端无须单独配置服务器即可监听。延迟请求和响应也是交换的一部分。

Perl 描述了一种默认组播模式：延迟请求和响应也会广播给其他参与者。Minsky 认为其扩展行为可能呈二次方增长。Jane Street 在有限范围内部署 PTP 时采用混合配置：同步消息组播，延迟请求和响应则使用单播。

NTP 可以比较多个时间源并排除 false tickers。Perl 担心 PTP 主时钟对于仍在运行但报时错误的时间源防护较弱。Jane Street 曾看到一台 GPS 设备在维护关机时发出荒谬的时间戳，因此简单的备用故障切换不足以让他放心。

Perl 提醒自己并非最佳主时钟算法的专家，但据他理解，算法依据时钟声称的质量进行选择，而不是独立检测时间源是否报告了严重错误的时间。Minsky 指出，PTP 的精度可能以牺牲 NTP 一些成熟的多源比较防护为代价。

为验证概念，Perl 结合了两种协议。GPS 设备向一层 Linux 机器发送带硬件时间戳的 PTP。这些机器再使用硬件时间戳和交错模式，通过 NTP 向下游客户端提供时间。

发送数据包的硬件时间戳要等数据包离开后才能获得，已经来不及放进该数据包。NTP 交错模式在下一次交换中发送上次传输的时间戳，让接收端用它进行更准确的计算。Perl 说，chrony 已经具备这一功能。

第一跳使用 PTP，是因为 GPS 设备会为 PTP 数据包生成硬件时间戳，却不会为 NTP 数据包生成。每台 Linux 服务器跟随单独的 GPS 设备。下游客户端结合多个 NTP 时间源，既受益于准确的硬件时间戳，也能识别故障来源。

客户端被配置为优先使用本地 NTP 服务器，因为远端时间源会引入更大的潜在误差。它们也查询较远的服务器，以发现本地时间源是否出错。Perl 指出其中的局限：如果两个本地时间源都出错，系统就会陷入困境。

设计的实际效果出乎意料地好，但要证明误差界限，就必须考虑每一项不确定性。Perl 计入无法获得更新时的估计漂移、时间守护进程自身的误差估计、往返延迟的一半、相应的 PTP 不确定性以及 GPS 误差。

Perl 说，将这些因素相加后，在没有特殊情况时，通常可以证明大多数服务器的最坏情况误差约为 35 微秒。专用、安静的计时网络和网络接口可以改善隔离，但也会增加硬件和运维复杂度；团队选择使用现有网络。

没有硬件时间戳的旧客户端在负载很高时可能超出 100 微秒的界限。支持硬件时间戳的新机器面对这种流量时更稳健。Perl 给出的典型数值是：客户端不支持硬件时间戳时约为 35 至 40 微秒，支持时接近 20 微秒。

团队还需要证明合规。它每 10 秒采集一次计时统计数据，写入数据库，再检查哪些系统超出了其精度要求。Perl 承认，任何有限的采样间隔都无法证明持续合规；这样的选择基于一个假设，即有意义的故障通常会持续足够长时间，能够被观察到。

Minsky 问，如果未来规则要求精度达到 10 微秒以内会怎样。Perl 说，现有设计将不够用；一个可能方向是 White Rabbit，它结合了 PTP 相关技术和同步以太网。频率同步（syntonization）使时钟频率一致，却不一定使时间值一致；White Rabbit 利用这一点实现精细得多的同步。

更严格的设计也需要认真处理可靠性和冗余。Perl 设想使用主、备用主时钟，在主时钟异常时通过自动化或操作人员辅助进行切换。对于实际要求，现有技术已经足够；如果误差界限大幅收紧，就值得探索其他方法。