AVB in der Theorie super aber die Praxis ist eher bescheiden

  • Wie versprochen wollte ich euch nicht mit jeder Neuigkeit langweilen, also war hier erst mal eine weil pause.


    Der Code hat eine bessere Struktur bekommen und wurde so umgearbeitet das er auf verschiedenen Plattformen lauffähig wäre. Es gab starke Veränderungen Im Code , die ich jetzt nicht im einzelnen abspulen möchte. Jedenfalls ist er wieder ein Stück fixer geworden :) .


    An der API gab es Änderungen was die Json Antworten angeht, Values mit vielen Werten werden jetzt besser angezeigt, siehe unten. Das Betrifft auch die Control Values... Momentan arbeite ich am einheitlichen Errorhandler, hierzu muss man ab und zu den Code nochmal anfassen. Da ergeben sich dann meist auch Optimierungen. Unter Linux bin ich mit dem BpF vom Kernel jetzt grün und es gibt vermutlich April, Mai noch eine Überraschung.... So läuft das Projekt stabil..


  • Also ich möchte ein paar Dinge Posten. Der Controller kann wenn man es es aktiviert sich als eigenes Entity im AVB publizieren. Das ist schon seit einen Jahr vorhanden, aber nur mit dem Deskriptor "Entity" -> Konfiguration 0. Jetzt ist das Entity vervollständigt worden. In Vorbereitung für die versprochene Überraschung. Es wird so sein das man Deskriptoren in ein einem Konfigurationsfile beschreiben kann und das der Entity Core die Entsprechenden Funktionen bereitstellt -> ist aber noch Baustelle..


    Die Verfahrensweise der Control Values wurde überarbeitet. Die Values werden Count,Type,Range werden aus den Daten des Deskriptor geprüft. Man kann dem Entity keine falschen Values übergeben, oder unvollständige. Wie schon seit über 1 Jahren kann der Controller mit allen Typen umgehen. Die weise wie sie im Json dargestellt werden wurde verbessert. Lässt sich einfacher mit Javascript lesen.. Später kann man das Json Objekt einfach per POST senden und somit die Values setzen.

    Es funktioniert natürlich auch mit dem Deskriptoren Mixer,Matrix ! Siehe Bild, da sieht man schon das besser Json Format. Mixer muss man erst mal verstehen :| . Es beschreibt eine Möglichkeit Control values in einer Quelle zu Mischen. Deswegen werden nur Linear Values unterstützt. Das Thema Sources ist ziemlich wirr und ich werde das noch besser da stellen müssen. Sources lassen sich ja schon per HAL verfolgen.


    Einmal editiert, zuletzt von marcoboy ()

  • Mal was anderes außerhalb dem Controller Thema..


    Mir wurde im Dezember ein Raspberry Pi CM4 https://www.raspberrypi.org/pr…nt=raspberry-pi-cm4001000 mit dem IO Board https://www.raspberrypi.org/pr…ompute-module-4-io-board/ auf den Tisch gelegt.


    Nebst der unsauberen Verarbeitung wird das Board als "Onboard Gigabit Ethernet PHY supporting IEEE1588" beworben.


    Ich habe mir das auch schon denken können und mich schon kurz im Dezember mit beschäftigt. Das geladene Standard Modul für die Broadcom PHY keine Hardware Timestamps, das haben jetzt auch andere mitbekommen und kotzen bei GIT darüber aus https://github.com/raspberrypi/linux/issues/4151 . Das Problem alles bei Broadcom steht unter NDA selbst die Datenblätter. Ein super Grundlage um Treiber zu entwickeln und ich glaube ich nicht das dies die Raspberry Pi Foundation machen wird. Obwohl das eine wichtige Voraussetzung wäre um wie beworben das Modul in der Industrie zu verwenden. Macht keiner Bastelkram bleibt Bastelkram..


    Aber das IO Board hat auch einen PCIe Slot, also hat der Marco eine Intel i210 aufgesteckt einen PTP fähigen Kernel gebaut und mit dem linux PTP Projekt versuche gemacht.


    Um festzustellen das zwar die PHY synchronisiert und es auch gelingt diese Uhr mit dem System zu synchronisieren. Naja fast, denn der Clock vom dem Board ist derart miserabel das dieser stark weg läuft und es mit der Regelschleife im Userspace dann nicht mehr gelingt das die PLL einrastet.


    So ein paar Stunden läuft es dann ist auf einmal Feierabend, warum auch immer. Schaut man sich die Linux AVB Projekte so an ist nichts dabei was wirklich verwendbar ist. SRP,QOS werden von der Konsole aus gesteuert und einen einen IEEE1722.1 Controller gibt es erst recht nicht. Man startet Talker und Listener auch per Hand und hofft das was ankommt. Fazit von 2013 bis heute ist man nicht sehr weit gekommen...

  • 1. Marco, du arbeitest doch auch seit 2014 an deinem Controller. Wo ist der denn? Da brauchts du dich über die Linux Community nicht beschweren. Mal davon ab, dass jemand aus der Community, ohne selbst ein verkaufbares Produkt herstellen zu wollen, die 500$ für die IEEE Spezifikationen hinlegen wird.

    2. Laut den Kommentaren auf der Raspberry Github Seite ist doch mittlerweile ein Hardware PTP Treiber in Arbeit oder sogar schon im Test.

    3. Wenn man Wine installiert kann man auch unter Linux (X85) jeden Windows AVB Controller verwenden. Und ein Controller braucht auch weder PTP noch Trafficshaping.

    4. Üblicherweise benutzt man heute ein AVB Audiointerface mit USB für die Verbindung zum Rechner (Motu AVB Serie, Presonus, RME Digiface AVB). Die Haben alle eine Mischpultfunktion und Controller (zumindest zum Connekten) integriert und sind die ideale Bridge zwischen Comptuter und AVB Netzwerk.

    5. Von Neutrik gibt es ein Modul (Neutrik MINEA) mit dessen Hilfe OEMs eigene AVB Geräte bauen können sollen. Vielleicht gibt das ja einen neuen Schub für AVB.

    Ich, der AVB nur hobbymäßig einsetzt (Motu 16A an Linux Rechner mit i210 https://github.com/Drumfix/avb4linux)) , bekomme natürlich leider keine Doku dazu von Neutrik.


    Gruss

  • Hallo,


    1. Ich beschäftige mich seit 2014 mit TSN und mit dem Controller wurde ernsthaft vor 2 1/2 Jahren begonnen.
    2. PTP ist nicht alles was man für ein TSN fähiges Gerät benötigt. Du beklagst den nicht kostenfreien IEEE Standard. Alles bei Broadcom steht unter NDA nicht einmal ein Datenblatt bekommt man. Extrem schlechte Voraussetzungen für die Entwicklung eines Treibers. Mit der i210 musst du dich ja auskennen, das kann der Treiber von der Broadcom PHY nicht einmal ansatzweise.

    3. Man braucht kein Wine ,Win10 hat ein Linux Subsystem. Außerdem ist das Projekt vom Ansatz her auch auf anderen OS lauffähig. Deswegen ja auch der wechsel zu cmake Im Übrigen Hive lässt sich auch für Linux übersetzen. Wenn du einen Controller mit Benutzeroberfläche suchst.

    4. Der RME Controller ist lustig, weißt du wie dieser funktioniert ? Ohne PC gar nicht, denn dieser läuft auf dem Rechner wo der Treiber läuft.

    5. Kenne ich aber bisher noch keine Hardware gesehen, auch keine Entwicklungsumgebung.


    Nunja es ist eben alles nicht so einfach und ich mit der Meinung das dass Projekt noch nicht so weit ist um es zu veröffentlichen.

    Momentan arbeite ich an einer neuen Flow API. Das Projekt hat auch ein völlig anderen Ansatz und des wird auch so bleiben. Wenn sich keiner findet und mit HTML5 eine Oberfläche baut.

  • Ich will das Produkt https://www.neutrik.com/de/pro…audio/milan-oem-solutions nochmal auseinander nehmen.


    Es kann nur 100MBit/s links -> veraltet und es basiert auf einen Marvell ARM Switch Baustein. Der ARM der da oben ist für die Peripherie . Von Marvell bin ich geheilt und in der Praxis die Kunden sicherlich auch.


    Die Idee war ewt. einen RPI CM4 hierzu zu ertüchtigen. Wenn man die Software schon mal entwickelt hat, diese auf andere Industrie fähige Hardware zu portieren. Soweit die Idee, die Praxis ist dank NDA sehr weit entfernt. Nun bin ich am prüfen ob NXP die bessere Wahl wäre... Der günstige Preis eines RPI CM4 erschien mir als nicht so sehr Risikoreich.

  • Huhu...


    Es gibt mal wieder was neues ;). Die Flow API ist fertig, ich kann jetzt viel besser Flows verwalten. Also alles was um das verbinden von Geräten benötigt wird. Irgendwann mehr dazu...


    Ich bin jetzt dabei mit nochmal Gedanken zu machen die API zu beschreiben. Mich mit RAML und OpenAPI beschäftigt. Nunja mich für openAPI entschieden. Nur leider rendert auch die aktuelle Version nicht so die links wie HATEOAS (Hypermedia as the Engine of Application State) -> HAL. Deswegen muss das auch erst mal drin bleiben.


    Unheimlich Mühselig, aber hier die ersten Ergebnisse. Funktioniert so... Die API wird in einem json oder yaml beschrieben. Durch den Client gelesen und der rendert dann das UI -> rechts auf dem Bild. Das was zu sehen ist wird aus der Beschreibung erzeugt, es ist nicht die Antwort vom Controller ;) .

  • Hmm auch mal wieder Rückschläge. Die Tools hierzu funktionieren nur halb, man kann damit eine simple API sicherlich fix beschreiben. In meinen Fall wird das ganze so derart komplex das keine Sau mehr durchsieht. Wichtige Dinge die es vereinfachen würden funktionieren schon seit Jahren nicht. Ich habe mir die mühe gemacht die Json per yaml zu beschreiben das war auch nicht ganz nutzlos. Ich habe ganz einfach ehrlich gesagt keine nerven herzu mich in dort so tief einzuarbeiten das da was brauchbares heraus kommt. Problematische fragen gibt es einen Haufen und auch keinen der mir sagt ob das überhaupt Sinn macht. Ohne externe Hilfe geht es hier nicht sinnvoll weiter. Aus externen Quellen wird man auch nicht schlau. Im openAPI Projekt sind unglaubliche 450 Issues ! Da Entwickler merken das Dinge fehlen oder nicht funktionieren um ihr Projekt zu beschreiben. Vor dieser Mauer stehe ich auch...

  • So ein Stück Schokolade als Energie Reserve und muss ich da durch. Ich muss die API irgend wie umschreiben. Also weiter mit der openAPI. Ich bin jetzt dazu übergegangen das ganze in kleine Teile zu zerlegen. Was nicht funktioniert im Editor, aber irgend wie doch. Das komplexe ist ich muss jeden Endpoint beschreiben und das sind unheimlich viele. Die Deskriptoren habe ich schon alle beschrieben :) . Hierbei habe ich auch gleich bemerkt was einfach gedacht aber aus Sicht der API schlecht gelöst wurde.


    Warum der Aufwand? Aus dieser Beschreibung kann man mit einem Generator eine Client/Server Bibliothek für fast 30 Sprachen generieren. https://openapi-generator.tech/docs/generators


    Das macht es einfach die API einzubinden.


    Die Erfahrung war nicht umsonst, sie hat auch gezeigt was von der anderen Seite verbessert werden kann. Anbei nur mal ein kleiner Einblick wie umfangreich das ganze wird, es zeigt einen kleinen Teil der Endpoints. Erstmal nur die Methode GET, andere kommen noch.


    Im Grunde und das ist auch das Ziel, diese Beschreibung einzulesen und im Controller mit Variablen zu verknüpfen.

  • Ich hatte einen guten Freund, er war ein zufriedener junger Mann, Lehramtsstudium, nette Freundin ... begeisterter Hobbyangler. Bei Ihm auf dem Klo gab es immer ganz wunderbare Lektüre, den Blinker, den deutschen Karpfenfreund, ein paar Bände Jamiri und Robert Crumb.


    Dann hatte er eine Sinnkrise, die nette Freundin verlassen, ein Informatikstudium durchgezogen und ist heute ein Top-Notch Java Programmierer .... auf seinem Klo liegen nur noch C++ Inside, Linux Weekly & Co. .... sein Leben ist einsam, niemand besucht ihn mehr .... schmeiß dich nicht weg, und mach was Anständiges aus deinem Leben ... sonst führst du irgendwann virtuelle Selbstgespräche in einem Veranstaltungstechnikforum ...

  • sonst führst du irgendwann virtuelle Selbstgespräche

    "transparenz" würde ich das bezeichnen :)


    Alles Super - er hängt sich doch dahinter und hält die User auf dem Laufenden - könnten ein paar Hersteller auch 'mal machen ;)


    :thumbup::thumbup::thumbup:



    sec

    "geht nicht" ? - gibt's nicht !

    ...ja, das war schon immer mein Avatar :evil:

    "Mit der Dummheit kämpfen Götter selbst vergebens" (Friedrich Schiller, " Jungfrau von Orleans")

  • Das hier kaum Antworten kommen ist auch dem geschuldet das wir hier in einem Veranstaltungstechnikforum sind :) . Die wenigsten können bei diesem Thema verständlicherweise etwas beitragen. Auch einer deiner Forderungen, wenn man keine Ahnung hat F... halten.


    Ich habe den Thread nun damals hier begonnen und bei 66k Zugriffe kann dies nicht ganz uninteressant sein. Der Austausch findet schon statt aber eben auf anderen Foren und das er zu speziellen fragen.


    Die API zu beschreiben erfolgt auch viel zu spät, denn nur so kann ein außenstehender erkennen welche Fähigkeiten das Projekt besitzt. Der Otto Normalverbraucher kann mit dem Projekt erst mal wenig anfangen. Aber andere könnten mit der Hilfe der API Beschreibung etwas leicht bedienbares bauen.


    Andere Controller Projekte greifen das Thema REST API ebenfalls auf. Das Angebot steht immer, wer es ausprobieren will kann sich gerne melden.

  • Ich Bitte um etwas Geduld :sleeping: ... Das mit der openAPI ist ein riesengroßer Schritt. Wo schon erwähnt funktioniert nicht alles wie man sich das wünscht.


    Der Grund ist auch folgender das nun die Daten direkt im Json Objekt per PATCH geändert werden können. Die Examples sind auch in der API beschrieben. Es fällt also der "command path" weg.


    Auch wird die Content Negotiation implementiert, geht auch gar nicht anders.


    Hindernisse gab es auch mit dem CORS Regeln im Browser, die mich dann auch dazu gebracht haben das Thema anzugehen. Jede Ressource muss die Methode OPTIONS implementiert haben, sonst laufen andere Methoden außerhalb GET gegen den Baum.

  • So lang lang ist her.. Der Punkt API Beschreibung ist ein großes dickes Brett was erst mal gebohrt werden muss. Der Umfang ist so groß das es auch die Tools an ihre grenzen bringt. Aus diesen Daten habe ich mal mit dem openapi-generator eine HTML File erzeugt. Mit solchen Generatoren kann man aus den Quellen der Beschreibung in YAML auch anderer Code generieren.


    Ich habe mal das generierte HTML File und YAML angehängt Video und Sensor Units habe ich auskommentiert. Der Umfang ist der gleiche wie bei der AudioUnit. So hat man einmal eine Vorstellung davon welch ein Umfang das Projekt besitzt. Das HTML File kann man mit dem Browser öffnen und das YAML mit swagger. Wobei Swagger den Vorteil hat das man sich besser durcharbeiten kann ;). Aber nicht wundern das einlesen dauert aufgrund des Umfangs etwas -> Javascript Meldung des Browsers ignorieren.


    Das YAML umfasst 35000 Code Zeilen, so lässt das nicht bearbeiten und deshalb wurde es in verschiedenen Dateien gesplittet. Später mit einem Generator wieder zusammen genagelt. Hier gibt es auch hin und wieder Probleme. Da sich nicht alles so aufteilen lässt wie man sich es wünscht.


    Die Manipulation der Daten erfolgt über die JSON Dokumente oder als Forms. Der Command Path fällt komplett weg. Man schaue in die API :) .

  • Hallo marcoboy,


    ich dachte, ich muss mich nun auch mal registrieren und hier etwas schreiben nachdem ich den Thread hier immer mal wieder als anonymer Leser sporadisch verfolge und muss dir erstmal großen Respekt zollen für deine Ausdauer und Hingabe für dieses Projekt.


    Vielleicht kurz zur Hintergrundinfo: Bin aktuell nicht mehr aktiv im VT Gewerbe aktiv, habe ich früher mal als Student gemacht und arbeite jetzt als Entwicklungsingenieur im Audio-Bereich.

    Ich habe vor nicht allzulanger Zeit an einem proprietären Audio-over-IP System gearbeitet, welches aber konzeptuell in eine ähnliche Richtung wie AVB, Dante & Co geht. Also Systemlatenz unter 2ms und eine Audio-Synchronisation der Endknoten im Bereich von ca. 100ns.

    Daher habe ich mir vor allen Dingen die Dante-Boards aber auch z.B. die XMOS AVB Lösungen mal sehr genau angeschaut.


    Mein Gefühl ist, dass sich AVB auf so einem Standardsystem wie einem Raspberry gar nicht so effizient implementieren lässt.


    Wenn man sich mal Dante anschaut -> entweder arbeiten die mit einem Spartan-6 FPGA oder bei den kleineren AVIO Adaptern ist ein kleiner Single-Core ARM Freescale Microcontroller einfach nur drinnen.


    Zu erstmal zu dem PTP:

    Wenn man hier wirklich die präzise Synchronisation haben will im Bereich unter 100ns, muss man zumindest einen Ethernet-MAC Controller haben, der das Zeitstempeln der eingehenden und ausgehenden MAC frames erlaubt. Normalerweise haben da viele uC's oder SoC's einen standard Ethernet-Controller von Synopsis drinnen. Da lässt sich dann über die Deskriptoren der Timestamp auslesen (bevor die Daten weiter ins IP-Stack laufen). Egal ob das jetzt ein ST Chip oder NXP Chip ist. Ich habe das am Ende des Tages nicht unter Linux gemacht. Aber müsste low-level ähnlich funktionieren.


    Das Interessanteste ist halt, dass man 1. zum "Clock-Master" im System synchron werden muss mit den RX/TX Audio-Datenströmen und 2. Akkurat das Audiointerface (I2S / TDM) synchron bekommen muss (damit man das Audio wirklich überall phasensynchron rein und rausbekommt).
    Damit das geht, muss man das Sync/WCLK Signal vom I2S/TDM sauber gegen die PTP clock Zeitstempeln können um dann über eine PLL die Clocks vom Audio-Interface nachzuregeln, damit das Timing von lokalen Audio-Interface Synchron zu den gewünschten "Playback-Zeiten" der Audio-Ströme wird.


    Dazu braucht man dann zwingend wie schon geschrieben eine externe PLL (bei den Dante-Karten ist immer so ein kleiner SiLabs QFN Chip drauf oder ansonsten auch recht gerne genommen der CS2100 chip). Und dazu muss man wie schon geschrieben im SoC das Audio-Interface gegen die PTP Clock zeitstempeln.


    Ich frage mich gerade so ein bisschen wie man das auf einem System wie ein Raspberry oder einer Standard-Linux Maschine realisieren möchte. Klar die i210 kann PTP unterstützen, bleibt aber trotzdem noch das Problem der Synchronisierung von Audio I/O gegen die PTP clock? Bestimmt ist das irgendwie machbar auf dem Broadcom chip, aber ohne tiefergehende Dokumentation und der Standardsoftware die verfügbar ist, sehe ich das schwarz um ehrlich zu sein.


    Wie ist da dein Plan wie du hier weitermachen möchtest?

  • In erster Linie ging es ja hier im einen Controller. Das man da so tief einsteigt das man auch in der Lage ist Geräte zu bauen fällt nebenbei ab.


    Das mit dem CM4 war eine angedachte Nebenbaustelle in Verbindung mit dem Projekt. Es ging darum in Streams rein zu hören und PTP Dinge anzuzeigen. Auch die Hardware als Produkt zu verwenden -> ist ja sowie so nicht lieferbar.


    Das mit den rein hören ist an sich leicht machbar, man schneidet die Pakete einfach mit, die Zeitbasis ist erst mal Wurst . Du musst aber erst mal die Switch und die AVB Geräte dazu bringen dir einen Stream zu schicken.


    Beim CM4 ist genau das passiert was ich befürchtet hatte , die Entwicklung des PTP Treiber ist gestoppt. Ich vermute einmal weil die PHY von Broadcom nicht richtig funktioniert. Die PHY stempelt die Pakete und der Kernel unterstützt dies auch. Knackpunkt ist der Treiber, der muss dies an den Kernel übergeben.


    Der Controller ist fast kein Controller mehr, er ist in der Lage sich selbst als AVB Gerät im Netzwerk zu publizieren. Das ist ja die Grundvoraussetzung um einen Stream zu erhalten. Was man machen kann und das ist eine weitere Baustelle. Die Descriptoren per JSON einlesen und Callbacks zur Verfügung zu stellen. So ließe sich auch ein Endgerät steuern welches auf dem System läuft. Dazu muss man aber die Pakete im Kernel anhand des CD Bits filtern, dazu lädt man ASM Code in den Kernel.


    AVB Geräte mit ARM sind so eine Sache. Dazu braucht man mehrerer Cores auf dem man Zeitkritische Dinge aufteilt. Flaschenhals ist die Schnittstelle der PHY und Interne Schnittstellen . 1Gbit/s zu verarbeiten geht eigentlich nur mit einem FPGA. Der XMOS macht bei 44Mbit/s zu, also mehr wie 32ch 48KHZ geht nicht, trotz 1Gbit PHY. Das XMOS Zeug würde ich auch nicht verwenden wollen, die kümmern sich um ihren Code nicht und dieser ist seltsam zusammengenagelt.


    Das Projekt ist ziemlichen Verwerfungen ausgesetzt. Einige Dinge fasse ich zum dritten mal an, da ich keinen Berater hatte die mich davon abgehalten hätten. Jetzt wird mein gebastelter JSON Generator ausgetauscht. Das bringt an andere Stelle wieder Vorschritte und der Code kann entschlackt werden. Tja wo soll es hingehen, zum TSN Controller der alle Dinge im Standard unterstützt. Macht er ja schon, also einziger mit Video und Sensor Units etc.


    An dem eigentlich AVB Core wurde bis auf Kleinigkeiten kaum etwas gemacht. Die größte Zeit frisst das Userinterface mit HTTP/REST Schnittstelle. Da ich mich von Anfang an gegen eine Grafische Oberfläche verwehrt habe und konsequent auf HTTP setzte hat das Projekt gegenüber Mitbewerbern voreile. Sie übernehmen ja auch ein paar Dinge.... Mir fehlt das 50 Man starke Entwickler Team :/. Das ich den Code noch nicht veröffentlicht habe hat genau jene gründe. Ich muss mir über die Auswirkungen auf mögliche Anwender keine Gedanken machen...

  • Ich schätze mal die lowcost Variante für den PI heisst Samplerateconversion. Damit geht aber vermutlich die 2ms Latenz flöten.

    Der i210 kann, so glaube ich, an den SDP Pins ein PTP synchrones Signal ausgeben, das dann von einem CS2100 in eine MCLK gewandelt werden kann. Wie hier

    https://statics.cirrus.com/pubs/appNote/AN408REVA.pdf

    von Cirrus Logic beschrieben.

    Bin aber kein Hardwaremensch, kann mir also sowas nicht selbst zu Testzwecken zusammenbasteln.

  • Nun du musst ja auch die Daten zum Wandler übertragen. Die Betrachtung sieht einfach aus ist aber dann doch nicht so einfach.


    MCLK muss zwingend von der CPU Hardware erzeugt werden und synchron mit der PTP sein. Warum?


    Die Daten müssen am Wandler zum Zeitpunkt x vorliegen, lesen/schreibend ist da egal.


    Im Stream ist eine Präsentationstime vereinbart. Wann die Daten am Ausgang erscheinen und diese Zeit ist von der PTP abgeleitet. Stimmt diese Zeit nicht läuft der Buffer über oder leer. Da ja der Talker die Daten immer weiter sendet, zur PTP Zeit. Bist du zu schnell sind die Daten gar nicht vorhanden, zu langsam läuft das Glas über und die Daten sind verloren.


    Einfacher ist es ohne Hardware. Empfangen ist kein Problem und mitschneiden. Senden musst die Hardware in der Lage sein die Pakete zu stempeln und synchron mit der PTP sein. So kritisch ist das ganze ja auch nicht, 2ms ist eine menge zeit die man hat, da kann man große Buffer bauen.


    2 Channels In/Output mit einem ARM halte ich für realisierbar. Wenn die PTP/PHY und i2s vorhanden sind. Man braucht aber QOS was zuverlässig funktioniert und das lässt sich nicht auf dem ARM mit einem Core machen. Da muss man dann eine PHY nehmen oder einen Switch IC der das kann. Sonst kann man mit dem 1722.1 den Stream flach legen.


    Im übrigen ein Mangel in den alten XMOS Geräten. Der Core war mit dem Stream schon zu sehr ausgelastet das dieser 1722.1 Pakete ignorierte. Dieser hatte sie zurückstellen müssen und innerhalb von 250ms ausliefern. Alternativ antworten und sich mehr zeit erbitten.