Dante Unicast Delay Requests: PTP-Multicast sicher reduzieren

6 Min. Lesezeit · Aktualisiert am 14. Oktober 2026 · AV-Netzwerkingenieure, Systemtechniker, FOH- und Monitortechniker, Broadcast-Operatoren, Veranstaltungstechniker, Integratoren und Produktionsleiter

Verstehen Sie Dante Unicast Delay Requests, prüfen Sie die Leader-Kompatibilität, aktivieren Sie die Funktion nur bei kompatiblen Followern und testen Sie Taktstabilität unter repräsentativer Netzwerklast.

Kurzantwort — Dante-Clock-Follower verwenden normalerweise Delay-Request-Nachrichten, um die Laufzeit im Netzwerk zum Clock-Leader zu messen. Auf unterstützten Geräten senden Unicast Delay Requests diese Nachrichten direkt an den Leader statt per Multicast; dadurch kann der Multicast-Steuerverkehr in großen Netzwerken sinken. Bestätigen Sie zuerst, dass aktuelle und mögliche Leader die Funktion unterstützen, aktivieren Sie sie nur auf kompatiblen Followern und testen Sie anschließend Wahl, Synchronisation, Audio und Wiederherstellung vor der Abnahme.

Was die Einstellung verändert

Dante-Geräte verwenden Precision Time Protocol, damit Follower sich am gewählten Clock-Leader ausrichten können. Delay-Request-Nachrichten helfen einem Follower dabei einzuschätzen, wie lange Timing-Nachrichten durch das Netzwerk laufen. Das Standardverhalten nutzt Multicast; die optionale Einstellung bewirkt, dass ein Follower seine Delay Requests per Unicast an den Leader sendet.

Einstellung	Verkehrsverhalten	Betriebsfolgen
Standard-Delay-Requests	Follower senden Multicast-Delay-Requests	Einfache Kompatibilität, aber mehr Steuerverkehr mit steigender Follower-Zahl
Unicast Delay Requests aktiviert	Jeder aktivierte Follower sendet Anfragen direkt an den Leader	Weniger Multicast-Delay-Request-Traffic, wenn jedes erforderliche Gerät unterstützt wird
Gemischt kompatibles Netzwerk	Einige Follower nutzen Unicast, andere bleiben auf Multicast	Kann gültig sein, wenn Support und Leader-Verhalten dokumentiert sind
Nicht unterstützter Leader-Pfad	Aktivierte Follower können den erwarteten Austausch nicht abschließen	Follower synchronisieren möglicherweise nicht

Diese Einstellung verändert den Transport des Clock-Control-Traffics. Sie wandelt Dante-Audioflüsse nicht von Multicast auf Unicast um, ersetzt keine IGMP-Konfiguration, behebt keine Überlastung und ändert nicht die Audio-Latenzeinstellung des Receivers.

Entscheiden, ob das Netzwerk es braucht

Belassen Sie die Standardeinstellung, wenn das Netzwerk klein, stabil und innerhalb seiner gemessenen Kapazität ist. Unicast Delay Requests sind eine Überlegung wert, wenn eine große Anzahl an Endpunkten zu spürbarem Multicast-Clock-Control-Traffic führt oder wenn das entwickelte Design es ausdrücklich verlangt.

Orientieren Sie sich an Messwerten: inventarisieren Sie Gerätemodelle und Firmware, identifizieren Sie aktuelle bevorzugte und gewählte Leader, messen Sie Multicast-Traffic und prüfen Sie Clock-Ereignisse. Aktivieren Sie die Option nicht nur deshalb, weil „unicast“ effizienter klingt.

Der Dante-Guide zum Clock-Leader erklärt Wahl und externe Clock-Übernahme. Der Leitfaden zur Netzwerkgesundheit erklärt, wie Sie Traffic und Clock-Daten baselinefähig erfassen.

Mit Kompatibilitätsprüfung aktivieren

1. Inventarisieren Sie jeden möglichen Leader und Follower

Dokumentieren Sie Gerätemodell, Dante-Interface-Generation, Firmware, primäre und sekundäre Rolle, aktuellen Clock-Status und ob Controller Unicast Delay Requests anzeigt. Beziehen Sie Geräte ein, die nach einem Ausfall Leader werden könnten, nicht nur den beim Setup sichtbaren Leader.

2. Belegen Sie zuerst die Leader-Unterstützung

Die Controller-Hinweise von Audinate sagen, dass die Funktion nur auf Followern aktiviert werden muss, der Clock-Leader aber die Unicast Requests empfangen können muss. Prüfen Sie die Unterstützung, indem Sie bestätigen, dass die Option für das Gerät verfügbar ist, und indem Sie die aktuelle Gerätedokumentation konsultieren. Wenn ein möglicher Leader es nicht unterstützt, lassen Sie die Follower im Standardverhalten oder planen und testen Sie eine unterstützte Leader-Policy.

3. Ändern Sie eine kontrollierte Follower-Gruppe

Speichern Sie die bekannte, funktionierende Konfiguration und die Ereignisbasis. Aktivieren Sie die Einstellung bei einer kleinen, repräsentativen Gruppe kompatibler Follower. Ändern Sie Leader-Priorität, QoS, Verkabelung, Firmware und Delay-Request-Modus nicht im selben Testfenster.

4. Prüfen Sie Synchronisation und Audio

Bestätigen Sie, dass jeder geänderte Follower auf den erwarteten Leader lockt, stabil bleibt und eindeutig identifizierbares Audio durchlässt. Beobachten Sie Clock-Status, Offset-Historie, Event-Logs, Paketfehler und Multicast-Auslastung unter Normal- und Spitzenlast. Vergleichen Sie die Ergebnisse mit der Basis, statt sich auf einen kurzzeitigen grünen Status zu verlassen.

