DMX-Control 2.1.2 nutzt nur ein CPU Kern beim i5

Quote from MrIncredible

Die anderen drei Kerne machen nichts, somit wird die Rechner-CPU nur 1/4 ausgenutzt.

Gibt es da einen Patch oder ähnliches bzw. eine Einstellung, wie man die die CPU vollständig nutzen kann?

Nein, da gibt es keinen Patch dafür. Das ist keine einfache Aufgabe ein Programm auf mehrere Kerne/Threads aufzuteilen. Da kann man nicht einfach sagen "nutze alle Kerne".

Du hast hier ein ganz grundlegendes theoretisch Problem gefunden mit dem sich sehr viel in der Informatik auseinandergesetzt wird. Das kann man jetzt nicht umfassend in 3 Sätzen erklären, aber ich versuch es mal ansatzweise.

Ganz einfach ausgedrückt ist ein Programm (wie DMXControl 2) eine Liste von Anweisungen was die CPU nacheinander in genau der Reihenfolge tun soll. Ein CPU Kern ist eine Einheit die diese Anweisungen abarbeitet.

Wenn du jetzt mehrere CPU Kerne hast bedeutet das, dass du mehrere Anweisungslisten parallel abarbeiten kannst. Aber das ändert nichts daran, dass DMXControl 2 nur eine Anweisungsliste ist. Die kann dann trotzdem nur von einem CPU Kern bearbeitet werden und die anderen tun dann wirklich nichts. Weil die Anweisungen genau in Reihenfolge abgearbeitet werden müssen kann eben ein Programm nicht einfach automatisch auf mehere Kerne zerteilt werden. Das ist ganz grundlegend so und hat jetzt nichts mit DMXControl 2 zu tun. Diese Klasse von Anwendungen sind Single-Thread Anwendungen und dazu gehört eben auch DMXControl 2.

Wenn man jetzt möchte, dass ein Programm mehrere Kerne nutzt, muss man das Programm explizit so schreiben, dass es aus mehreren Threads (=Anweißungslisten hier im Beispiel) besteht. Wenn man mehrere Anweißungslisten hat kann man diese natürlich gut auf mehere Kerne verteilen. Das ist ja einfach wie mehere einzelne Programme nebeneinander starten.

Allerdings muss das von Anfang an beim programmieren berücksichtigt werden und auch entsprechender aufwand betrieben werden. Weil es muss ja dann irgendwo im Programm festgelegt werden, welche Berechung in welchem Thread landet. Dann muss man sich natürlich um Informationsaustausch zwischen diesen Threads bemühen, die Threads syncronisieren, und noch viele weitere Sachen beachten. Das Stichwort hier weiterzusuchen wäre Nebenläufigkeit.

Deswegen muss das unterstützen von mehreren Kernen unbedingt von Anfang an in der Software geplant sein und das ist nichts was man mal so kurz patchen könnte.

Und ganz unabhängig von der Diskussion hier, DMXControl 2 wird wie wir schon an vielen Stellen bekannt gegeben haben nicht mehr weiterentwickelt. Es wird keine Patches mehr dafür geben.

Aber das mit dem Multithreading wäre z.B. ein Problem warum DMXControl 2 nicht mehr weiterentwickelt wird, sondern mit DMXControl 3 alles neu gemacht wurde. Natürlich gibt es für DMXControl 3 noch viele weitere weit wichtigere Punkte warum wir das ganz neu gemacht haben, aber der Punkt passt sicher auch dazu.

Viele Grüße

Moritz

Hallo und herzlich willkommen im Forum,

ein weiterer Ansatzpunkt sind die Enttec-Interfaces. Deren Ausgabeplugin belastet den PC recht stark, weil hier die Interfaces das DMX-Signal nicht selbst berechnen können. So muss DMXControl 2 erst die DMX-Werte an das Plugin senden und dieses muss alle Daten auf dem DMX-Bus generieren und diese 44 mal die Sekunde an das Interface schicken. Besser sind hier aktive Interfaces, die das Signal selbst berechnen können und somit der Treiber nur noch die DMX-Werte an das Interface schicken muss und auch nur, wenn sich diese geändert haben. Aktive Interfaces wären z.B. das Digital Enlightenment bzw. das fx5-Interface, unser Nodle-Interface und die Art-Net-Interfaces von Ulrich Radig (es gibt aber auch noch einige andere).

Was du trotzdem mal testen kannst ist, den Taskmanager öffnen (Rechtsklick auf die Taskleiste=>Task-Manager) und dort auf die Prozess-Seite (unter Windows 10 "Details") gehen. Mach einen Rechtsklick auf den Prozess von DMXControl 2 und klicke auf "Zugehörigkeit festlegen". Im sich nun öffnenden Fenster machst du einen Haken bei allen CPU-Kernen und schließt das Fenster nun wieder. Nun kann der DMXControl 2-Prozess durch Windows dynamisch zwischen den Prozessorkernen hin und her geschoben werden. Dadurch kann zwar DMXControl 2 trotzdem nur auf einem Kern berechnet werden, aber die CPU-Leistung kann besser ausgenutzt werden. Das erhöht etwas die effektive Ausführungsgeschwindigkeit (zumindest in meinen bisherigen Tests lief DMXControl 2 dadurch immer etwas flüssiger). Allerdings hat das zwei Nachteile: Zum einen musst du diese Prozedur bei jedem Neustart von DMXControl 2 erneut ausführen. Außerdem kann diese Verteilung u.U. (aus eigener Erfahrung) zu Problemen beim Speichern von Szenen kommen. Daher das ganze nur im Normalbetrieb durchführen und nicht während du neue Szenen programmierst. Dann klappt das aber doch recht gut.

