解决什么问题
验证报告最常见的问题是只写平均延迟。平均值可以描述常见体验，却不能证明关键控制流每个周期都满足 deadline。TSN 更关心尾部、最大值、miss 次数和测量误差。
本节解决的是指标选择。没有正确指标，再多测试也可能得出错误信心。
背景与直觉
如果电梯平均等待 10 秒，但偶尔等 5 分钟，用户体验仍然很差。控制网络更严格：如果 deadline 是 500 us，一次 900 us 就可能是失败。平均值会把失败样本稀释掉。
怎么解决
报告至少要同时给出这些指标。
| 指标 | 含义 | TSN 价值 |
|---|---|---|
| average latency | 平均表现 | 只能做背景参考 |
| maximum observed latency | 测试中最大样本 | 接近边界判断 |
| percentile | 尾部趋势 | 观察低频风险 |
| deadline miss count | 超过 deadline 的次数 | 直接判断失败 |
| jitter range | 周期波动 | 控制质量相关 |
| measurement error | 时间戳不确定性 | 影响结论可信度 |
如果 deadline 是 500 us，最大观测延迟是 492 us，但测量误差可能有 +/- 15 us，那么不能简单说安全。你需要把误差预算写进结论。
带来了什么新问题
关注最坏情况会迫使测试更严谨。样本量不足会漏掉低频问题，背景流量不真实会低估尾部，测量精度不够会让边界判断模糊。
同时，最大观测值也不是数学最坏值。它只能说明测试覆盖范围内的结果，因此报告必须写清场景和限制。
检查点
- 为什么平均延迟 80 us 不能证明 500 us deadline 一定安全？
- 如果测量误差是 20 us，最大观测延迟距离 deadline 只有 10 us，你会怎样写结论？