5. Testen Sie Wahl und Wiederherstellung

Entfernen oder deaktivieren Sie den aktuellen Leader an einer freigegebenen Grenze. Bestätigen Sie, dass ein unterstützter Ersatz gewählt wird und jeder aktivierte Follower ohne unzulässige Stummschaltung oder wiederholte Warnung neu synchronisiert. Stellen Sie den ursprünglichen Leader wieder her, warten Sie auf Stabilität und wiederholen Sie den Test auf redundanten Primary- und Secondary-Pfaden, falls vorhanden.

Fehlerbilder diagnostizieren

Nachweis	Wahrscheinliches Problem	Nächster kontrollierter Check
Geänderte Follower verlieren sofort die Synchronisation	Der aktuelle Leader unterstützt Unicast Requests möglicherweise nicht	Diese Follower-Gruppe zurücksetzen und Leader-Fähigkeit prüfen
Der Normalzustand besteht, aber Leader-Failover schlägt fehl	Ein möglicher Ersatz-Leader ist inkompatibel	Jeden zulässigen Leader einzeln testen
Nur ein Gerät fällt aus	Firmware, Gerätesupport oder lokaler Pfad unterscheidet sich	Mit einem bekannten guten Follower derselben Rolle vergleichen
Die Multicast-Last ändert sich kaum	Delay Requests waren kein relevanter Teil des Traffics	Messung erneut prüfen und gegebenenfalls beim Standardverhalten bleiben
Clock-Warnungen bleiben bestehen	Die Ursache liegt woanders im Timing- oder Netzwerkpfad	Den Clock-Event- und Offset-Nachweisen folgen
Das Secondary-Netzwerk verhält sich anders	Support, Firmware oder Topologie unterscheidet sich zwischen den Pfaden	Beide Netzwerke als getrennte Fehlerdomänen prüfen

Erhöhen Sie die Audio-Latenz nicht, um Clock-Instabilität zu verdecken. Die Receiver-Latenz schützt die Medienausgabe vor zu spät eintreffenden Audiopaketen; sie behebt keinen inkompatiblen PTP-Austausch.

Abnahme-Checkliste

Jeder aktuelle und mögliche Clock-Leader hat dokumentierten Support.
Jeder geänderte Follower hat kompatible Firmware und zeigt die Einstellung an.
Eine bekannte, funktionierende Konfiguration und eine Clock-Event-Basis sind gespeichert.
Geänderte Follower locken und bleiben unter repräsentativer Last stabil.
Echtes Audio wird an jedes kritische Ziel übertragen.
Die Multicast-Auslastung wird vor und nachher gemessen.
Leader-Verlust, Wahl, Wiederherstellung und Tests der redundanten Pfade bestehen.
Das Rollback-Verfahren stellt das vorherige Verhalten wieder her.
Zuständigkeit und die akzeptierte Geräteliste sind dokumentiert.

Wenn ein Test Warnungen erzeugt oder die Synchronisation verloren geht, verwenden Sie zuerst den Dante-Fehlerleitfaden zur Clock-Synchronisation, bevor Sie die Änderung ausweiten.

Die Entscheidung zum Clock-Control dokumentieren

Dokumentieren Sie, warum die Option nötig ist, die Geräte- und Firmware-Inventur, aktivierte Follower, zulässige Leader, Auslastung vor und nach der Änderung, Clock-Ereignisse, Offset-Nachweise, Failover-Ergebnisse, Verantwortliche und Rollback-Punkt. Ein späterer Techniker muss eine absichtlich gemischte Konfiguration von einem unvollständigen Rollout unterscheiden können.

In Techrider.live halten Sie die Entscheidung neben den Notizen zum Digital-Audio-Netzwerk und der Patch-Liste fest. Laden Sie den Systemingenieur ein, denselben Technical Rider zu bearbeiten, speichern Sie die akzeptierte Version, prüfen Sie die Historie und exportieren Sie ein PDF für die Übergabe an Venue oder Tour.

FAQ

Was sind Unicast Delay Requests in Dante?

Sie sorgen dafür, dass ein aktivierter Clock-Follower PTP-Delay-Request-Nachrichten direkt an den Clock-Leader sendet, statt sie per Multicast zu übertragen. Sie betreffen den Clock-Control-Traffic, nicht den Transporttyp von Audio-Subscriptions.

Sollte ich Unicast Delay Requests in Dante aktivieren?

Aktivieren Sie sie nur, wenn die gemessene Größenordnung oder ein dokumentiertes Netzwerkdesign die Änderung rechtfertigt und alle erforderlichen Leader und Follower kompatibel sind. Ein gesundes kleines Netzwerk braucht die zusätzliche Konfiguration meist nicht.

Welche Dante-Geräte brauchen aktivierte Unicast Delay Requests?

Nur kompatible Follower müssen die Option aktiviert haben. Der aktuelle und jeder mögliche Ersatz-Clock-Leader muss weiterhin das Empfangen der Requests unterstützen.

Können Unicast Delay Requests die Dante-Taktsynchronisation verhindern?

Ja. Audinate weist darauf hin, dass die Aktivierung der Funktion auf Followern, wenn der Clock-Leader sie nicht unterstützt, verhindern kann, dass diese Geräte synchronisieren.

Wie teste ich Dante Unicast Delay Requests?

Erfassen Sie zuerst eine Basis des Netzwerks, ändern Sie eine kleine Follower-Gruppe, prüfen Sie Clock und Audio unter Last, erzwingen Sie eine freigegebene Leader-Wahl, testen Sie Wiederherstellung und redundante Pfade und vergleichen Sie anschließend Multicast-Auslastung und Ereignisnachweise mit der Basis.