AVB in der Theorie super aber die Praxis ist eher bescheiden

Also 10 Jahre will ich nicht brauchen , bald ist aber ein Jahr vergangen seit dem ich an der Sache dran bin..

Aber es gibt Fortschritte, die Problematik mit dem Format bei Control und weiteren Kommandos ist gelöst.

Es bestand ja das Problem die Daten zu entschlüsseln da einige Informationen dazu nicht in der Antwort enthalten sind. Man musste also auch die Descriptoren lesen...

Das Entfällt und das macht der Controller jetzt für den Client. Voraussetzung das Control Value wurde mit einen Descriptor beschrieben... Sonst kommt es in base64 zurück.

So kann man das Value per GET auslesen und bekommt das inkl. Präfix im korrekten Format zurück. Das macht es für Clients besonders einfach und sie müssen nicht zwangsweise die Descriptoren auslesen.

Nunja eine Switch besteht aus zwei teilen. A: den Core der die Datenpakete transportiert. B: Ein System welches den Core steuert. Das System B ist ein normales OS z.Bsp Linux, auf dem man andere Sachen laufen lassen kann. Dort könnte man auch einen AVB Controller laufen lassen.

Diese China Switch basiert auf einen Marvell in dessen ein ARM mit einer Switch kombiniert wurde. Das Problem ohne die Dokumention über die Register ist das ganze nutzlos und ich hatte trotz alles versuche keinen Zugang zur Buildroot Umgebung um Treiber oder auch Programme für das System zu bauen.

Xmos ist für mich mittlerweile unten durch. Der Stack ist so etwas von Grausam gebaut und ungepflegt das es sich kaum lohnt den noch weiter an zufassen. Mittlerweile habe ich die schlimmsten Bugs behoben und mir Descriptoren gebastelt um den Controller zu testen.

Der größte Nachteil ist aber das der Xmos zu wenig Leistung hat. x-core200 hat zwar eine 1Gbit/s PHY macht aber bei ca. 44Mbit/s schlapp. In Channels ausgedrückt alles über 32Ch ist problematisch..

Ohne Traffic-Shaping kann ich den Controller dazu benutzen den Stream zu stören. Ich sende einfach 100000 AVDECC Pakete an das Gerät.. Um das zu vermeiden muss ich verhindern das ich das Gerät mit Trafic bombardiere. Ich könnte schauen in wie weit Antworten zurückkommen und den Sende Queue dann so steuern... Nächstes Problem ...

Es gibt immer wieder Ankündigungen das es einen AVB Stack der auf einen ARM läuft veröffentlicht, aber es entsteht ein ähnliches Problem. Zu wenig Leistung, für 1Gbit/s ohne FPGA nicht möglich.

Ja von Intel z.Bsp. Aber schon mal etwas für FPGA gemacht ? Wenn du ohne Module auskommen willst kannst du alles aus Gattern zusammen basteln. Willst du dir das ersparen musst du dein Portmonee weit aufklappen das wäre dann auch schon leer nachdem du die nötigen Lizenzen erworben hast um deinen Code zu erzeugen..

Für Rolf seinen Medienwandler ist das relativ einfach, für AVB schon etwas schwieriger und sehr umfangreich.

Xmos sollte ja eine alternative zum FPGA darstellen. Da es keine Interrupts gibt, sind zeitkritische Dinge planbar. Es ist aber immer noch ein Mikrocontroller mit mehrenden Kernen. Der auch einen Begrenzten Takt aufweist und wie es somit mal ist mehre Takte benötigt um einen Befehl auszuführen.

Nachteil sind auch die hohen kosten vom FPGA selbst. Ein ARM kostet ein paar Dollar.. Ein FPGA $40 und mehr..

So der stand ist jetzt so das alles zum neuen internen http Service portiert wurde Das alte Interface wurde entfernt...

Bevor was neues hinzu kommt werde ich den Core optimieren und auf Bugs abklopfen.

