Performance bei Effekten auf RGBIC-LED-Streifen

Hallo zusammen!

Ich bin noch nicht so erfahren in der DMX-Welt (DMXControl hat es mir aber sehr angetan, supertolles Projekt!) und arbeite mich daher Schritt für Schritt vorwärts. Im "Partykeller" sind etliche Moving Heads, ein Laser, drei Gruppen aus LED-Streifen,... Alles wird über gleichzeitige Cuelists kombiniert, in den Cuelists laufen wiederum viele Effekte (nicht nur statische Szenen).

Die neuste Bastelei ist eine Konstruktion an der Wand mit je zwei separat angesteuerten RGBIC-LED-Streifen a 5 Meter mit je 300 LEDs, angesteuert per Art-Net über den 4096 Kanal Controller von Ulrich Radig.

Mir ist da schon sofort aufgefallen, dass der Controller standalone mit der bunten Begrüßungsszene 100% flüssig läuft. Wenn ich irgendwelche Effekte (auch ähnliche mit Regenbogenfarben) in DMXC draufschmeiße, ist das hingegen etwas hakelig. Bei den 30 Hz von DMXC wird es fürs Auge natürlich auch nicht 100% flüssig. Aber dazwischen sind auch unregelmäßige Hänger in der Wiedergabe, die eher ein Performance-Problem sind. Wenn ich die Updaterate von DMXC erhöhe, wird das (zumindest subjektiv) eher schlimmer.

Über den Controller kann man die LEDs im Streifen gruppiert ansprechen (2er, 4er etc.), wodurch man in DMXC weniger Einzelgeräte ansteuern muss. Das hat das Problem etwas verbessert, aber natürlich relativiert das die eigentlich feine Abstufung mit den vielen LEDs im Streifen...

Kann man da irgendetwas machen oder kommt DMXC hier Performance-mäßig schon an seine Grenzen? Eigentlich wollten wir noch ein wenig erweitern, aktuell werden angesteuert:

- 2 Streifen a jeweils 300 (= 600) LEDs (gruppiert und verkürzt auf 67 + 68 = 135 DMX-Geräte)

- 1 Streifen a 40 LEDs/DMX-Geräte

... und geplant waren noch 1-2 weitere Gruppen a 300 LEDs. Wo sich nun aber die Frage stellt, ob das überhaupt realistisch anzusteuern ist, wenn es bereits nur bei 1-2 Gruppen a 300 LEDs (ohne alle anderen Geräte) hakelig zu werden scheint?

Der DMXC-Host ist ein i7-6700K mit 32 GB RAM (+ GTX 980 Ti, wobei DMXC ja m.W. über die CPU rechnet). Als Version läuft 3.3 RC3.

Wenn ich über die Stage View die zwei auf 67 + 68 Geräte zusammengefassten LED-Streifen ansteuere mit einem Regenbogeneffekt, dann läuft der ausgegebene Effekt noch gerade so ohne Hänger, aber gelegentlich fängt da auch schon die DMXC-GUI an träge zu reagieren. Die Ausgabe liegt in dem Moment bei ca. 70 Msg/s, 900 kB/s und 3100 DMX/s...

Lieben Dank im Voraus!
Adrian

Sorry für die späte Reaktion! Komme leider jetzt erst wieder dazu, mich mit allem zu beschäftigen...

Der Controller ist im gleichen Netz wie der Rest vom Haus (via LAN). Habe jetzt beim Test mit Jinx aber den Eindruck, dass es wirklich an DMXC liegt, weil damit läuft es auf Anhieb extrem flüssig (und das, obwohl Jinx ja auch nur 25 fps ausgibt). Selbst wenn ich 'nen schnellen Strobe draufwerfe sieht das sehr gleichmäßig (und schnell) aus, da hätte ich mit DMXC keine Chance. Schade, da es dabei ja noch nicht um nennenswerte Matrizen geht mit nur rund 130 LEDs.

Auf jeden Fall spannend mit dem "Twinkle-Tree" Projekt, dann ist Jinx wohl wirklich das Mittel der Wahl für solche Anwendungen. Ich schau mal, ob ich meine DMXC-Effekte in Jinx nachbilden und dann fernsteuern kann.

Schöne Weihnachtsfeiertage!

So, wiedermal viel Zeit vergangen...

