learn

为什么 TSN 需要共同时间

从调度窗口、跨设备测量和故障复盘三个场景理解共同时间为什么是 TSN 的坐标系。

第三章：共同时间核心前提IEEE 802.1ASgPTP12 分钟

本节学习目标

共同时间调度坐标跨设备时间戳日志复盘

普通以太网里，每台设备可以按自己的本地时钟工作。交换机只要把帧收进来、排队、转发出去，并不需要和其他交换机约定“现在到底是几微秒”。但 TSN 一旦进入时间感知调度，就不能只靠各自本地时钟了。

假设有两台交换机都配置了“在 1000us 打开关键队列 gate”。如果第一台交换机的 1000us 比第二台交换机早 20us，那么关键帧在第一跳刚好进入窗口，到了第二跳却可能撞上还没打开的窗口。这时配置文件看起来一致，现场行为却不是同一套时间表。

共同时间解决的是坐标一致性问题。它让网络里的设备对“这个窗口什么时候开始”“这个时间戳代表哪个全局时刻”“这次迟到发生在哪一跳之前”有共同解释。

很多人第一次听到时间同步，会把它理解成“所有设备显示同一个时间”。这只是表象。TSN 更关心的是事件排序和时间间隔：某个帧何时进入交换机，何时等待，何时出端口，何时到达下一跳。

如果每台设备的时间坐标不同，跨设备抓包就像把几张没有比例尺的地图拼在一起。你看到了发送时间戳和接收时间戳，却无法判断两者差值究竟是网络延迟，还是两个设备时钟本来就相差 30us。

第一类是调度。Qbv/TAS 的 gate 是按时间开关的，多个设备的窗口还要沿路径接力。没有共同时间，每台设备都可能“正确地执行自己的本地表”，但整条路径合起来是错位的。

第二类是测量。TSN 工程里经常要证明端到端延迟、每跳驻留时间、抖动边界。如果时间戳来自不同设备，就必须知道这些设备的时钟差距。否则你很难判断 8us 的延迟变化是网络行为，还是时间戳坐标没对齐。

第三类是故障复盘。现场出现偶发迟到时，应用日志、交换机日志、抓包文件、PTP 状态变化往往来自不同设备。共同时间让这些事件能排成同一条时间线，从而判断是同步失稳、排队突发、配置漂移还是链路故障。

设一个关键帧需要在第二跳的 1000us 到 1040us 窗口内发送。帧从第一跳出来时，第一跳认为当前是 990us。路径传播和处理后，帧到第二跳时，第一跳估计大约是 1002us，听起来刚好进入窗口。

但如果第二跳本地时钟比第一跳慢 20us，第二跳看到的时间其实是 982us。对第二跳来说，窗口还没开，帧只能等待。这个等待会改变后续路径上的到达时间，甚至让后面的窗口也错过。

这就是为什么“调度表看起来合理”还不够。你必须知道设备之间的时间偏差上界，否则无法判断窗口余量是不是足够。

引入共同时间后，系统多了一组必须管理的假设：谁是参考时间源，时间如何传播，链路延迟如何估计，设备时间戳是否足够准确，同步中断后能撑多久，拓扑变化后误差是否仍然可控。

这也意味着 TSN 的确定性不是单靠一个协议名成立的。工程文档里写“使用 802.1AS/gPTP”只是开始，还要说明同步精度、误差来源、最坏情况边界和验证方法。否则后续 Qbv、延迟测试和论文模型都可能建立在没有证据的时间假设上。

读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。