learn
调试手册：TSN 失败时按证据链收敛
把 TSN 失败拆成需求、时间、队列、调度、配置、冗余和测量几类证据，形成可复盘的排查顺序。
第九章：验证与进阶阅读工程闭环TSN Validation22 分钟
本节学习目标
- 能按证据链排查 TSN 延迟、丢包或重复问题。
- 知道不要把测量假象误当成网络问题。
- 能把排查过程写成可复盘记录。
建议先读
核心概念
evidence chainroot causeconfiguration driftmeasurement artifact
本章目录
- 01可观测性计划：TSN 测试要留下哪些证据把拓扑、配置、抓包、硬件时间戳、端口计数器、背景压力和故障注入组织成能证明边界的测试计划。
- 02最坏情况指标：平均延迟为什么不够学习 TSN 验证中应该关注最大值、分位数、deadline miss、抖动范围和测量误差，而不是只报告平均延迟。
- 03时间同步证据：没有共同时间，延迟数字也会失真学习 TSN 验证中如何记录 gPTP 状态、时间戳来源、offset、grandmaster 和测量时钟，避免把不同时间基准下的数字硬比较。
- 04故障注入设计：测试要覆盖你声称覆盖的故障学习如何把 FRER、Qbv、Qcc 的故障模型转成断链、端口 down、设备重启、配置失败和恢复阶段的验证场景。
- 05调试手册：TSN 失败时按证据链收敛把 TSN 失败拆成需求、时间、队列、调度、配置、冗余和测量几类证据，形成可复盘的排查顺序。
- 06可复现报告：让别人能重新相信你的结论学习一份 TSN 验证报告应该如何组织拓扑、配置、流量、脚本、原始数据、统计和结论边界。
- 07从验证报告到论文阅读：指标、假设与结论边界把工程测试里的证据意识迁移到论文阅读，判断 TSN 论文的模型、实验、baseline 和结论是否扎实。
解决什么问题
TSN 失败时，现象可能是迟到、丢包、重复交付、窗口 miss、配置不一致或测量数据异常。如果没有排查顺序，很容易反复改配置，把现场证据覆盖掉。
本节解决调试方法问题：按证据链收敛，而不是靠猜。
背景与直觉
复杂系统调试像破案。先保护现场，再收集证据，再排除假象，最后定位根因。TSN 的“现场”包括配置、抓包、计数器、时间同步状态和流量输入。
怎么解决
推荐排查顺序如下。
| 顺序 | 问题 |
|---|---|
| 1 | 需求和 flow set 是否正确 |
| 2 | 时间同步和时间戳是否可信 |
| 3 | 队列映射和入口约束是否正确 |
| 4 | Qbv/CBS/抢占配置是否应用 |
| 5 | Qcc 目标状态和设备状态是否一致 |
| 6 | FRER 序列、重复消除和路径状态是否正常 |
| 7 | 背景流量和故障动作是否符合测试计划 |
| 8 | 统计脚本和测量误差是否引入假象 |
每一步都尽量保存证据，再做改动。改动后记录版本，避免新旧状态混在一起。
带来了什么新问题
严格排查会比“先改一下试试”慢，但它能减少来回试错。尤其是跨团队问题，只有可复盘记录才能让设备、网络、应用和测试人员讨论同一个事实。
调试手册还应随项目更新。新增机制、新增设备、新增测试工具，都可能改变排查顺序和证据类型。
检查点
- 为什么 TSN 失败时第一步不一定是改 GCL？
- 如果怀疑测量数据异常，你会检查哪些时间戳和统计环节？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能列出 TSN 失败排查的推荐顺序。
- 2能解释为什么每次改配置前要保存现场证据。