写在开篇·蓉儿又挖坑
上回说到，郭靖搞清楚了TAS——通过时间门控，给关键数据开专用窗口。
郭靖合上笔记本，若有所思：“蓉儿，TAS虽然好，但有个问题——如果刹车指令来得不是时候，刚好在视频窗口，还得等下一个刹车窗口。那不就延迟了吗？”
黄蓉咬了口糖葫芦：“问得好！TAS是‘定时发’，帧抢占是‘插队发’。 今天就把帧抢占讲清楚——它是什么，和TAS有什么区别，什么时候用它。”
一、帧抢占是什么？为什么需要它？
黄蓉在白板上写下定义：
帧抢占 = Frame Preemption = 高优先级数据可以打断低优先级数据的发送
IEEE 802.1Qbu 标准定义
“核心思想：正在发一个长包（比如大视频帧），突然来了一个紧急刹车指令，立刻打断，先发刹车，发完再继续发视频。”
没有帧抢占：
┌─────────────────────────────────────────────────────────────────────┐
│ 视频流（1500字节）正在发送… │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ [视频帧头][视频数据…][刹车指令来了，排队！][视频数据续] │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ ↑ │
│ 刹车排队，等视频发完 │
└─────────────────────────────────────────────────────────────────────┘
有帧抢占：
┌─────────────────────────────────────────────────────────────────────┐
│ 视频流正在发送… │
│ ┌─────────────────────┐ │
│ │ [视频帧头][视频数据]│← 刹车指令来了，打断！ │
│ └─────────────────────┘ │
│ ↓ │
│ ┌─────────┐ │
│ │ [刹车] │ ← 刹车指令插队，先发 │
│ └─────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────┐ │
│ │ [视频数据续][视频帧尾] │ ← 继续发视频 │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
二、帧抢占是怎么工作的
黄蓉画了帧抢占的核心机制：
┌─────────────────────────────────────────────────────────────────────┐
│ 帧抢占原理 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 普通以太网帧： │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 前导码 │ 帧头 │ 数据（最大1500字节） │ CRC │ │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 帧抢占改造： │
│ ┌──────────────────────────┐ ┌───────────────────────────────┐ │
│ │ 前导码 │ 帧头 │ 分片1 │ │ 前导码 │ 分片2 │ CRC │ │
│ └──────────────────────────┘ └───────────────────────────────┘ │
│ ↑ ↑ │
│ 可被抢占的部分 不可抢占的部分（带特殊标记） │
│ │
│ 流程： │
│ ① 开始发视频帧（长包） │
│ ② 刹车指令来了 → 视频帧在可抢占点被打断 │
│ ③ 立即发刹车指令（短包） │
│ ④ 刹车发完，继续发视频帧剩余部分 │
│ │
└─────────────────────────────────────────────────────────────────────┘
三、帧抢占 vs TAS：什么时候用哪个
郭靖问：“TAS和帧抢占都能保障关键数据，有什么区别？怎么选？”
黄蓉画了一张对比表：
| 核心机制 | 时间门控，定时发送 | 打断低优先级，插队发送 |
| 依赖条件 | 需要gPTP时间同步 | 不需要时间同步 |
| 适用场景 | 周期性关键数据 | 偶发性紧急数据 |
| 延迟保障 | 确定性（最坏等待时间可算） | 极致低延迟（几乎不用等） |
| 配置复杂度 | 高（需要配置GCL表） | 低（只需标记优先级） |
| 硬件要求 | 支持802.1Qbv | 支持802.1Qbu |
| 典型应用 | 摄像头视频流（周期30fps） | 刹车指令（偶发紧急） |
TAS适合周期性的关键数据，帧抢占适合偶发性的紧急数据。两者可以配合使用。
四、TAS + 帧抢占 = 黄金搭档
黄蓉画了配合使用场景：
┌─────────────────────────────────────────────────────────────────────┐
│ TAS + 帧抢占 配合使用 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 时间轴：│ 刹车窗口 │ 视频窗口 │ 视频窗口 │ 刹车窗口 │ │
│ │ 100μs │ 500μs │ 500μs │ 100μs │ │
│ │
│ 场景1：刹车指令在刹车窗口内到来 │
│ └── TAS保障：直接走专用窗口，不用抢 │
│ │
│ 场景2：刹车指令在视频窗口内到来（偶发） │
│ └── 帧抢占保障：打断视频，插队发送 │
│ │
│ TAS负责正常调度，帧抢占负责突发情况——双保险！ │
│ │
└─────────────────────────────────────────────────────────────────────┘
五、帧抢占的局限
黄蓉提醒郭靖：“帧抢占也有几个注意事项：”
| 需要硬件支持 | 不是所有交换机都支持帧抢占 |
| 分片开销 | 打断后需要额外的帧头来标识分片 |
| 最小帧限制 | 被打断的帧分片不能太短（以太网最小64字节） |
| 不适用于所有流量 | 只有标记为“可抢占”的流量才能被打断 |
| 配置需谨慎 | 打断太频繁会增加网络开销 |
六、车载典型应用场景
黄蓉画了一张应用场景表：
| 刹车指令 | 帧抢占 + TAS | 偶发紧急，需要极致低延迟 |
| 转向指令 | 帧抢占 + TAS | 同上 |
| 摄像头视频 | TAS | 周期性，确定延迟就够了 |
| 激光雷达点云 | TAS | 大数据量，周期性 |
| 诊断数据 | 无（普通尽力而为） | 不要求实时 |
| 娱乐视频 | 无（普通尽力而为） | 可容忍延迟 |
七、黄蓉的小本本
郭靖翻开她的笔记本，上面写着：
帧抢占核心要点：
1. 帧抢占是什么：高优先级数据可以打断低优先级数据的发送（IEEE 802.1Qbu）
2. 核心价值：偶发性紧急数据不用等周期窗口，来了就发
3. 和TAS的区别：
-
TAS：定时发，适合周期性关键数据
-
帧抢占：插队发，适合偶发性紧急数据
4. TAS + 帧抢占 = 黄金搭档
-
TAS负责正常调度
-
帧抢占负责突发保障
5. 局限：需要硬件支持、分片有开销、配置需谨慎
一句话：TAS是“定时公交”，帧抢占是“救护车”。一个按点发，一个插队走。
写在最后
郭靖合上笔记本：“帧抢占让紧急数据可以打断低优先级数据，不用等周期窗口。TAS适合周期性的关键数据，帧抢占适合偶发性的紧急数据。两个配合，才是黄金搭档。”
黄蓉咬了口糖葫芦：“帧抢占讲完了。那如果网络断了，关键数据怎么办？”
郭靖摇头。
“下篇预告：冗余传输——关键数据走双路，一条断了另一条上。”
打完收工，886。
