Stabile DMXControl-Konfiguration

Hallo,
mir ist gerade so eine Idee gekommen. Wie wäre es, wenn man den Ausgabeplugin-Teil in ein eigenes kleines Programm kopiert und eine Zwischenspeicherfunktion einbaut? Dieses würde zumindest helfen, wenn DMXC abstürzt, aber der Rechner weiter läuft. Man müsste sogar vermutlich nicht mal viel an DMXC selber ändern, weil man dieses Ausgabeprogramm per dll als Ausgabeplugin in DMXC integrieren könnte. Die eigentliche Ausgabe an die Interfaces usw. übernimmt dann das kleine Programm (natürlich muss dieses dann recht absturzsicher sein). So könnte man sogar mehrere DMXC-Instanzen an dieses eine Tool anbinden und eine andere Instanz übernehmen, wenn die eine DMXC-Instanz abstürzt. Und wenn man den normalen Ausgabeteil von DMXC nicht verändert, kann jeder sogar selbst entscheiden, ob er diese zusätzliche Zwischenschicht benötigt oder nicht.
Das ist mir grade so spontan eingefallen. Ich weiß nicht, wie gut das funktioniert. Aber mal als kleine Anregung für weitere Diskussionen ;).
Viele Grüße
JP

Das ist in DMXControl 3 umgesetzt, dort läuft ein DMXControl Server, der für Ausgabe und Co. zuständig ist, welcher nicht mal ein grafisches Interface hat.

Das grafische Interface läuft dann auf beliebigen anderen Rechnern im Netz, diese verbinden sich mit dem Server. Wenn nun einer dieser Rechner oder die Software dort abstürzt, läuft der Server weiter und sorgt unterbrechungsfrei für die Ausgabe.

Freundliche Grüße

Stefan

Es darf halt nicht der Server abstürzen. Wobei man auch bedenken muss, dass der die ganzen Berechnungen macht und nicht nur allein für die Ausgabe zuständig ist.

Quote from Stefan

Das ist in DMXControl 3 umgesetzt, dort läuft ein DMXControl Server, der für Ausgabe und Co. zuständig ist, welcher nicht mal ein grafisches Interface hat.

Das ist mir klar, aber meine Idee wäre zumindest für die 2.XX Versionsreihe eine Übergangslösung, bis die 3.XX Serie für den produktiven Einsatz verfügbar ist. Und es sollte auch nicht all zu schwer sein, das umzusetzen.
Viele Grüße
JP

Zum ursprünglichen Thema:

* DMXControl in einer virtuellen Maschine:
Davon würde ich absolut abraten. Ohne der Maschine hat man zwei Punkte, weswegen DMXControl abstürzen kann:
+ Windows
+ DMXControl
mit der virtuellen Maschine hat man mehr Punkte:
+ Windows (Host-System)
+ Windows (Gast-System)
+ Unzulänglichkeiten an der Soft-/Hardwareemulation der virtuellen Maschine
+ DMXControl
Sind also deutlich mehr Punkte gewesen, und die Unsicherheit ist größer geworden. Außerdem steigt die CPU- und Hauptspeicher-Auslastung, da der Rechner quasi zwei Betriebssysteme parallel betreiben muss.

* alle nicht benötigten Fremdprogramme (Mailprogramme, Virenerkenner etc.) beenden
Firewall fehlt (man könnte die Liste endlos erweitern, aber beschränken wir uns mal auf verbreitete Programme)
besserer Ansatz: solche Programme erst garnicht starten. Teilweise lassen die dann trotzdem Reste im System drin. Meine Firewall z.B. ist so tief im System verankert, dass auch ohne Start der GUI der Firewall neue Progamme nicht ins Netz dürfen, die werden ungefragt geblockt (eigentlich sollte eine Frage kommen, aber die kommt halt erst, wenn die GUI gestartet ist - wenn das fehlschlägt, fehlt auch die Frage. Ist aber besser soherum ;))

* Software-Stabilisierung
Da fehlt mir noch ein Punkt: Nur gute getestete Plug-Ins einsetzen. Das führt zwar dazu, dass einige weit verbreitete Plug-Ins nicht mehr eingesetzt werden dürften, dafür hat man dann aber ein stabiles System - ist halt die Frage, was man genau will.

* Hardware-Stabilisierung
Ein wichtiger Punkt fehlt dort: Ordentliches Interface verwenden, welches die DMX Timingwerte selbst generiert, z.B. das DE- oder FX5-Interface. Der Rechner muss damit nicht auch noch belastet werden.

