iperf3 必须用 udp 模式测抖动，因 tcp 的重传、滑动窗口和拥塞控制会掩盖真实延迟波动；udp 才能暴露网络时序变异，且更贴近 voip、视频等实时业务。

iperf3 为什么必须用 UDP 模式测抖动

抖动（Jitter）本质是数据包到达时间的变异，只有 UDP 才暴露真实网络时序行为；TCP 自身重传、滑动窗口和拥塞控制会掩盖延迟波动，iperf3 -u 是唯一有效起点。

• 不加 -u 默认走 TCP，测出来的是吞吐或重传率，不是抖动
• SD-WAN 设备常对 TCP 流做路径优化或分片重组，UDP 更接近真实业务（如 VoIP、视频流）的感知
• -b 带宽参数要略低于链路标称带宽（比如标称 100Mbps，设 -b 80M），避免因打满引发队列堆积，把设备缓存抖动误判为链路抖动
• 务必加 -i 1（每秒输出），否则默认只给汇总值，看不出抖动随时间的变化趋势

服务端启动命令不能漏掉 -s 和 -p

SD-WAN 多站点部署时，服务端常在中心机房或云 VPC 内，端口暴露和防火墙策略容易出错；iperf3 -s 启动后默认监听 5201，但 SD-WAN 网关可能只放通特定端口（如 5001）。

• 服务端必须显式指定端口：iperf3 -s -p 5001，客户端才好对齐
• 若服务端在 NAT 后（如私有云），需确认 SD-WAN 策略已将该端口映射到公网 IP，否则客户端连不上，错误信息是 Connection refused
• 别用 -D 后台运行却不查日志——iperf3 -s 出错时静默失败，建议先前台跑一次确认无报错再后台

客户端命令要带 -u -b -l -t -i 这五个关键参数

少一个就可能让抖动数据失真：SD-WAN 的路径切换、FEC 补偿、优先级队列等机制，只在持续、稳定、小包的 UDP 流下才可被观测。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• -u：强制 UDP
• -b 20M：固定发送速率（单位 M 或 K），避免自适应导致流量忽高忽低
• -l 1200：设置包长为 1200 字节（小于典型 MTU 1500），避开分片，也更贴近语音包大小
• -t 60：至少跑够 60 秒，短于 30 秒很难捕捉 SD-WAN 动态选路带来的周期性抖动
• -i 1：每秒输出一行，从 stdout 中 grep jitter 可快速提取抖动序列

示例完整命令：iperf3 -u -c 192.168.10.100 -p 5001 -b 20M -l 1200 -t 60 -i 1

看抖动不能只盯平均值，重点扫 jitter_ms 的分布和突增点

SD-WAN 抖动不是平稳噪声，常表现为“大部分时间

• 用 grep jitter 提取所有行后，用 awk '{print $7}' | sort -n 查抖动值排序，看 95% 分位是否
• 注意 iperf3 输出中 jitter_ms 是毫秒级浮点数，但精度只到 0.1ms，低于 1ms 的抖动显示为 0.1，不代表网络完美
• 如果某几秒抖动突然飙升（比如从 5ms 跳到 65ms），立刻检查那段时间 SD-WAN 控制面日志——大概率是链路切换、BFD 检测超时或 FEC 启动补偿
• 别忽略丢包率（datagrams 行里的 loss），抖动 + 丢包组合才是 SD-WAN 真实压力测试点

真正难判断的，是抖动毛刺和 SD-WAN 主动干预之间的因果关系——得把 iperf3 日志时间戳和控制器操作日志对齐看，这点最容易被跳过