Beiträge von HeK

Zitat von gäbsn

Hier wird AVB mit Milan durcheinandergeworfen. AVB stellt ein Set an Spezifikationen bereit, definiert aber nicht, was davon umgesetzt werden muss. Genau das war ja immer die Krux.

Milan setzt hier an und definiert bewusst die Minimalanforderungen (z. B. Kanäle pro Stream, 48 kHz Support verpflichtend, höhere Samplerates optional, …), um Interoperabilität sicherzustellen. ...

Ganz kleine Korrektur: Milan enthält keine Verpflichtung zu 48kHz. Es ist vielmehr der einzige (!) Fall, in dem 2 Milan Geräte kein Audio miteinander verbinden können, wenn sie NICHT dieselben Samplerates unterstützen.

Das erscheint merkwürdig, hat aber den Grund darin, dass es auch Mischpult- und Studiogerätehersteller gab und gibt, die ausschließlich auf 96 kHz oder 192 kHz setzen, und die wollten auch Milan implementieren können, ohne ihre gesamte Hardware umbauen zu müssen. Sample Rate Converter implementieren geht - wie auch immer - nur mit hohem Aufwand.
Es wird sich auf Dauer zeigen, ob sich Hersteller in Zukunft noch dazu hinreißen lassen, Geräte in den Markt zu bringen, die wg. Vernachlässigung von 48kHz nicht mit allen anderen Milan Geräten interoperabel sind.

Ich behaupte, dass der Markt das Thema recht schnell erledigen wird, zumal es - Stand heute - eh eine absolute Ausnahme ist.

Zitat von marcoboy

Nö Milan hat den Standard der IEEE verlassen und sogar an dem genormten Header was heran geklatscht so das es inkompatible wird. Auch hat man die Art des Verbindens modifiziert so das es mit AVB Geräten Probleme gibt.

Der Grund ist da man sich bei der IEEE mit den Vorschlägen nicht durchsetzte, hat man eben seinen eigenen Kram erfunden.

Sorry, aber das ist komplett falsch. In der letzten Version des 1722.1 wurden in Zusammenarbeit mit den Milan Herstellern sogenannte 'Vendor Specific Commands' eingeführt, die es erlauben, dass bestimmte Profile von AVB - wie z.B. Milan, es ist ein AVB PROFIL - eigene Befehle definieren und implementieren. Das ist also allerhöchstamtlich IEEE 1722.1 konform.
Der Grund für diesen Weg ist, dass die IEEE selbsterklärtermaßen niemals in der Lage wäre, allen Detailanforderungen der ProAV Industrie vollständig und in angemessener Zeit (!!) gerecht zu werden. Genau deshalb gibt es solche Profile wie Milan, in welchen die Use Case spezifischen Details definiert sind. Aber nichts ist hier 'eigener Kram' oder gar prinzipiell inkompatibel.

Die Verbindungsprozesse in 1722.1 sind teils unzureichend für größere ProAV Anforderungen und wurden ebenfalls mit Hilfe dieser spezifischen Erweiterungen optimiert. Das alles wird von der Avnu Alliance geprüft und zertifiziert.

Ich weiß es, weil ich Teil des Vorgangs war und immer noch bin.

Zitat von audiobo

Führt PTP-Jitter zu Samplingjitter, ja oder nein?

Das hängt vom Spectrum des Jitters ab. Wenn der Jitter eher hochfrequent ist (schmale Spikes) dann wird die Trägheit der Empfänger PLL das in aller Regel gut genug ausregeln können.
Wenn die Abweichungen sehr langsam ODER wenn sie asymmetrisch sind wird es eher problematisch.

Bei PTPV1, was ja die Zeit der Übertragung durch alle Switch Hops hindurch zwischen den Endpoints misst, tritt dann leicht sogenannter 'Wander' auf (Ein 'Wegwandern' der Clock), wenn sonstiger Traffic durch die Switche asymmetrisch ist. Also wenn sehr viel Traffic in eine Richtung verläuft, so dass der Hinweg für die PTP Packete andere Latenzen aufweist als der Rückweg.