* plötzlich im Dunkeln stehen
Das ist ein Punkt am DE-Interface, den ich schon länger kritisiere - aber die Entwickler nicht gewillt sind, ihn zu beheben. Wenn ich das Interface an den USB-Port stecke oder DMXControl beende, ist das Interface ohne erkennbaren Grund im Standby-Modus. Wieso? Das ist insbesondere in Havarie-Situationen fast schon die schlimmste Situation (nach Ausgabe von komplett falschen Daten), die auftreten kann. Der Standby-Modus ist unnütz, das Interface sollte da zumindest 1:1 die Werte vom DMX-In durchschleifen. Somit hätte man bei 90 % der Fehler sofort eine funktionierende Haverie-Lösung, und muss sich nicht mit Abstecken des Interfaces bis zum Start von DMXControl behelfen.

* nun auch die "Pack&Go"-Funktion an.
So ganz funktioniert das noch nicht, aber ist schon mal ein guter erster Schritt

Auch wenn man alle Punkte berücksichtigt, kann es trotzdem noch zu Abstürzen kommen, auch wenn die Wahrscheinlichkeit schon verringert wird. Softwarefehler können leider noch nicht ganz ausgeschlossen werden (ich hoffe, dass sich das mit automatisierten Tests und DMXControl 3 verbessert).
Mir ist DMXControl 2.9 (?) im Live-Betrieb mehrfach wegen eines Bugs abgestürzt - und das war eine so "einfache" Funktion, bei der ich es nicht erwartet hätte - oder wer erwartet schon, dass DMXControl abstürzt, wenn man einen laufenden Effekt von "Normal" auf "Zufällig" stellt? Das sind halt dann Details, die ich im Vorhinein nie getestet hatte, dort keinen Fehler erwartet habe, und dann beim Live-Betrieb zum Totalabsturz führen.

Freundliche Grüße

Stefan

Quote from Markus M.

Wobei man auch bedenken muss, dass der die ganzen Berechnungen macht und nicht nur allein für die Ausgabe zuständig ist.

"Berechnungen" - genau dafür ist die CPU da, und darauf ist sie ausgelegt. Berechnungen sind das einfachste, mit was du einen Computer (= zu deutsch Rechner) überhaupt behelligen kannst. Genau aus dem Punkt verstehe ich nicht, wieso man DMXControl mit dem langsamen Farbübergang z.B. von LED-PARs zuverlässig gut auslasten kann. Das sind einfachste mathematische Funktionen, die da benötigt werden, nicht mehr.

Lass mal MADRIX mit ner 8 x 32 Matrix (= 256 Kanäle) und z.B. nem Sound-Analyzer laufen (und mit DE-Interface, wie es DMXControl auch verwendet). Dort ändert sich so gut wie jedes Pixel der Matrix ständig, und trotzdem bleibt die CPU-Auslastung ohne Probleme im grünen Bereich.

Quote from JPK

Und es sollte auch nicht all zu schwer sein, das umzusetzen.

Du redest hier von einer fundamentalen Änderung in der Architektur von DMXControl - egal wie schwer das sein möge, das muss ordentlich geschrieben und ausgiebig getestet werden. Bis das so weit ist, halten wir DMXControl 3 bereits in Händen. Nicht zu vergessen: Der Beta-Test läuft bereits.

Freundliche Grüße

Stefan

Meine Aussage nezog sich eher auf die Stabilität. Die GUI ansich ist total dumm.
Der Kern berechnet alles etc. von daher währe dort eine einfach gestrickte Ausgabeebene auch nicht verkehrt.

Was die Performance von DMXC 2.x angeht liegt das wohl eher daran, dass alles in einem Thread abläuft.
Also auch die ganze grafische Darstellung.
Zum Beispiel sollte man die Kanalübersicht lieber zu machen, da die wirklich sehr viel Leistung schluckt, wenn sich viele Kanäle aufeinmal ändern.
Daher sollte man alle grafischen Elemente bei denen sich viel auf der Oberfläche animiert ist schließen.

Quote from Markus M.

die Kanalübersicht lieber zu machen, da die wirklich sehr viel Leistung schluckt

Hm, das höre ich zum ersten Mal, das ist das Fenster, was ich standardmäßig als erstes offen habe... (u.U. sogar im Vollbild auf einem extra Bildschirm) Danke für den Hinweis.
Nimm das doch bitte auch noch in den Wiki-Artikel auf.

Habs gerade nochmal getestet.
Irgendwie kams mir beim letzten Mal mehr vor. Habs gerade nochmal getestet.
Soviel isses wohl doch nicht, sind schätz ich mal 5% CPU-Last weniger wenn zu.