Dante 封包錯誤與延遲錯誤：判讀正確的網路故障
閱讀約 6 分鐘 · 更新於 2026年10月12日 · 前場（FOH）與監聽工程師、系統技術人員、AV 網路工程師、廣播操作員、製作經理、場館技術人員、整合商與巡演音訊團隊
分辨 Dante 封包錯誤與延遲錯誤，讀懂 Dante Controller 指標與直方圖，追查實體或時序路徑，並驗證修復是否穩定有效。
TL;DR — Dante 的封包錯誤與延遲錯誤代表不同的邊界。封包錯誤表示 switch 與接收端之間的媒體封包已損壞，通常要先往實體連線查；延遲錯誤表示封包到達接收端播放期限太晚或剛好壓線，通常要先看緩衝設定、路徑長度、壅塞、QoS 或拓樸。請在負載下擷取計數器與直方圖，修正根因後只清除一次進行受控重測，並確認實際音訊狀況。
封包完整性與封包到達時間是兩個不同檢查
Dante Controller 的 Network Status 檢視會彙整最近的封包與延遲表現。某一路由可能只出現一種錯誤，而沒有另一種，所以要針對真正變動的指標下手。
| 指標 | Dante Controller 回報的內容 | 優先檢查的第一個邊界 |
|---|---|---|
| Packet Errors | switch 與接收端之間的媒體封包已損壞 | 線材、接頭、switch 埠、光模組、連線協商 |
| Amber Latency | 封包到達時間接近接收端 latency 上限 | 路徑變動、負載、QoS、拓樸、緩衝餘裕 |
| Red Latency | 封包晚於播放期限到達 | 同一路徑，再加上可聽見的音訊遺失與接收端設定 |
| Grey Latency | 裝置沒有有效 subscription | 進行效能判讀前先確認路由狀態 |
Dante network health guide 說明了完整的監測基準。本篇則負責判斷到底是實體損壞，還是封包到得太晚。
從接收端往回診斷 packet errors
Network Status 中的 packet errors 代表媒體在通往接收端的最後一段連線上已受損。打開 Device View > Status，記錄接收錯誤計數、link 狀態、速度、位址與使用率，接著檢查所連接的 switch 埠。
一次只處理一個邊界：
- 保留目前計數與事件時間；
- 以已知正常的線材重新插拔或更換端點線；
- 檢查接頭、patch panel、轉接器、光模組與 switch 埠計數；
- 確認預期的 speed 與 duplex 協商結果；
- 只有在授權時段內才移到已知正常的埠；
- 只清除一次計數器，重現完整負載，並確認計數維持在 0。
不要因為數字小就假設沒問題。長期穩定的舊計數可能只是過去事件的殘留；如果計數在掉訊期間持續增加，那就是很強的證據。請同時比對時間與方向。
用 histogram 診斷 latency errors
接收端 latency 是網路封包從發送端傳到接收端、必須在播放前完成傳遞所能使用的時間區間。支援的裝置會在 Device View > Latency 顯示每個發送端的 histogram。
請依這個順序閱讀：
- Setting： 套用到該 subscription 的實際 latency；
- Peak： 觀測到最慢的封包到達時間；
- Average： 一般到達區域，不是最壞情況；
- Late measurements： 包含一個或多個封包晚於期限的觀測；
- Distribution： 綠色且明顯在上限內代表健康，黃色接近上限，紅色則已超出。
Multicast flow 至少使用 1 ms，而有些發送端協商出的最低值會比接收端預設值更高。請讀取該 subscription 顯示的有效值，不要假設每條路由都用同一個數字。
判斷是修路徑，還是增加緩衝
當設計好的路徑包含更多 switch、較低速的鏈路，或可預期的變動超過現有設定所能承受時，提高接收端 latency 可能是合理的。但它不能拿來掩蓋損壞、壅塞、錯誤 QoS，或意外的拓樸。
| 證據 | 較好的第一步 |
|---|---|
| 一個接收端的 packet errors 上升 | 修復線材、接頭、埠、光模組或協商問題 |
| 只有在尖峰負載才出現 red latency | 檢查容量、QoS、multicast 與共享 uplink |
| 沿著較長但已核准的路徑出現 amber latency | 驗證較大的接收端 latency 設定 |
| 多個接收端都在同一台 switch 後方失敗 | 檢查共同 uplink、queue 與拓樸 |
| 一個發送端對很多接收端都太晚 | 檢查它的存取路徑與共同來源邊界 |
| 網路乾淨，但設定低於裝置/路徑支援值 | 使用支援的 latency 並重建 subscriptions |
當 buffer 變更有正當理由時，請遵循 Dante latency settings guide。修改 latency 會重新建立已接收的 flows，可能中斷音訊，所以請在維護時段進行。
在代表性負載下證明修正有效
- 儲存路由、裝置設定、計數器、histogram 與 switch 證據。
- 執行完整的演出路由，包括 multicast 與備援流量。
- 在實際物理目的地重現受影響的訊號。
- 套用一項實體、網路、QoS、拓樸或 latency 修正。
- 清除相關計數器或 histogram，並記錄新的開始時間。
- 以相同負載與任何已核准的 failover 情境重複測試。
- 確認 packet 計數維持穩定、latency 保持在限制內，且音訊乾淨。
- 恢復或保留已接受的狀態，並記錄責任歸屬。
如果故障無法重現，請保留證據並定義監測時段，不要只看過短暫的綠色畫面就宣告成功。
錯誤分流檢查清單
- Packet 與 latency 指標分開判讀。
- 已命名受影響的接收端、發送端、subscription 與時間。
- 已檢查 link speed、實體計數器與 switch 埠。
- 已保存有效 latency、peak、average、late measurements 與 distribution。
- 已包含完整製作負載與共享 uplink。
- 每次測試只變更一個邊界。
- 只有在記錄過的重測開始時才清除計數器。
- 已驗證實際音訊、復原方式、負責人與 rollback。
FAQ
Dante 封包錯誤和延遲錯誤有什麼差別？
Packet errors 表示接收端附近的網路連線有媒體損壞。Latency errors 表示封包在接收端播放期限前後才到。兩者需要先檢查的項目不同。
Dante Controller 裡的 packet errors 通常是什麼原因？
最常見的邊界是 switch 與接收端之間的實體路徑：線材、接頭、patch point、光模組、埠或連線協商。觀察錯誤計數是否在事件期間增加，可用來確認。
Dante latency errors 通常是什麼原因？
原因包括接收端 buffer 太小、網路跳點太多或速度太慢、壅塞、錯誤 QoS、意外的 multicast 流量、拓樸變更，或 uplink 受限。
我要怎麼讀 Dante latency histogram？
把 distribution 與有效 latency 上限比較。綠色且明顯在上限內的數值代表健康，黃色數值接近上限，紅色數值則表示太晚。同時也要記錄 peak、average 與 late-measurement 計數。
為了避免音訊掉包，應該提高 Dante latency 嗎？
只有在確認實體路徑、容量、QoS、拓樸與裝置支援後才考慮。較大的 buffer 適合真正更長或變動更大的路徑，但不應拿來掩蓋損壞或壅塞。
把診斷邊界寫進技術需求清單
在 Techrider.live 記錄受影響的路由、指標類型、計數器、histogram、路徑、設定、測試負載、修正動作、驗收結果、負責人與 rollback。邀請系統與場館工程師共同編輯同一份技術需求清單，儲存已核准的基準，並在路徑變動時檢查歷史紀錄。