Solche eher langsamen asymmetrischen Clock Ungenauigkeiten können zum Wegdriften einer PLL führen. Genaus das wurde in dem Experiment bei IXIA demonstriert, indem man Video Traffic unidirektional durch 6 Hops geleitet hat mit 95% Auslastung der Bandbreiten. Das ist gerade bei Video ja keine Seltenheit, das ein Netz in eine Richtung wesentlich mehr Traffic hat als in eine andere.

Zitat von gemini

Dass PTPv2 nach 6 Hops 4500ns jittert ist definitiv nicht korrekt.

Diese Aussage hat in dieser Allgemeinheit niemand getroffen. Das Doc von Keysight berichtet von einem sorgfältig durchgeführten Experiment, welches zeigt, dass eine solcher PTP Jitter unter bestimmten Umständen auftreten KANN, was nicht besagt, dass er es unter allen Umständen tut.

Ganz im Sinne der Korrektheit. (!)

Zitat von gemini

Wie gesagt ich bin wirklich kein verfechter von Audinate, ich bin auch für offene Technologien, aber trotzdem muss man korrekt bleiben.

Keysight ist nicht bekannt dafür, inkorrekte Messungen vorzunehmen. Im Gegenteil, die sind führend im Bereich Messtechnik für Netzwerke. Ich wüsste nicht, was hier 'inkorrekt' ist. Es scheint eine Frage der Interpretation zu sein.

Die Fragestellung war, ob das AVB gPTP wirklich besser ist (stabiler, genauer, zuverlässiger) als PTP V1 oder PTP V2. Wie die Ergebnisse zeigen, lässt sich gPTP auch durch massiven anderen Traffic (95% Auslastung der Bandbreiten in diesem Experiment) nicht irritieren und bleibt unter 100ns PTP Jitter.

Wie gesagt, in der Praxis wird man solche Auslastungen nicht konstant haben - das wäre sehr schlechtes Netzwerkdesign - aber als Spitzenbelastung ist das statistisch natürlich möglich und kann PTP V1 ordentlich aus dem Takt bringen. Ob das relevant ist kann man wohl nur im Einzelfall bewerten, aber es führt ja zu der best-practice Empfehlung, Dante und Best-Effort-Traffic in relevantem Ausmaß möglichst getrennt zu halten.

Eine Frage an Gemini: Inwiefern unterstützt Dante PTP V2? Dante selbst läuft meines Wissens nur auf PTP V1 aber diverse Dante Hardware unterstützt AES67 und das basiert natürlich auf PTP V2.

Zitat von Christian Hofmann

Audinate garantiert eine Genauigkeit von 1-2 microsekunden (Laut den Unterlagen vom Level 3).

Diese Genauigkeit wird bei Dante mit PTP V1 nur dann erreicht, wenn auf dem Netz nur sehr wenig oder kein weiterer Best Effort Traffic vorhanden ist. Sobald im Netz Bursts auftreten oder die Bandbreite auf Links halbwegs ausgeschöpft wird beginnt die PTP V1 Clock zu wandern. Das ist durch VLans kaum zu vermeiden, weil sich auf den Trunks zwischen den Switchen eh alles die Bandbreite teilt.

Wann treten Bursts auf? Z.B. wenn man über das Netz Dateien kopiert, Updates fährt, Videos auf Webseiten schaut oder wenn man umfangreiche Steuerdatenpakete an die Devices sendet (etc). Der von Audinate angegebene Wert ist ein Idealwert, der in der Praxis nur dann erzielt wird, wenn Dante sein eigenes isoliertes Netzwerk hat und die daran angeschlossenen Rechner sich äußerst 'brav' verhalten.

Es gab dazu umfangreiche Tests wie hier etwa von Keysight.
https://www.keysight.com/us/en/assets/7…than-Classi.pdf

Es wurde gezeigt, dass (unter allerdings extremer Auslastung der Bandbreite von 95%) das PTPV1 (Dante) bis in den ms Bereich asynchron werden kann. In der Praxis wird der Effekt meist geringer sein, tritt aber jederzeit auf, wenn die PTP Pakete durch Bursts anderer Daten nicht mehr gleichmäßig fließen.