Dante 数据包错误 vs 延迟错误：快速判断正确的网络故障
阅读约 6 分钟 · 更新于 2026年10月12日 · FOH 与监听工程师、系统技术员、AV 网络工程师、广播操作员、制作经理、场馆技术人员、系统集成商以及巡演音频团队
区分 Dante 数据包错误与延迟错误，读取 Dante Controller 指示灯和直方图，追踪物理链路或时序路径，并验证修复是否持久有效。
TL;DR — Dante 数据包错误和延迟错误指向的是两类不同的边界。数据包错误表示交换机与接收端之间的媒体包发生了损坏，通常应优先检查物理链路。延迟错误表示数据包到达得太接近或晚于接收端的播放截止时间，通常应优先检查缓冲选择、路径长度、拥塞、QoS 或拓扑。请在负载下抓取计数器和直方图，修复根因后仅清零一次进行受控复测，并用真实音频验证。
数据包完整性和数据包到达时间是两项独立检查
Dante Controller 的 Network Status 视图会汇总最近的数据包与延迟表现。某条路由可能只出现一种错误类型，因此应优先诊断实际发生变化的那个指示项。
| 指示项 | Dante Controller 报告的内容 | 首先检查的边界 |
|---|---|---|
| Packet Errors | 媒体包在交换机与接收端之间发生损坏 | 线缆、连接器、交换机端口、光模块、链路协商 |
| Amber Latency | 数据包在接近接收端延迟上限时到达 | 路径变化、负载、QoS、拓扑、缓冲余量 |
| Red Latency | 数据包在播放截止时间之后到达 | 同样的路径问题，外加可听损失和接收端设置 |
| Grey Latency | 设备没有有效订阅 | 在性能诊断之前先确认路由状态 |
Dante 网络健康监控指南解释了完整的监控基线。本指南专注于在物理损坏与迟到到达之间做出判断。
从接收端向后排查数据包错误
Network Status 中的数据包错误表示靠近接收端的最后一段链路出现了媒体损坏。打开 Device View > Status，记录接收错误计数、链路状态、速率、地址和利用率，然后检查连接的交换机端口。
一次只处理一个边界：
- 保留当前计数和事故发生时间；
- 用已知良好的线缆重新插紧或替换终端线缆；
- 检查连接器、跳线面板、转接头、光模块和交换机端口计数；
- 确认预期的速率与双工协商；
- 仅在授权时间窗口内切换到已知良好的端口；
- 仅在开始复测时清零计数器一次，复现完整负载，并确认计数保持为零。
不要认为数量很小就可以忽略。一个长期稳定的计数可能描述的是过去事件；而在掉音期间持续增加的计数则是强证据。要同时关联时间与方向。
用直方图排查延迟错误
接收端延迟是网络数据包从发送端传输到接收端、并在播放前可用的时间间隔。受支持的设备会在 Device View > Latency 中为每个发送端提供直方图。
按以下顺序阅读：
- Setting： 应用于该订阅的实际延迟值；
- Peak： 观测到的最慢数据包到达；
- Average： 正常到达区域，而不是最坏情况；
- Late measurements： 包含一个或多个数据包超过截止时间的观测；
- Distribution： 绿色在限制内且留有充足余量表示健康，琥珀色表示接近上限，红色表示已经越界。
Multicast 流至少使用 1 ms，而某些发送端协商得到的最低值会高于接收端的默认配置。请读取订阅实际显示的有效值，不要假设每条路由都使用相同数字。
判断是修复路径还是增加缓冲
如果设计路径包含更多交换机、更低速链路或可预见的变化，而现有设置无法覆盖这些情况，那么提高接收端延迟可能是合理的。但它不能替代对损坏、拥塞、错误 QoS 或意外拓扑的修复。
| 证据 | 更优先的第一步 |
|---|---|
| 某一个接收端的数据包错误增加 | 修复线缆、连接器、端口、光模块或协商 |
| 只有在峰值负载下出现红色延迟 | 检查容量、QoS、Multicast 和共享上行链路 |
| 琥珀色延迟与更长的已批准路径一致 | 验证更大的接收端延迟设置 |
| 多个接收端都在同一台交换机后失败 | 检查共用上行链路、队列和拓扑 |
| 一个发送端对多个接收端都出现迟到 | 检查其接入路径和共用源边界 |
| 网络很干净，但设置低于设备/路径支持值 | 使用受支持的延迟并重建订阅 |
当缓冲调整有合理依据时，请遵循 Dante 延迟设置指南。更改延迟会重新建立接收流，可能中断音频，因此应在维护窗口内进行。
在代表性负载下证明修复有效
- 保存路由、设备设置、计数器、直方图和交换机证据。
- 运行完整的演出路由，包括 Multicast 和备用流量。
- 在其物理目的地复现受影响的信号。
- 只应用一个物理、网络、QoS、拓扑或延迟修正。
- 清零相关计数器或直方图，并记录新的开始时间。
- 用相同负载以及任何已批准的故障切换场景重复测试。
- 确认数据包计数保持稳定、延迟始终在限制内，并且音频干净。
- 恢复或保留已接受状态，并记录责任归属。
如果故障无法复现，请保留证据并定义一个监控窗口，而不要因为短暂的绿色画面就宣布成功。
错误分诊清单
- 数据包指示和延迟指示被分别处理。
- 受影响的接收端、发送端、订阅和时间都已命名。
- 已检查链路速度、物理计数器和交换机端口。
- 已保存有效延迟、Peak、Average、Late measurements 和分布。
- 已包含完整演出负载和共享上行链路。
- 每次测试只更改一个边界。
- 计数器只在记录在案的复测开始时清零。
- 已验证真实音频、恢复、责任人和回滚方案。
FAQ
Dante 数据包错误和延迟错误有什么区别？
数据包错误表示接收端网络链路附近的媒体出现损坏。延迟错误表示数据包在接收端播放截止时间附近或之后到达。两者需要不同的第一步检查。
Dante Controller 里的数据包错误通常是什么原因？
通常的边界是交换机与接收端之间的物理路径：线缆、连接器、跳线点、光模块、端口或链路协商。观察事故期间计数器是否持续增加，可以帮助确认。
Dante 延迟错误一般由什么引起？
原因包括接收端缓冲不足、网络跳数过多或过慢、拥塞、错误的 QoS、意外的 Multicast 流量、拓扑变化或上行链路受限。
Dante 延迟直方图怎么看？
将分布与有效延迟限制进行比较。绿色测量值明显处于限制内表示健康，琥珀色测量值表示接近上限，红色测量值表示已经迟到。还要记录 Peak、Average 和 Late measurements 计数。
要不要通过增加 Dante 延迟来解决音频掉线？
只有在检查了物理路径、容量、QoS、拓扑和设备支持之后才考虑。更大的缓冲适合真实存在的更长或更不稳定路径，但不应拿来掩盖损坏或拥塞。
把诊断边界写进技术需求清单
在 Techrider.live 中记录受影响的路由、指示类型、计数器、直方图、路径、设置、测试负载、修正措施、验收结果、责任人和回滚方案。邀请系统工程师和场馆工程师共同编辑同一份技术需求清单，保存已批准的基线，并在路径变化时检查历史记录。