Dante Unicast Delay Requests：安全降低 PTP 多播控制流量
閱讀約 7 分鐘 · 更新於 2026年10月14日 · AV 網路工程師、系統技術人員、前場（FOH）與監聽工程師、廣播操作人員、場館技術人員、系統整合商與製作經理
了解 Dante Unicast Delay Requests 的作用、如何先確認 leader 相容性、如何安全啟用 follower，以及如何在代表性網路負載下驗證時鐘穩定性。
TL;DR — Dante 的時鐘 follower 通常會使用 delay-request 訊息來量測到 clock leader 的網路傳遞時間。對於支援的裝置，Unicast Delay Requests 會把這些訊息直接以 unicast 送給 leader，而不是使用 multicast，這可以在大型網路中降低 multicast 控制流量。請先確認目前與可能的 leader 都支援此功能，只在相容的 follower 上啟用，然後在驗收前測試選舉、同步、音訊與回復。
這個設定會改變什麼
Dante 裝置會使用 Precision Time Protocol 的 timing 訊息，讓 follower 能與已選出的 clock leader 對齊。Delay request 有助於 follower 估算 timing 訊息穿越網路所需的時間。預設行為是使用 multicast；此選用設定則會讓 follower 以 unicast 把 delay request 送到 leader。
| 設定 | 流量行為 | 營運影響 |
|---|---|---|
| 預設 delay request | follower 傳送 multicast delay request | 相容性簡單，但隨著 follower 數量增加，控制流量也會增加 |
| 已啟用 Unicast Delay Requests | 每個已啟用的 follower 直接把請求送給 leader | 當所有必要裝置都支援時，可減少 multicast delay-request 流量 |
| 混合相容網路 | 部分 follower 使用 unicast，其他仍維持 multicast | 只要支援性與 leader 行為有文件記錄，可能是有效的 |
| 不支援的 leader 路徑 | 已啟用的 follower 無法完成預期交換 | follower 可能無法同步 |
這個設定會改變 clock-control 的傳輸方式。它不會把 Dante 音訊流從 multicast 轉成 unicast，也不會取代 IGMP 設定、修復壅塞，或改變接收端的音訊 latency 設定。
判斷網路是否需要它
如果網路規模小、運作健康，而且容量在量測範圍內，就維持預設值。當大量端點造成明顯的 multicast clock-control 流量，或工程設計明確要求時，再考慮使用 Unicast Delay Requests。
請從證據出發：盤點裝置型號與韌體、找出目前偏好與已選出的 leader、量測 multicast 流量，並檢視 clock 事件。不要只因為「unicast」聽起來比較有效率，就啟用這個選項。
Dante clock leader guide 會說明選舉與外部 clock 擁有權。network health guide 會說明如何建立流量與 clock 證據基準。
以相容性門檻啟用
1. 盤點每一個可能的 leader 與 follower
記錄裝置型號、Dante 介面世代、韌體、主次角色、目前 clock 狀態，以及 Controller 是否顯示 Unicast Delay Requests。除了設定當下可見的 leader，也要包含在故障後可能成為 leader 的裝置。
2. 先證明 leader 支援性
Audinate 的 Controller 指引指出，這個功能只需要在 follower 上啟用，但 clock leader 必須支援接收 unicast 請求。請透過確認該裝置是否有此選項，以及查閱目前的裝置文件來驗證支援性。如果某個可能的 leader 不支援，就讓 follower 維持預設行為，或設計並測試一個受支援的 leader 政策。
3. 先變更一小組受控的 follower
先儲存已知良好的設定與事件基準。只在一小組、具有代表性的相容 follower 上啟用此設定。不要在同一個測試時段內，同時變更 leader priority、QoS、佈線、韌體與 delay-request 模式。
4. 驗證同步與音訊
確認每個已變更的 follower 都鎖定到預期的 leader、保持穩定，並能通過可辨識的音訊。觀察 clock 狀態、offset 歷史、事件紀錄、封包錯誤與在正常和峰值負載下的 multicast 使用量。請與基準值比較，不要只看某一瞬間的綠色狀態。
5. 測試選舉與回復
在核准的邊界下移除或停用目前的 leader。確認系統會選出受支援的替代者，且每個已啟用的 follower 都能重新同步，而不會出現不可接受的靜音或反覆警告。將原本的 leader 恢復，等待穩定後，再在適用時於冗餘的 primary 與 secondary 路徑上重複測試。
診斷失敗模式
| 證據 | 可能問題 | 下一個受控檢查 |
|---|---|---|
| 已變更的 follower 立刻失去同步 | 目前的 leader 可能不支援 unicast 請求 | 還原該 follower 群組並驗證 leader 能力 |
| 正常狀態可通過，但 leader failover 失敗 | 某個可能的替代 leader 不相容 | 逐一測試每個符合資格的 leader |
| 只有一台裝置失敗 | 韌體、裝置支援或本地路徑不同 | 與同角色、已知良好的 follower 比較 |
| multicast 負載幾乎沒有變化 | delay request 並不是流量中的重要部分 | 重新檢查量測，若合適則維持預設行為 |
| clock 警告持續存在 | 根因在時序或網路路徑的其他地方 | 依照 clock 事件與 offset 證據追查 |
| secondary 網路的行為不同 | 兩條路徑之間的支援、韌體或拓撲不同 | 將兩個網路分開視為不同失效域來稽核 |
不要透過提高音訊 latency 來掩蓋 clock 不穩定。接收端 latency 的作用是保護媒體播放不受延遲到達的音訊封包影響；它無法修復不相容的 PTP 交換。
驗收清單
- 每個目前與可能的 clock leader 都有文件化的支援性。
- 每個已變更的 follower 都有相容韌體並顯示此設定。
- 已儲存已知良好的設定與 clock 事件基準。
- 已變更的 follower 在代表性負載下能鎖定並保持穩定。
- 實際音訊能送達每個關鍵目的地。
- 已量測變更前後的 multicast 使用量。
- leader 遺失、選舉、恢復與冗餘路徑測試都通過。
- 回復程序能還原先前行為。
- 已記錄負責人與接受的裝置清單。
如果測試出現警告或解鎖，請先參考 Dante clock sync troubleshooting guide，再擴大變更範圍。
記錄 clock-control 決策
請記錄為什麼需要這個選項、裝置與韌體盤點、已啟用的 follower、符合資格的 leader、變更前後的使用量、clock 事件、offset 證據、failover 結果、負責人與回復點。未來的技術人員必須能分辨「刻意的混合設定」與「尚未完成的全面部署」。
在 Techrider.live 中，請把這個決策和數位音訊網路備註與 patch 放在一起。邀請系統工程師編輯同一份技術需求清單，儲存已接受的修訂版，檢視歷史記錄，並匯出 PDF 交給場館或巡演交接。
FAQ
Dante 的 Unicast Delay Requests 是什麼？
它會讓已啟用的 clock follower 直接把 PTP delay-request 訊息送給 clock leader，而不是以 multicast 送出。它影響的是 clock-control 流量，而不是音訊訂閱的傳輸類型。
我應該在 Dante 啟用 Unicast Delay Requests 嗎？
只有在量測出的規模或文件化的網路設計足以證明需要變更，且所有必要的 leader 與 follower 都相容時，才應該啟用。健康的小型網路通常不需要額外設定。
哪些 Dante 裝置需要啟用 Unicast Delay Requests？
只有相容的 follower 需要啟用這個選項。現在的 clock leader，以及每一個可能的替代 leader，仍必須支援接收這些請求。
Unicast Delay Requests 會讓 Dante 時鐘同步失效嗎？
會。Audinate 提醒，如果在 follower 上啟用此功能，而 clock leader 不支援，這些裝置可能無法同步。
要怎麼測試 Dante Unicast Delay Requests？
先為網路建立基準，變更一小組 follower，在負載下驗證 clock 與音訊，強制進行一次核准的 leader 選舉，測試回復與冗餘路徑，然後把 multicast 使用量與事件證據和基準比較。