learn
抢占验证：怎样证明链路真的按 express/preemptable 工作
学习验证帧抢占时要检查能力协商、队列映射、计数器、抓包和最坏阻塞，而不是只看配置开关。
第六章：帧抢占降低阻塞IEEE 802.1QbuIEEE 802.3br18 分钟
本节学习目标
- 知道抢占验证要确认链路两端能力和队列映射。
- 能用最坏阻塞和计数器判断抢占是否真的生效。
- 理解只看配置页面不足以支撑调度预算。
建议先读
核心概念
capability negotiationqueue mappingpreemption counterblocking time
本章目录
- 01express 与 preemptable：抢占不是丢弃普通帧理解帧抢占中的两类 MAC 服务、片段边界和恢复过程，避免把抢占误解成粗暴打断。
- 02抢占与 guard band：更小阻塞换来新的复杂度分析帧抢占如何缩短 Qbv guard band，以及它带来的开销、协商和测试问题。
- 03片段、开销与恢复：抢占不是免费的理解帧抢占把大帧切成片段后，链路会出现额外开销、恢复状态和实现限制，不能只看 guard band 变小。
- 04抢占验证：怎样证明链路真的按 express/preemptable 工作学习验证帧抢占时要检查能力协商、队列映射、计数器、抓包和最坏阻塞，而不是只看配置开关。
- 05兼容性与协商：链路两端都同意，抢占才算成立理解帧抢占依赖链路两端能力、MAC Merge 状态和队列映射，混合设备网络不能只看单端配置。
- 06什么时候不该用抢占：复杂度也有成本学习判断帧抢占收益是否值得，包括链路速率、最大帧长、窗口宽度、设备支持、验证成本和故障排查复杂度。
解决什么问题
抢占经常被当成一个配置开关：打开以后，guard band 就能缩小。但工程上不能这样用。你必须证明链路两端真的协商成功，关键队列真的属于 express，普通队列真的可抢占，计数器和延迟表现也支持这个结论。
本节解决的是验证链路。没有验证，抢占预算只是纸面假设。
背景与直觉
想象你设计了一个更短的安全距离，因为你相信车辆都有自动刹车。如果实际某些车辆没有启用自动刹车，这个安全距离就不再安全。抢占也是同样逻辑：只有设备真实进入抢占工作模式，guard band 才能按片段级阻塞计算。
怎么解决
验证抢占至少分四步。
| 步骤 | 检查内容 | 证据 |
|---|---|---|
| 能力协商 | 链路两端是否都支持并启用 | 端口状态、日志 |
| 队列映射 | 哪些队列 express，哪些 preemptable | 配置快照 |
| 行为观测 | 是否出现片段、恢复和抢占计数 | 计数器、抓包 |
| 预算验证 | 最坏阻塞是否低于完整大帧 | 延迟统计 |
测试时要构造普通大帧持续发送，再让 express 关键帧在不同相位到达。对比抢占开启前后的最坏等待，才能说明 guard band 是否真的可以缩短。
带来了什么新问题
抢占验证很依赖设备可观测性。有的设备能提供清晰计数器，有的只能看到端口状态；有的抓包点看不到片段细节；有的实现对队列组合有限制。这些差异会影响你能留下多强的证据。
此外，抢占可能和 Qbv、CBS 组合使用。组合机制下，单独验证抢占还不够，还要证明它在调度窗口、背景压力和实际队列映射下仍然工作。
检查点
- 如果配置里启用了抢占，但端口协商失败，Qbv guard band 预算会怎样变化？
- 你会用哪些证据证明 express 帧没有等待完整普通大帧？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能列出验证抢占至少要采集的证据。
- 2能解释为什么协商失败会让 guard band 预算失效。