Mir ist jetzt noch etwas aufgefallen, womit sich das Performance-Problem ggf. eingrenzen lässt: In der GUI (Stage View) laufen die Effekte absolut flüssig, d.h. DMXC selbst berechnet alles wohl ausreichend schnell. An der Ausgabe scheitert es aber, die ist nämlich bei zunehmender Anzahl LEDs extrem hakelig. Und da rede ich absolut nicht von einer großen Menge LEDs/Geräte. Im folgenden Beispielvideo war es schon sehr extrem mit nur ca. 25-30 LEDs (1 Universum), auf denen jeweils gleichzeitig etwas ausgegeben wurde. In anderen Szenen steuere ich auch mal (mehrere) Hundert LEDs über bis zu 11 Universen (2 Controller) an, ohne dass es so schlimm stockt. Es liegt also nicht rein nur an der Anzahl LEDs - trotzdem nimmt das Hakelige mit der Anzahl LEDs zu.

https://www.youtube.com/watch?v=0pT_oCVjCbY (Achtung, Stuhl quietscht laut im Video )

Die Controller selbst (von Radig) funktionieren einwandfrei, über Jinx kann ich beliebige Effekte vollkommen flüssig ausgeben.

Was könnte das sein? DMXControl berechnet alles flüssig (siehe Stage View), auch die Hardware-Infrastruktur und insbesondere Controller können alles flüssig wiedergeben (siehe Jinx). Der Flaschenhals scheint also irgendwo auf dem Weg vom DMXControl-Kernel zum (oder beim) ArtNet-Plugin zu liegen.

Auch auffällig: Wenn ich die Framerate (DMXC) reduziere, werden die groben Hänger (in der realen Ausgabe) weniger. Sobald ich die reale, niedrige Framerate der jeweiligen Szene treffe, sind die Hänger sogar ganz weg (aber mit teils < 15 fps ist es dann natürlich nicht mehr so schön). Irgendwas kann also offenbar gewisse Datenmengen in entsprechenden Frameraten nicht so schnell verarbeiten, wie DMXC es eigentlich berechnet und ausgeben will? Das kann im Grunde genommen (zwischen DMXC-Kernel und Netzwerkkarte) ja nur das Art-Net Plugin sein, das viel zu langsam arbeitet und sich dann extrem an den "zu vielen" Frames verschluckt?

Habe vorhin noch aktualisiert auf den finalen Release von 3.3.0 (Glückwunsch! Und vielen Dank für die viele, tolle Arbeit); damit ist aber alles unverändert.

- -

Fleckenzwerg84

Madrix schaue ich mir bei Gelegenheit mal an, danke. Bin aber rein von den Möglichkeiten extrem zufrieden mit DMXControl und hätte eigentlich keinen Grund, die LED-Streifen über eine andere Software anzusteuern. Die Art der Programmierung gefällt mir extrem gut, zumal es bei mir verschiedenste "Konstrukte" mit LED-Streifen statt eingängiger Streifen oder normaler Matrizen sind. Das lässt sich, so individuell, perfekt in DMXC handhaben.

Absolut, ich habe schon öfters gesehen, dass DMXC eigentlich zu mehr fähig ist... (Schöne Show übrigens!)

Anbei der Wireshark-Mitschnitt. Habe es einmal mit 25 fps DMXC-Ausgabe (-> Anhang) und einmal mit 15 fps getestet. Die Pakete werden zumindest erkennbar in der richtigen Häufigkeit zur Frequenz versendet...

Habe nochmal Verschiedenes getestet, Kurzfassung:

- Mit Jinx laufen alle Arten von Effekten perfekt (flüssig und ohne irgendwelche Hänger). -> Es hängt also wohl irgendwie mit DMXC zusammen.

- Mit DMXC an einem zweiten PC (Projektdatei kopiert) tritt das Problem 1:1 genauso auf. -> Liegt also eher nicht an der Hardware.

- (DMXC) In dem getesteten Effekt-Szenario sind die Hänger bei einer Ausgabefrequenz zwischen 20 und 45 besonders extrem. Unter 20 wird es zunehmend etwas besser. Über 45, vor allem gegen 50, sogar deutlich.

- Interessant: Wenn ich den Netzwerk-Switch entferne und den PC direkt an den Controller anschließe, verändern sich die Probleme recht stark. Es wird wesentlich(!) flüssiger, dafür flackert/blitzt die Ausgabe (LED-Streifen) aber extrem wild... Bei Jinx wiederum ist die Konstellation egal, beides funktioniert wunderbar. (Aufbau regulär: Netgear-Switch zu 1x PC und 2 Ulrich Radig Controllern, alleine im Netzwerk, je mit fester IP)

Das tritt also ausschließlich mit DMXC auf, unabhängig vom Host-System, aber beeinflussbar durch die DMXC-Ausgabefrequenz und auch beeinflussbar durch einen zwischengeschalteten Netzwerkswitch...