Dann kommt erst mal der Dicke Brocken mit der Datenbank um die Trafic aus den Geräten zu nehmen.

Der zweite Punkt ist der http Service -> File API, Session Management,TSL, Access Konfiguration

Punkt 3 Firmware Updates der Geräte..

Schaut mal auf der PLS nach AVB Geräten

Nun bin ich doch daran TLV umzusetzen, damit kann man auf den Speicher des entitys direkt zugreifen. Das ist der Mechanismus für Firmware Updates.

Apple hat sogar Bildchen hinterlegt, und vergessen die Adressen zu prüfen. Sie prüfen sie schon reichen mir aber den Inhalt trotzdem durch. autsch.. ich kann also im Speicher des Prozesses munter herum rutschen.

Ein dummes Problem ist das dieses Mechanismus den schreiben,lesen und ausführen mit einen Kommando erlaubt. Dazu bildet man eben mehrere TLV.. Das lässt sich aber in der Rest API nicht abbilden, des wegen kann man nur ein TLV pro Kommando absetzen.

Tadaaa es ist ein Bild ein Bild ..

Was ist passiert ? Mir ist es gelungen im Memory Deskriptor beschrieben Inhalt auszulesen und als base64 zu encodieren .

Die Daten decodiert und wir haben ein gültiges Bild eines Apple Entitys. Welches sich im Browser ohne Probleme decodieren lässt. Der Vorteil darin ist das mit einen Request der Inhalt verfügbar ist und nicht noch mal ein extra Request um den Inhalt abzuholen. Man könnte das natürlich auch Binär übertragen, aber dann verlassen wir das Json Konzept.

Was noch gemacht werden muss -> senden per chunks an den Client und auch das übertragen von Daten zum Entity

Was ich noch überlege das ganze aus den Deskriptor heraus zu machen, somit muss man keine Adressen und Längen angeben.

Offenbar haben einige den Standard nicht gelesen , die Payload ist beim AECP begrenzt und deutlich kürzer als die mögliche.. Das hat einen Grund, man will das diese Pakete im QOS zwischen gequetscht werden. Sind diese zu lang passen sie kaum zwischen den Pausen..

Die meisten senden trotzdem längere Pakete...

Das war jetzt gar nicht einfach .. Das Problem bestand in der libmicrohttpd und der Symptomatik das ich auf jede response vom Entity warten muss(wollte).. Es gab keine Möglichkeit den Post Prozess anzuhalten .. So das ich die Daten komplett einsammeln musste. Um Speicher zu sparen habe ich es nach versuchen so gebaut das die base64 Daten chunk weise decodiert werden, sie müssen eine Teilmenge von 4 haben. Sonst ist das base64 im Eimer. Den Rest der möglicherweise übrig bleibt kopiere ich um und hänge sie beim nächsten chunk an um sie zu decodieren. Das verfahren hat den Vorteil des immer noch weniger speicher braucht als das base64 als String abzulegen.

Diese decodierten Daten werden dann stückweise an das Entity gesendet ..

Es ist eine Zwischenlösung, da das ganze nicht taugt am 100MB zu übertragen. Als File die upload Daten zwischen zu speichern gestaltet sich leichter...

Was man natürlich machen kann ist die Daten mit mehren Request zu übertragen, das ginge natürlich ohne Probleme.

Tatata... ein 4.4k Bildchen aus dem Memory vom Apple ..

Das sind dann die ersten die darauf warten etwas für umsonst zu bekommen... Das Projekt kann schon mehr als das was auf dem Markt verfügbar ist und meine MONOLOGE bestätigen die Erfolge.

Oder kennst du ein Kommerzielles Produkt welches sich per REST API bedienen lässt und somit offen für alle anderen Gewerke wäre ?

ARM ab oder ARM dran .. Ich habe mir mal eine Buildroot Umgebung für den RaspberryPi gebaut und damit auch eine toolchain. Auf deutsch... Linux System aus den Quellen erzeugt und die Werkzeuge um Programme für das System zu übersetzen.

