Dante Unicast Delay Requests : réduire le trafic multicast PTP en toute sécurité

TL;DR — Les followers d’horloge Dante utilisent normalement des messages de delay-request pour mesurer le temps de traversée du réseau jusqu’au clock leader. Sur les appareils compatibles, Unicast Delay Requests envoie ces messages directement au leader au lieu d’utiliser le multicast, ce qui peut réduire le trafic de contrôle multicast sur les grands réseaux. Confirmez que le leader actuel et les leaders possibles prennent en charge la fonction, activez-la uniquement sur des followers compatibles, puis testez l’élection, la synchronisation, l’audio et la reprise avant validation.

Ce que change le réglage

Les appareils Dante utilisent les messages de synchronisation du Precision Time Protocol (PTP) pour que les followers puissent s’aligner sur le clock leader élu. Les delay requests aident un follower à estimer le temps nécessaire aux messages de synchronisation pour traverser le réseau. Le comportement par défaut utilise le multicast ; le réglage optionnel fait envoyer par un follower ses delay requests au leader en unicast.

Ce réglage modifie le transport du contrôle d’horloge. Il ne convertit pas les flux audio Dante du multicast vers l’unicast, ne remplace pas la configuration IGMP, ne corrige pas une congestion et ne modifie pas le réglage de latence audio du récepteur.

Décider si le réseau en a besoin

Laissez le réglage par défaut en place lorsque le réseau est petit, sain et dans sa capacité mesurée. Envisagez Unicast Delay Requests lorsqu’un grand nombre de points de terminaison génère un trafic de contrôle multicast significatif ou lorsque la conception technique l’exige explicitement.

Partez des faits : inventairez les modèles d’appareils et les firmwares, identifiez les leaders préférés et élus actuels, mesurez le trafic multicast et examinez les événements d’horloge. N’activez pas l’option simplement parce que le mot « unicast » semble plus efficace.

Le guide du clock leader Dante explique l’élection et la propriété d’une horloge externe. Le guide de surveillance de l’état du réseau explique comment établir une base de référence pour le trafic et les preuves d’horloge.

L’activer avec un filtre de compatibilité

1. Inventoriez chaque leader et follower possible

Notez le modèle de l’appareil, la génération de l’interface Dante, le firmware, le rôle primaire et secondaire, l’état d’horloge actuel, et le fait que Controller affiche ou non Unicast Delay Requests. Incluez les appareils susceptibles de devenir leader après une panne, pas seulement le leader visible pendant la configuration.

2. Prouvez d’abord la prise en charge du leader

La documentation Controller d’Audinate indique que la fonction ne doit être activée que sur les followers, mais le clock leader doit prendre en charge la réception des requêtes unicast. Vérifiez la prise en charge en confirmant que l’option est disponible pour l’appareil et en consultant la documentation actuelle du matériel. Si un leader possible ne la prend pas en charge, soit laissez les followers sur le comportement par défaut, soit concevez et testez une politique de leader compatible.

3. Modifiez un groupe de followers contrôlé

Enregistrez la configuration connue comme bonne et la base de référence des événements. Activez le réglage sur un petit groupe représentatif de followers compatibles. Ne modifiez pas la priorité du leader, la QoS, le câblage, le firmware et le mode de delay-request dans la même fenêtre de test.

4. Vérifiez la synchronisation et l’audio

Confirmez que chaque follower modifié se verrouille sur le leader attendu, reste stable et transmet un audio identifiable. Observez l’état d’horloge, l’historique d’offset, les journaux d’événements, les erreurs de paquets et l’utilisation du multicast sous charge normale et de pointe. Comparez les résultats à la base de référence plutôt que de vous fier à un instantané vert.

5. Testez l’élection et la reprise

Retirez ou désactivez le leader actuel à une frontière approuvée. Confirmez qu’un remplaçant pris en charge est élu et que chaque follower activé se resynchronise sans mute inacceptable ni avertissement répété. Restaurez le leader d’origine, attendez la stabilité, puis répétez sur les chemins primaire et secondaire redondants lorsque c’est applicable.

Diagnostiquer les modes d’échec

N’augmentez pas la latence audio pour masquer une instabilité d’horloge. La latence du récepteur protège la lecture média contre les paquets audio arrivés en retard ; elle ne répare pas un échange PTP incompatible.

Liste de validation

• Chaque clock leader actuel et possible a une prise en charge documentée.
• Chaque follower modifié possède un firmware compatible et affiche le réglage.
• Une configuration connue comme bonne et une base d’événements d’horloge sont enregistrées.
• Les followers modifiés se verrouillent et restent stables sous charge représentative.
• L’audio réel passe vers chaque destination critique.
• L’utilisation du multicast est mesurée avant et après.
• La perte du leader, l’élection, la restauration et les tests de chemin redondant réussissent.
• La procédure de retour arrière restaure le comportement précédent.
• La propriété et la liste des appareils acceptés sont consignées.

Si un test produit des avertissements ou des déverrouillages, utilisez le guide de dépannage de la synchronisation d’horloge Dante avant d’étendre le changement.

Documenter la décision de contrôle d’horloge

Consignez pourquoi l’option est nécessaire, l’inventaire des appareils et des firmwares, les followers activés, les leaders éligibles, l’utilisation de base et après modification, les événements d’horloge, les preuves d’offset, les résultats de basculement, le responsable et le point de retour arrière. Un futur technicien doit pouvoir distinguer une configuration mixte intentionnelle d’un déploiement incomplet.

Dans Techrider.live, gardez la décision à côté des notes du réseau audio numérique et de la fiche de patch. Invitez l’ingénieur système à modifier le même rider, enregistrez la révision acceptée, consultez l’historique et exportez un PDF pour la salle ou la transmission tournée.

FAQ

Que sont les Unicast Delay Requests dans Dante ?

Ils font en sorte qu’un follower d’horloge activé envoie les messages PTP de delay-request directement au clock leader au lieu de les envoyer en multicast. Ils affectent le trafic de contrôle d’horloge, pas le type de transport des subscriptions audio.

Faut-il activer Unicast Delay Requests dans Dante ?

Activez-les uniquement lorsque l’échelle mesurée ou une conception réseau documentée justifie le changement et que tous les leaders et followers requis sont compatibles. Un petit réseau sain n’a généralement pas besoin de cette configuration supplémentaire.

Quels appareils Dante doivent avoir Unicast Delay Requests activé ?

Seuls les followers compatibles doivent avoir l’option activée. Le leader d’horloge actuel et chaque leader de remplacement possible doivent toujours prendre en charge la réception des requêtes.

Unicast Delay Requests peut-il empêcher la synchronisation de l’horloge Dante ?

Oui. Audinate avertit que l’activation de la fonction sur les followers alors que le clock leader ne la prend pas en charge peut empêcher ces appareils de se synchroniser.

Comment tester Dante Unicast Delay Requests ?

Établissez une base de référence du réseau, modifiez un petit groupe de followers, vérifiez l’horloge et l’audio sous charge, forcez une élection de leader approuvée, testez la reprise et les chemins redondants, puis comparez l’utilisation multicast et les preuves d’événements à la base de référence.