//edit

Ergänzende Info: Vor den Radig-Controllern hatte ich einen der LED-Streifen mit einem DMX-Decoder (Noname von Amazon) angesteuert, das DMX-Signal kam über einen JMS USB2DMX. Das hat auch einwandfrei funktioniert...

Ich konnte es jetzt stark eingrenzen und teilweise lösen. Da kommen mehrere Probleme zusammen:

1. Ich hatte Broadcasting im Art Net Plugin (DMXC) ausgeschaltet und stattdessen die Ziel-IP vom Controller angegeben. Dadurch sind offenbar massiv Pakete verloren gegangen (bzw. nicht angekommen), daher das Gestottere und Geflackere. Broadcast an, schon wurde es deutlich besser.

Komisch daran: Das wird durch alle Universen auf einem Controller gleichermaßen beeinflusst. Beispiel bei mir: 3 LED-Streifen als je 1 Universum an einem Controller. Wenn nur einer der LED-Streifen einen Effekt ausgibt, wird es mit jedem der drei Universen, wo ich Broadcast einschalte, sukzessive flüssiger. Auch die beiden, auf denen gar nichts ausgegeben wird! Wenn Broadcast nur alleine auf dem Universum eingeschaltet ist, das gerade auch etwas ausgibt, bleibt es trotzdem sehr ruckelig...

2. Der Windows Defender blockiert scheinbar willkürlich einzelne Pakete (aber nicht alle) von DMXC. Nachdem ich für alle Portfreigabe-Einträge von DMXC einheitlich ausgewählt habe, dass sowohl in privaten, als auch in öffentlichen Netzwerken kommunizieren werden darf, wurde das Gestottere nochmal besser.

3. Wenn ich jetzt noch den Controller direkt mit dem PC verbinde, ohne LAN-Switch dazwischen, dann scheint die Ausgabe (LED-Streifen) tatsächlich 1a zu sein. Mit Switch dazwischen bleibt es hingegen aber noch etwas hakelig.

Da ist jetzt auch der Knackpunkt: Den Switch brauche ich ja, um beide Controller ansprechen zu können... Mir ist überhaupt noch ein Rätsel, was der Switch da macht, das den Art Net Datenverkehr so negativ beeinflusst? Ist ein günstiges Netgear-Teil, der kann und macht nicht viel (ich teste aber mal einen anderen)...

Was mir auch überhaupt nicht einleuchtet ist, dass nichts von alledem bei Jinx irgendeinen Einfluss hat. Da läuft alles tiptop: Broadcasting egal (= aus), Windows Defender egal, Switch egal... Diese ganzen komischen Probleme treten nur in Verbindung mit DMXControl auf. An zwei verschiedenen Computern.

Ist irgendein Art Net Experte hier, der irgendeine Vermutung hat, was da los ist? Für mich ist das noch Neuland...

Hi Steff, insgesamt ist der Aufbau ein wenig größer (mit zwei Radig-Controllern und insgesamt 11 Universen). In meinem Beispiel meinte ich nur einen Teil vom Gesamtaufbau, der wie folgt aussieht:

Universum 1: Art Net -> Radig Controller 1 -> LED-Streifen 1

Universum 2: Art Net -> Radig Controller 1 -> LED-Streifen 2

Universum 3: Art Net -> Radig Controller 1 -> LED-Streifen 3

Die Einstellungen in DMXC sind je Universum so wie von dir beschrieben, also auch in den erweiterten Einstellungen (für das jeweilige Universum bzw. den jeweiligen Eingang vom Controller). Anbei drei Screenshots von einem der Controller, von DMXControl, und zum Vergleich von Jinx.

Steff Interessant, danke!

Ich hab den größeren "4096 Kanal LED Strip Controller", davon insgesamt 2 Stück.

Mit Jinx läuft es wie gesagt absolut perfekt, oder mit DMXC scheinbar auch in speziell der gestern beschriebenen Konstellation mit Broadcast an und -ohne- Switch dazwischen. Switch mit reinklemmen und/oder Broadcast an, schon ruckelt und hängt es wieder (aber auch nur via DMXC)...

LightningBrothers Eben, das wundert mich auch sehr. Gerade so ein günstiger Switch macht mit den Datenpaketen ja auch nichts, außer sie weiterzuleiten...

Ich schau mal nach, was für ein Port das ist, bzw. welche Geschwindigkeit ausgehandelt wird. Da es mit Jinx und auch größeren Effekten (viel mehr LEDs angesteuert) auch funktioniert, vermute ich aber eher, dass das hier kein Problem ist.

