摘要

  • RIPE Atlas 固件 5130 说明，5120 把往返时延的一半写成了 NTP 时钟偏移量；5120 上报的 offset 不正确，但 rtt 不受这次回归影响。
  • 8 月 31 日 03:12 UTC 的无缓存 API 快照中，2721 个探针记录同时满足 Connected 和 firmware_version=5120；5130 为 2350 个，全部 Connected 记录为 14680 个。
  • 2721 不是错误测量条数，也不是用户数。好消息是，NTP 原始结果本来就带有 fw、prb_id 和时间戳，使用者可以识别并排除 5120 结果。
  • 仍缺的是机器可发现的结果勘误：它要说明坏的是哪个字段、哪些字段仍有效、每个探针的影响起止、应排除还是重算，以及哪一版勘误被采用。版本迁移进度应另记一本账。

数字在变，事实边界不能跟着漂移

本轮研究第一次查询公开 API 时，5120 的 Connected 记录为 2725。几分钟后正式冻结来源时，数字变成 2721。这个变化没有被写成增长、下降或修复速度，因为两次瞬时观察不足以构成趋势。

冻结快照的三个数字是：5120 为 2721，5130 为 2350，全部 Connected 为 14680。2721 约占总数的 18.5%。API 返回样本中的 status=1 明确显示名称为 Connected。

这些数字只描述探针记录的当时状态。它们没有说明 2721 个探针是否在该时间段执行了 NTP 测量，也没有说明有多少独立宿主、运营者或研究项目。一个组织可能维护多个探针；一台在线探针也可能没有生成任何相关结果。不能把版本清单直接当成错误结果清单。

但版本清单仍然重要。5130 发布十九天后，公开系统里仍有数千个在线记录报告 5120。发布修复、完成部署、标记历史数据是三个不同的状态迁移，任何一个完成都不能替另外两个结案。

第一次修复没有回到正确答案

RIPE NCC 的 issue 130 把这段过程保存得比一般发行说明更完整。

2025 年 7 月 11 日，最初问题被描述为符号相反：NTP 交换的四个时间戳本身没有错，但计算时的顺序与 RFC 相反，因而得到了反号的时钟偏移量。

2025 年 10 月 29 日发布的软件探针固件 5120 把“修复 NTP offset 计算”列入改动，并注明该发行只适用于软件探针。当天的维护者评论给出了 commit，宣布问题已经修复。

2026 年 7 月 23 日，维护者在测试 5130 时重新打开 issue，称那次改动可能没有修好，甚至可能“made it worse”。新补丁直接按 RFC 5905 的四时间戳公式，以 64 位定点值分别计算 RTT 与 offset。

8 月 12 日，5130 的正式说明 给出了新的错误形态：5120 上报的不是时钟偏移量，而是 RTT 的一半。说明还单独确认，5120 的 offset 不正确，RTT 不受影响。issue 随 5130 和 commit 197b599a7faa811d97ebd273078be176842264bb 关闭。

因此，不能把整个时期笼统写成“offset 正负号错了”。旧缺陷、5120 的修复尝试、5120 引入的半 RTT 回归，是三种可区分状态。若日后允许重算，规则必须知道一条结果究竟由哪一状态生成。

原始结果已经留下了版本指纹

RIPE Atlas 的结果格式文档 为纠错保留了关键条件。

每条 NTP 结果带有 fw，表示生成结果的固件版本；有 prb_id 和 Unix timestamp；内部的 result 把 offset 与 rtt 分开，并保留 origin、receive、transmit、final 四个时间戳。

这意味着，知道 5130 警告的使用者可以排除 fw=5120 的 offset 行，而无需识别探针宿主。文章也不能声称数据完全不可定位，更不能把同一探针的 ping、traceroute、DNS 等其他测量一并判错。官方声明只圈定 NTP offset，并明确排除 RTT。

不过，能筛选不等于已经有校正规则。自动化客户端从哪里发现这份警告？它如何知道当前警告的版本？某个探针从哪一条结果开始进入 5120，又从哪一条离开？究竟应当排除、重算还是以新结果替换？目前检查到的发行页、issue、结果格式与探针 API 没有把这些答案合成一个可机器连接的对象。

这也解释了为什么“文档已经写明”仍不是数据产品的终点。人在看到 5130 页面后可以回到查询脚本里手工增加条件；无人值守的采集器、已经封存的研究快照和只保存结果文件的第三方仓库却不会自动获得这段语境。若警告没有稳定标识和版本，团队只能把自然语言摘录写进各自的运行手册，随后很难证明两个过滤器遵循的是同一条规则。

一个合格的发现入口还应允许按产品、结果类型和固件查询，而不是要求使用者先猜中一篇发行说明。这样，旧数据在被重新打开时，也能主动找到后来生效的质量状态。

发现能力越靠近结果接口，纠错越不依赖偶然读到一则新闻。

在 RIPE NCC 发布权威重算合同之前，排除是证据边界最稳妥的选择。不能仅凭“5120 上报半 RTT”就把所有 offset 乘一个常数；错误行、重试、不同架构和版本切换边界仍要受规则约束。

两本账分别回答现在与过去

运行版本账应记录：抓取时间、Connected 总数、各固件数量、口径和修订。它告诉维护者迁移是否推进，但不回答一共有多少错误 NTP 结果。

结果勘误账应有稳定 ID 与版本，绑定 RIPE Atlas NTP 结果模式、固件 5120、受影响的 result[].offset、明确不受影响的 rtt、按固件/探针/时间选择结果的方法、每个流的实际起止、要求的处理动作、5130 与修复 commit，以及通知与修订历史。

两个日期不能替代实际起止。2025 年 10 月 29 日是 5120 发布日，不是所有软件探针的安装日；2026 年 8 月 12 日是 5130 发布日，也不是所有探针的升级日。31 日仍有 2721 个 Connected 记录，正说明发行日与运行状态之间存在时差。

把两本账合在一起会造成错误结案：当 5120 数量降到很低时，历史数据似乎也“修好了”。分开后，即使探针已升级，旧结果仍可以带明确质量状态；即使探针尚未升级，新的 5120 行也能按权威规则及时隔离。

不改写原始证据

勘误不应静默覆盖原始结果。原始行证明某个版本当时输出了什么。校正视图或过滤视图应保留原始字节，并附上采用的勘误 ID、版本、动作和生成时间。

这样也能保持分布式责任。RIPE NCC 控制结果字段含义、发行谱系和权威勘误；探针宿主控制安装；测量所有者控制任务与用途；下游研究者和运营者控制自己的缓存与重处理。勘误是共同的连接凭据，不是把所有控制权收回中心。

5130 已经把错误说得足够坦率，fw 也把版本留在数据里。现在需要做的是让“这条数据还能怎样用”像数据本身一样可查询、可固定、可携带。

来源