用打流测真实切换窗口
收敛时间不能靠设备日志里的时间戳推断：日志记录的是协议事件发生的时刻，而业务感知的中断长度取决于最后一个成功报文与第一个恢复报文之间的间隔，两者往往差出不少。可靠做法是持续打流——低速率长时间探测，记录丢包序列与恢复点，换算成丢包数量和中断时长。单次测量容易受当时网络状态影响，正式验收至少要采集多次，看均值与最差值的分布，而不是拿一次最好结果交差。测量口径还要与业务要求对齐：语音关心的是连续丢包长度，交易业务更关心恢复时刻。
基本信息
| 测量方法 | 低速率长间隔探测，或专用打流工具持续发包 |
|---|---|
| 核心口径 | 中断时长（秒）与丢包数量（包） |
| 采样要求 | 同一场景多次演练，取均值与最差值 |
| 判据来源 | 业务侧探测结果，而非设备自报的协议事件时间 |
| 对照目标 | 与业务可接受的中断窗口逐项核对 |
典型使用场景
- 双出口切换验收：确认实际中断是否在业务可接受范围内
- 方案比选：对比优化前后的收敛表现
- SLA 对账：向业务方提供量化的切换数据
- 故障复盘：判断某次中断是否超出设计预期
- 参数调优验证：改动检测机制后确认收益是否真实
测量示例
测量示例
# 低速率长时间探测，记录丢包序列与恢复点
ping -c 300 -i 0.2 10.2.2.1 | tail -5
# 带时间戳输出，便于计算中断时长
ping -D -i 0.2 10.2.2.1 | ts
# 大流量场景可用并发流工具观察吞吐恢复曲线
# iperf3 -c 10.2.2.10 -t 300 -i 1结果记录与解读
| 记录项 | 含义 | 判读要点 |
|---|---|---|
| 丢包数量 | 中断期间未收到响应的探测数 | 结合发包间隔换算为时长 |
| 中断起止 | 首个丢包与首个恢复包的时刻 | 这才是业务实际感受到的窗口 |
| 重复次数 | 同一场景重复测量的次数 | 单次结果不足以作为验收依据 |
| 最差值 | 多次测量中的最长中断 | 验收通常以最差值为准 |
探测间隔决定了时间分辨率：间隔 1 秒只能把中断时长精确到秒级，若要评估亚秒级切换，需要把探测间隔压到百毫秒量级。
测量期间避免同时进行大带宽传输或设备管理操作，这些都会让结果偏向悲观。