A&H GLD und Clock

    Wenn das Pult auf internen Clock steht kann es durch die PTP nicht mehr synchronisiert werden. Setzt man dann die Option der M-Dante "Slave to external wordclock" nicht gibt es zwangsläufig Probleme. Da GLD und M-Dante Karte nicht synchron sind.


    Das wird wohl damals die Ursache gewesen sein, warum es DropOuts gab. Durch die Umstellung des GLDs auf Slave ist dieses dann mit der M-Dante synchron und wird auch durch einen anderen Master durch die PTP synchronisiert.


    Warum A&H nicht grundsätzlich empfiehlt den Clock auf slave zu stellen kann ich mir nur mit einen größeren Jitter der M-Dante erklären. Ewt. läuft diese auch weg bei Erwärmung. Ich kann mir aber kaum vorstellen das die Clock Generatoren so schlecht sind auf der M-Dante. Jedenfalls habe ich noch keine negativen Auswirkungen bemerkt.


    Der BCM Algorithmus nimmt nicht nur die Wertigkeit als Maß sondern auch weitere Kriterien. http://www.tekron.com/sites/de…rent_clock_whitepaper.pdf

    Einmal editiert, zuletzt von marcoboy ()

    Zitat von "marcoboy"

    Keine Ahnung warum man dafür einen extra Thread braucht inkl. persönlicher Note.


    Man braucht den Extra-Thread deswegen, weil das Thema - wie deine ausführliche Antwort zeigt - etwas komplexer ist, als dass es in einem iLive-Pro-Contra-Thread einfach mal so mit abgefrühtückt werden könnte.


    Ganz nebenbei: Deine erste Aussage dazu à la "Standardsetup der GLD ist falsch, weil das Pult auf Slave stehen muss" hat einige erst mal extrem verwirrt und wurde in dieser allgemeinen Form auch sehr schnell als falsch entlarvt. Du kamst dann mit der Info nach, dass du das auf Dante beziehst. Das musste ich zumindest erst mal so hinnehmen, weil ich Dante in iLive und GLD noch nie genutzt habe, aber irgendwie war mir die Erklärung zu dürftig. Das kam irgendwie besserwisserisch rüber, so nach dem Motto "Is halt so, weil ich, der Marcoboy, das Wissen gefressen habe und Euch das so sage!". Wenn dann manche Aussagen so definitiv nicht stimmen (oder unvollständig sind), klingt das schnell nach Dampfplauderer.
    Das einfach mal von mir dazu, wie ich einige deiner Posts wahrnehme. Ich kann nicht für die anderen Foristen sprechen, aber ich habe das Gefühl, das geht nicht nur mir so.


    Dazu aber auch danke für deine letzten Posts zu diesem Thema, die das Ganze denjenigen, die nicht jeden Tag Multimaster-Dante-Netzwerke bauen, verständlich macht. Deine Erklärung ist in sich schlüssig und leuchtet ein. Hätte das Ganze (vielleicht in etwas verkürzter Form) gleich beim ersten Post dabeigestanden, hätte es einige Missverständnisse und sarkastische Kommentare (wie auch von mir) gar nicht gegeben.


    Insofern - mehr Sachlichkeit und weniger markige Sprüche oder Allgemeinplätze, die so nicht stimmen, würde generell jedem im Forum ganz gut tun.


    Nix für ungut,
    Robert

    Der Thread wurde vom Mod abgetrennt und gekürzt. Im Original Thread stand etwas von externer Hardware.


    Damit war dann gemeint das dann wichtige Einstellungen verloren gehen und der Anwender vor einen größeren Problem steht als vorher. Wenn z.Bsp seine externen Preamps, Routing etc. weg sind.


    Das laden des Hersteller Setups kann also auch so richtig in die Hose gehen. Das war damit gemeint.

    Zitat von "marcoboy"

    Der Thread wurde vom Mod abgetrennt und gekürzt. Im Original Thread stand etwas von externer Hardware.


    Punkt für dich, das stand da (als kurzer Nebensatz) wirklich. Zumindest ich dachte bei externer Hardware aber eher an sowas die externe FXe oder Inserts, die dann ggf. neu gepatcht werden müssen, aber nix dramatisches wie Dropouts.


    Zitat

    Damit war dann gemeint das dann wichtige Einstellungen verloren gehen und der Anwender vor einen größeren Problem steht als vorher. Wenn z.Bsp seine externen Preamps, Routing etc. weg sind.


    Das laden des Hersteller Setups kann also auch so richtig in die Hose gehen. Das war damit gemeint.


    Richtig, das kann passieren. Es ging im Ursprungsthread aber ja darum, Pulte in einen funktionierenden Grundmodus zu bringen. Da hat man dann normalerweise das Pult in Standardconfig dabei (beim GLD also die AR2412 und ggf. noch den Expander). Wer mit unbekanntem Pult, spezieller Netzwerkhardware (dazu würde ich Dante bei GLD jetzt erst mal zählen) und ohne kompetenten Betreuer auf der Baustelle steht und nicht weiss, wie er das Pult einrichten soll, der ist dann natürlich verloren. Jetzt wirds hier aber wieder OT. Und was ich eigentlich sagen wollte: Ich stolpere einfach öfters über Posts von dir, die für mich im Kontext so einfach keinen Sinn ergeben. Ich glaube gerne, dass du im Allgemeinen weisst, worüber du schreibst, aber meiner bescheidenen Meinung nach verstehst du meist nicht so gut, dich so auszudrücken, dass das auch so rüberkommt.

    Zitat von "simonstpauli"


    Kannst Du das bitte konkretisieren? Was hat der Vertrieb gesagt, was genau soll man nicht machen?


    Na, das Brooklyn Modul auf die Clock der iLive syncen, das sollte man nicht machen.


    Problem war, unser eines Brooklyn Modul war teildefekt oder eher "falsch geflasht" ab Werk - jedenfalls lies es sich nicht ins gleiche Netz bringen wie das andere Modul. Damals mit dem Support telefoniert, das ganze Setup durchgegangen, inklusive der Info dass man das Pult auf die Clock des Moduls synchronisieren soll und nicht umgekehrt, Modul neu geflasht und seitdem läuft das ganze stabil.

    Nichts neues was oben nicht schon besprochen wurde. Nur ist der Sinn bzw. die Empfehlung welche Variante bei welchen Netzwerk Sinnvoll ist aus dem pdf nicht erkenntlich. Wenn das so durchs Netz geistert bleiben die selben fragen offen.


    Mit der DVS als einziger Teilnehmer funktionieren alle Varianten, mit weiteren Dante Geräten kommen zwei nur bedingt in Frage.

    Naja... Es darf nur einen Taktgeber geben. Alle anderen Geräte syncen sich darauf.
    Wer den Takt generiert ist vollkommen humpe.


    Noch ein Beispiel. Diesmal nicht als PDF.



    Es gibt eine iLive auf der Bühne als Monitorkonsole, eine GLD am FoH und eine DVS am FoH.


    Die Monitorconsole ist Taktgeber, also audio Sync INTERNAL.
    Die Dante Karte in der iDR ist "slave to external" und "Prefered Master".
    Die Dante Karte am FoH in der GLD ist "Slave" und der Sync im GLD ist auf "Slave Option Card"
    Die DVS im Hintergrund ist auf jede Fall "Slave".



    Grüße


    Johannes

    Eben nicht. Es gibt schlechte wie gute Clock Master. Bei Ethernet Audio funktioniert das etwas anderes wie z.Bsp bei MADI.
    Der Clock wird aus der PTP synchronisiert, bzw. eine PLL die diesen dann herunter teilt.
    Da ich durch die strengen Lizenz Bedingungen habe ich ein Pflaster auf den Mund, mir sind die Hände gebunden das verfahren genau zu beschreiben. Es läuft aber ähnlich ab wie IEEE beschrieben.


    Das wichtigste ist ein Algorithmus der immer dafür sorgt das auch ein geeigneter Teilnehmer Clock Master wird.
    Dieser Mechanismus wird gezielt ausgehebelt, ohne das die folgen bewusst werden.
    Problematisch ist dabei wenn dein Clock Master über eine Switch angebunden ist. Das Kabel sehr lang und weiterer Datenverkehr über die Verbindung läuft.


    Das Problem das die Durchleitung des PTP auf den Ports der Switch nie wirklich konstant und gleich erfolgt. Durch zusätzlichen Datenverkehr muss die Switch immer mehr Entscheidungen treffen. Das führt dazu das die Latenz wackelt. Der Algorithmus sorgt dafür das solch ein Gerät nicht Master wird.


    Bei AVB hat man die Problematik so gelöst das ein Port an dem der Master hängt Slave wird und die Switch die PTP als Master auf allen Ports verteilt. Alle Pakete sind synchron und unbeeinflusst von anderen Datenverkehr. Die M-Dante mit der Marvell PHY schätze ich mal macht das auch so.


    Ich würde nicht empfehlen in den Mechanismus unbewusst einzugreifen.

    Einmal editiert, zuletzt von marcoboy ()

    Ich denke, marcoboy hat hier nicht ganz unrecht. Wenn man (wie ich) aus der AES3- und MADI-Welt in PTP-Audionetzwerke kommt, übersieht man leicht auch, dass diese Welt etwas anders tickt. So wie ich das hier verstehe, ist bei Dante der Mechanismus zur dynamischen Bestimmung des Clock-Masters eine essentielle Funktion. Mangels eigener Erfahrung mit größeren Dante-Netzwerken (über ne einzelne Rio3224 an einem Yamaha-Pult bin ich bisher nicht rausgekommen) glaube ich das mal so, da die Begründung (Netzwerkjitter) für mich als ITler in sich schlüssig klingt.


    In so einem Fall *kann* man natürlich nicht garantieren, dass ein bestimmtes Pult im Verbund immer die Dante-Clock-Master-Karte drinstecken hat. Unter diesen Vorzeichen ist es wohl tatsächlich klüger, das Netzwerk als Ganzes als Master zu betrachten und alle über Karten oder Adapter angeschlossenen "Fremdsysteme" - also Geräte, die nicht nativ Dante sprechen - als Slave zur Dante-Schnittstelle zu konfigurieren.


    Das gilt m. E. allerdings *nicht*, wenn man nur ein Pult mit einer Dante-Karte und eine Dante-Stagebox hat, die direkt über ein CAT-Kabel verbunden sind. Da ist prinzipiell der eine Dante-Teilnehmer als Master so gut wie der andere. Dann - und nur dann - kann man die Dante-Karte im Pult als Dante-Clock-Master definieren und zum Pult hin auf Slave stellen, und das Pult kann den Clock-Master machen.

    Zitat

    Das Problem das die Durchleitung des PTP auf den Ports der Switch nie wirklich konstant und gleich erfolgt. Durch zusätzlichen Datenverkehr muss die Switch immer mehr Entscheidungen treffen. Das führt dazu das die Latenz wackelt. Der Algorithmus sorgt dafür das solch ein Gerät nicht Master wird.


    Die Anzahl der Entscheidungen lässt kaum einen in den letzten zwei Jahrzehnten gebauten Switch ins schwitzen geraten. Parallel eintreffende Datenpakete auf multiplen Ports, die dann aber nicht gleichzeitig auf einem egress-Ports ausgeleitet werden können, erzeugen hingegen auf jedweder Hardware Jitter.


    Aus diesem Grund wird, wenn PTP in ernsthaft kritischer Genauigkeit einen Takt weiterleiten soll, PTP von allen Netzwerkkomponenten gesprochen, inklusive der Switches und Router. Dann ist es irrelevant, wie gross eine Queue im Switch geworden ist oder wie lange ein Router braucht um ein Paket zu forwarden. Der Takt-Zähler ist immer auf den vom Grandmaster bezogenen Takt synchron und durch Queues auftrende Delays der Signalisierungspakete werden beim weiterleiten irrelevant. In dieser Hinsicht ist PTP den anderen Protokollen überlegen, welche nur eine Delay und Jitter-Detection haben, die auf Heuristik basieren oder anderen "das macht es zumindest besser" Optimierungen.


    Das ist hauptsächlich im Industrie- und Mobilfunkumfeld ein gängiges Setup und Teil der entsprechenden Produkte. Vorteil: solche Switche sind in der Regel auch etwas robuster, was Temperatur angeht. Würden sich also auch eher weniger daran stören im gleichen Rack eingebaut zu werden, in dem schon 10HE Verstärker vorglühen :wink:


    Finanziell werden sich solche Produkte aber kaum für den Veranstaltungssektor rechnen, da die in solchen Netzwerken nötige Genauigkeit für PTP-Verhältnisse klein ist und die Preise für solche Geräte deftig.


    Ein Problem vom PTP im Vergleich zu anderen "Zeitsynchronisierungsprotokollen" ist aber, dass es zwar eine automatische Master-Election gibt, diese aber primär von der von den Zeitprovidern angegebenen Genauigkeit gelenkt wird und auf welche Jitter-Detection keinen Einfluss hat (zumindest nicht in den Standard-Profilen). Siehe Abschnitt 9.3 von IEEE Std 1588 (IEC 61588). Sollte der Jitter also wirklich in für die Anwendung relevante Größenordnungen reichen, sollte man evtl. doch in bessere Hardware investieren. Audio ist hier noch nicht wirklich anspruchvoll.


    Zudem ist sicherlich auch nicht jeder PTP-Stack, der im Master und Slave-Modus vor sich hinrennt, sinnvoll konfiguriert (der gewöhnliche Normaluser wäre mit der Parametrisierung hinreichend überfordert), so dass Hersteller einfach 08/15 Werte pi mal Daumen vorgeben. Mit dem Ergebnis dass es bei gleichkonfigurierten Geräten in der Realität zu wüsten Quer-Synchronisierungen und Problemen mit Korrektur-Werten kommen kann (TAI vs UTC-Offset mit korrekten Leap-Seconds?)


    Daher ist es nicht unwahrscheinlich, dass es einfach verdammt sinnvoll ist, in der Konfiguration aller Geräte festzunageln wer gefälligst Master und wer alles nicht Master sein soll. Das Gerät mit der höchstwahrscheinlich nicht wie ein PC herumeiernden Uhr sollte möglichst nicht den Takt bestimmen und ein Gerät mit sehr gutem Taktgenerator wird höchstwahrscheinlich ein guter Kandidat sein. Und schon ist das Thema gegessen und man sich wieder den kaputten Cat-Kabeln widmen.

    Ja klar so gesehen hast du natürlich recht zumal die PTP eine PLL synchron hält die auch noch auf den Audioclock herunter geteilt wird. Das Problem bei Dante ist das der User selber sicher stellen muss das seine Infrastruktur geeignet ist. Das überfordert die meisten User und Anleitungen die 3 Varianten ohne Erklärung warum dies so einzustellen ist sorgen für mehr Verwirrung. Wir mögen es verstehen aber die meisten User nicht. Solche Fixen Einstellungen in der Hardware sorgen dann auf Baustellen gerne mal für Probleme. Tja "da war was ... irgend Haken gesetzt da irgend wo .. "



    Selbst bei großen Netzen hatte ich nie Probleme mit Quer-Synchronisierungen. Die Entwickler von Audinate haben an einigen Stellen wirklich Pionierarbeit geleistet.