Jinx ist jeweils immer aus, ne. Habe immer nur ein Programm laufen Die blockieren sich sonst gegenseitig die Ausgabe.

LightningBrothers Es werden tatsächlich nur 10 MBit/s ausgehandelt. Aber da es ja in einer bestimmten Konstellation funktioniert, kann das nicht der Flaschenhals sein...

Gerade noch eine ganz abstruse Feststellung gemacht: Der PC hat zwei LAN-Karten, die zweite ist i.d.R. deaktiviert. Wenn ich den PC direkt mit dem Controller verbinde und Broadcast in DMXC aktiviere, funktioniert's ja, wie vorgestern festgestellt. Wenn ich jetzt aber auch noch die zweite Netzwerkkarte an den sonst leeren Switch anschließe, fängt es sofort wieder an zu hängen. Den Stecker wieder zu ziehen ändert dann auch nichts. Aber: Schalte ich die zweite Netzwerkkarte, die in dem Moment ja nix mehr macht, via Systemsteuerung komplett ab, ist sofort wieder alles flüssig.

(Die WLAN-Karte und deren Verbindung macht wiederum keinen Unterschied.)

Werd noch kirre mit dem Problem...

//edit:

Ist es in DMXC 3.3.0 noch irgendwie möglich eine Netzwerkkarte fest für das Art Net Plugin auszuwählen, so wie es im Wiki für 3.2.3 als "Bind to" gezeigt wurde?

Quote from Hydrum

Ist es in DMXC 3.3.0 noch irgendwie möglich eine Netzwerkkarte fest für das Art Net Plugin auszuwählen, so wie es im Wiki für 3.2.3 als "Bind to" gezeigt wurde?

Kleiner Push, falls die nachträglich reinbearbeitete Frage untergegangen sein sollte... Ist das noch irgendwie möglich?

Entgegen meiner Aussage vor ein paar Tagen sorgt das Zuschalten der WLAN-Karte teilweise doch für Probleme bzw. starke Hänger (beim Abschalten verschwindet das dann sofort wieder)... Scheint mal so und mal so zu sein, weshalb auch immer.

Wir haben nochmal sehr viel rumgetestet auch mit Netzwerkmetriken, Dummy-Adaptern usw... Das ist 100% ein reines Problem von DMXControl bei der Auswahl der Netzwerkschnittstelle. DMXC scheint, trotz fester Ziel-IP (und Broadcast ausgeschaltet), die Pakete komplett willkürlich über alle möglichen Netzwerkkarten zu jagen, teilweise auch gestückelt im Wechsel. Das ist so wild, dass teilweise sogar eine Karte (oder ein Dummy) in einem komplett fremden Subnetz aktiv sein muss, dass überhaupt was geht.

Egal, was man versucht, mit DMXC lässt sich außer in 1-2 (nicht Praxis-tauglichen) Sonderszenarien kein brauchbares Ergebnis erzielen... Mit Jinx hingegen funktioniert, wie es auch zu erwarten wäre, jede "normale" Konstellation perfekt ohne Probleme.

DMXC bekommt die automatische Bindung an die richtige Netzwerkschnittstelle bzw. das Routing der Art-Net Pakete einfach nicht richtig gebacken...

Daher nochmal die Frage an die Entwickler: Gibt es gar keine Möglichkeit mehr, DMXC fest an eine bestimmte Netzwerkkarte zu binden? Da führt für mich leider kein Weg dran vorbei... Das ist unfassbar frustrierend und macht es in der jetzigen Situation leider so nicht mehr sinnvoll benutzbar

Mini-Update: Die Netzwerk-Routing-Tabellen (cmd -> "route print") sind die Krux. Das ArtNet-Plugin wird sich da mit Windows wohl nicht einig, bzw. verschickt das ArtNet-Plugin teilweise auf den falschen Routen und/oder teilt die Pakete willkürlich auf (weswegen nicht alles am Ziel ankommt). Mutmaßlich ist speziell die Route auf 255.255.255.255 das Problem, muss ich aber noch weiter testen.

Wenn ich alle Routen auf den/die ArtNet-Controller lösche und manuell mit der richtigen Ziel-IP neu setze, dann bekomme ich wenigstens schonmal ein Szenario zustande, in dem ich beide Radig-Controller via LAN, gemeinsam am Switch, zu 99% flüssig ansteuern kann. Andere Netzwerk-/WLAN-Karten muss ich dann aus lassen, sonst jagt das ArtNet-Plugin dort wieder ungefragt Pakete ins Nirvana (anderes Subnetz) und es ruckelt.