TCP-IP "Echtzeit" Datenverarbeitung

We proudly present: The release of DMXControl 3.3.3!


On September 29, 2026, we held our release show for DMXControl 3.3.3. During our usual “hour-long” session, we showed you all the new features in this version and what it now has to offer.
Read all about it in the corresponding news article: We proudly present: The release of DMXControl 3.3.3!


  • Hallo liebes DMC Control Team,

    mal eine Frage abseits vom Licht. Ich habe gerade jobmäßig Schwierigkeiten Windows eingehende TCP-IP Daten ungeachtet der Windows CPU-Auslastung zeitnah ~ alle 100ms zu verarbeiten. Immer wenn das System ausgelastet ist (reichen schon 50-70%), dann bekommen ich am Eingang der .NET Verarbetungskette ein spurbares Delay (Sekunden). Ihr hattet ähnliche Anforderungen mit z.B. DMX-In. Das geht ja auf native APIs. Unter Stackoverflow findet man wertvolle Info´s, jedoch speziell das "Lastverhalten" und den damit verbundnenen Delay nicht.

    Wenn ihr so nett seid, könntet ihr mir ein paar Stichwörter zurücksenden? Multimedia-Timer? Es geht nicht um Licht, sondern Maschinendaten, also keine Sorge :)

    Lieben Dank schon mal.

    Viele Grüße

    Sascha

  • Hallo Sascha,

    Generell ist das ein mit Windows effektiv nicht lösbares Problem. Windows ist kein Echtzeitbetriebssystem bei welchem du die Sicherheit hast, dass Programme in regelmäßigen, deterministischen Abständen ausführt.

    Man kann in Windows mit Prozesspriorität versuchen das irgendwie zu beeinflussen aber wirklich Sicher ist das nicht. Nicht umsonst hat man im Maschinenumfeld SPS Steuerungen mit einem deterministischen Laufzeitverhalten.

    Gruß

    Das Leben ist NP vollständig!

  • Hallo Soon5,

    besten Dank für deine Rückmeldung. Ja, die Einschränkungen sind leider so wie beschrieben. Es gibt jedoch auch unter Windows Möglichkeiten etwas "performanter" Netzwerkdaten zu bearbeiten. Ein Stichwort ist z.B. den ‚Nagle’s algorithm' auszuschalten. (https://en.wikipedia.org/wiki/Nagle%27s_algorithm). Ich habe bei dem DMX4ALL bei euch z.B. gesehen, dass dies nativ genutzt wird. Native Anwendungen können einige Optionen per API einfacher setzen, die unter .NET so nicht möglich sind. Ich hatte kurz die Vermutung, dass dies aufgrund der Performance so gemacht wurde. Aber vermutlich nicht.

    Kurz gesagt wollte ich einfach nur Fragen, ob irgendwelche Anstrengungen unternommen worden sind dafür zu sorgen, dass TCPIP Daten auch bei moderater Auslastung unter Windows zeitnah für DMXControl verarbeitet werden, so dass keine merkwürdigen unregelmäßigen zeitlichen Abfolgen bei der DMX-Steuerung entstehen? Wenn ihr das Problem nicht hattet, umso besser! Glückwunsch, weiter so.

    Auf jeden Fall danke.

    Viele Grüße

    Sascha

  • Ne Seiteninfo bezüglich Echtzeitfähigkeit von Windows: In der Industrie gibt's das Problem auch, Beckhoff bietet hier mit TwinCAT eine Windows-Software an, die EtherCAT (ein Echtzeit Netzwerkprotokoll) ausgeben kann. Das ist aber nicht mit der Windows-Software gelöst, sondern die bindet sich tief in den Netzwerk-Treiber ein (unterstützt auch nicht alle Hersteller) und funktioniert je nach Treiber besser oder schlechter.

    Also theoretisch möglich ist es - praktisch tust du dir (wie bei vielen anderen Sachen) leichter, wenn du auf Windows und Microsoft-Produkte verzichtest.

  • dann bekommen ich am Eingang der .NET Verarbetungskette ein spurbares Delay (Sekunden)

    Trotzdem darf das Delay nicht bei Sekunden liegen, denn egal ob echtzeitfähig oder nicht sind die Input-Delays nicht so groß. Ist da evtl. noch irgendwas in deinem Netzwerk-Stack falsch konfiguriert?

    im Falle eines Falles klebt Gaffa einfach alles, denn Gaffa ist dein Freund und Helfer :thumbup:

  • Newly created posts will remain inaccessible for others until approved by a moderator. The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.