Viele Grüße

JP

Quote from MrIncredible

Gilt diese "Selbstständigkeit" für alle Art-Net-Interfaceses?

Ja, denn das ist rein technisch bedingt. Art-Net-Pakete sind im Grunde auch nur DMX-Werte, die an das Art-Net-Interface geschickt werden (mit etwas Netzwerk-Packet-Gedöhns außen herum). Daher baut dann das Art-Net-Interface auch das DMX-Signal selbst.

Zu dem passenden Rechner: Naja, es kommt halt darauf an, was du machen möchtest. Ich kann nur sagen, wie das bei mir bzw. meinen Veranstaltungen ist (hauptsächlich Theater/Musicals und musiksynchrone Lightshows . Wenn ich DMXControl 2 nutze, verwende ich meinen PC, mit einem Intel Core i5-2500K (nicht übertaktet), 2 Displays und ein Nodle- bzw. zwei DE-Interfaces. Das reicht ganz gut, wobei ich bei sehr vielen gleichzeitigen Änderungen + Audioausgabe ohne die Verteilung auf mehrere Kerne mit meiner Beschreibung oben (bei mir 4 Kerne) manchmal Ruckler habe. Deshalb mache ich auch diese Verteilung auf die Prozessorkerne. Wichtig ist dabei auch, dass Easy View auf einem anderen Kern wie DMXControl 2 läuft (ist standardmäßig auf dem selben). Aber ich belege normalerweise auch mindestens 100 bis 150 DMX-Kanäle bei meinen Veranstaltungen (so mal als Hausnummer). Generell sollte der PC schon etwas Leistung haben, damit etwas Reserve da ist. Aber eine genaue Aussage ist da leider schwer zu treffen.

Viele Grüße

JP

Joa das mit den zwei Kernen dürfte so hinhauen. Wie gesagt kann dann halt Windows DMXControl 2 auch auf einen anderen Kern schieben, wenn plötzlich ein Kern mit einer anderen Anwendung belastet wird. Aber noch mehr verteilen wirst du es nicht können, denn Windows ist da schon verhältnismäßig intelligent, was das angeht. Doch bevor du nun nach einem anderen PC schaust, würde ich erst einmal ein anderes Interface ausprobieren. Damit sollten schon sehr viele Probleme gelöst sein und das ganze deutlich flüssiger laufen. Erst danach würde ich mir Gedanken über einen anderen PC machen. In diesem Fall kannst du auch mal unter https://www.cpu-monkey.com/de/ CPUs vergleichen und welche finden, die eine hohe Single-Core-Leistung haben.

Aber noch ein weiterer Punkt: Was hindert dich, auf DMXControl 3 zu wechseln (aus reine Neugier)?

Viele Grüße

JP

Edit: Oh, das mit den Art-Net-Interfaces ganz vergessen Also ganz gut sind die Interfaces von Ulrich Radig (https://www.ulrichradig.de/home/index.php)

Das mit dem Art-Net-Interface hatte ich kurz nachdem du geschrieben hast noch ergänzt. Das hat sich etwas überschnitten mit deinem Post

Was stört dich an der Oberfläche von DMXControl 3? Zu überladen, zu unübersichtlich, zu versteckte Funktionen? Solche Infos helfen uns zu überlegen, was den Einstieg in DMXControl 3 erleichtern kann. Zur Commandobox kann ich aber schon mal sagen, dass mit DMXControl 3.2 ein würdiger Nachfolger kommt. Da kann man sich dann komplette virtuelle Pult-Oberflächen selbst bauen, also nicht nur Buttons, sondern auch Fader etc. Dass alles schon in DMXControl 2 programmiert ist, ist natürlich ein starkes Argument, weil die Übertragung eine Neuprogrammierung der Lichtstimmungen ist. Allerdings geht das doch etwas schneller als mit DMXControl 2 und man ist an einigen Stellen flexibler. Ich bin mit einigen Sachen eigentlich noch auf das Textbuch, Audioszenen und den Audioplayer von DMXControl 2 angewiesen, aber wo es geht, versuche ich mittlerweile DMXControl 3 zu verwenden, weil das Programmieren eben schneller geht.

Viele Grüße

JP

Hi,

auch wenn Dein Problem jetzt gelöst zu sein scheint, habe ich noch eine Möglichkeit parat:

Versuche mal die Wiederholungsrate auf 20 runter zu setzen. Das bedeutet, dass weniger als die Hälfte an Daten an das Enttec geschickt werden.

Ich benutze neben dem selbst aufgebautem FX5 einen "USB to RS485-Converter", der bauähnlich zu dem Enttec ist (und auch so von DMXC angesprochen wird) mit dieser Wiederholungsrate.

Die Halbierung der Rate merke ich nicht - eher habe ich den Eindruck, dass meine China-MH's so sogar weniger Fehler machen.

Grüße

Markus