Was soll ich sagen, der Controller lief auf dem Pi ohne Probleme . Ich werde mir mal auch eine für den beaglebone black basteln, denn der hat eine PTP fähige PHY oben..

Weiter geht es...

Der bedarf an einen Controller ist ja in so fern durch aus vorhanden. Das ist auch die Frage die sich jeder Hersteller eines AVB Gerätes fragen muss. Das kostet Zeit und Geld und müsste auf das Gerät umgeschlagen werden. Zumal der Anwender ja auch erwartet das dieser in der Lage ist andere Geräte zu verarbeiten.

Das eigentlich komplexe ist die Controller Angelegenheit und die fällt auf beiden Seiten an. Das blöde dabei ist, es gibt nicht mal einen Controller der alles unterstützt gegen Geld. Das Projekt kann Herstellern eine wertvolle Hilfe sein, bei der Entwicklung und Test ihrer Geräte.

Offenes Konzept durch REST API und JSON ist mit allen Programmiersprachen beherrschbar. Selbst wenn die HTML Oberfläche nicht fertig ist, ist es voll verwendbar...

Ich will mich nicht unter Druck setzen, aber vielleicht ist es bei der nächsten PLS bereit zum Plugfests...

So ich hatte noch ein richtige Leiche im Keller, die dem ganzen den Boden weg zog. Das kam beim Lasttest zum Vorschein, stand auch so noch dumm als TODO da ;)..

Hier mal 1000000 Request auf 4 Thread und 4 Connects. Response Zeit im Durchschnitt 1,9ms. Hardware Raspberry Pi ... Zu beachten ist aber das natürlich ein Entity zwischen ist, was erst mal antworten muss, sonst blockiert der Thread vom Request natürlich und womöglich auch noch ein Stream den Controller belastet.

Das mit dem BF Filter (Linux Packet filter im Kernel) ist noch nicht um das CD Bit ergänzt worden. Der Thread wird dadurch von Stream Daten belastet, da die dumme Switch die MACs als Broadcast durchreicht. Mit AVB Switch natürlich nicht..

Na dann klären wir das Problem mal auf..

Es entsteht folgendes Problem wenn man einen AVB Stream mit einer normalen Switch betreibt und keine VLANs bildet.

Problem [A]

In der IEEE sind die MAC Adressen vom MAAP(ausknobeln von Adressen für den Stream) als Broadcast registriert. Unser Standard Switch wird also den Stream auf alle Ports ausgeben.

Alle Geräte müssen die Daten dann auch verarbeiten, gerade Geräte mit Mikrocontroller können dabei an ihre grenzen stoßen. Oder es landet sogar unglücklicher weise im Wlan und stopft dies zu.

Problem[B]

wir haben eine AVB Switch und ein AVB Gerät an dieses sendet der Controller massiv Daten. Im normal ist sind die Stream Daten priorisiert, steht im Header des Frames. Die Switch bevorzugt diese Daten, der Rest landet im Queue .

Die Switch leert diesen zwangsweise in den Lücken und der labernde Idiot sorgt dafür das der Stream gestört wird. Da das Gerät nicht in der Lage ist den Datenstrom zu verarbeiten.

Problem[C ]

wir haben ein AVB Gerät welches gleichzeitig auch ein Controller ist. Die Daten unterscheiden sich im Header nur durch ein Bit (CD Bit).

Ohne dessen Filterung ganz vorne im Kernel weckt dieser den Prozess jedes mal auf wenn Stream Daten ankommen. Um dann festzustellen, och interessiert mich nicht. Das treibt die CPU Last nach oben...

Jetzt kombinieren wir A+C und kommen zu den Schluss das es besser wäre das Bit zu filtern.. Dieser BF Filter im Kernel ist assembler code der direkt ausgeführt wird. Der jetzige Filter lies sich mit tcpdump erstellen, da es auf die gleiche weise arbeitet. Im Bits zu filtern muss ich mich erst mal in den assembler code einarbeiten.