[WireGate-Plugin] Darf's ein bisschen schneller sein?

[Fry]

Hallo zusammen,

EXPERIMENTAL - wie immer!

Zusätzlich zu den Vorschlägen in diesem Thread habe ich gerade noch etwas gefunden:

Der Wiregate-Daemon macht momentan in einer Endlosschleife folgendes:

* Prüfung, ob ein KNX-Telegramm anliegt (warte auf Timeout), falls ja, wird EIN Telegramm abgearbeitet. Das bedeutet Logging in /var/log/eib.log, evtl. Kommunikation über 1-wire, Management-VPN aus/an, Zeit/Datumsanfrage beantworten, und passendes Plugin ausführen. Es wird aber nur EIN Telegramm so abgearbeitet, dann geht es wie folgt weiter.

* Prüfung, ob irgendein Plugin nach seinem cycle gerade fällig ist

* update_rrd einiger Systemparameter

* Prüfung, ob Daten an einem Socket anliegen (warte auf Timeout)

* falls fällig, Zeit/Datum versenden

* Dann wieder zurück nach oben (Endlosschleife)

Dies führt speziell in dem Fall, dass das Wiregate selbst viele Telegramme versendet (etwa aus Logiken des Logikprozessors, oder aus anderen Plugins) dazu, dass das Wiregate teilweise sehr verzögert reagiert. Hauptgrund ist, dass in jeder Schleife nur EIN Telegramm abgearbeitet wird, selbst wenn 10 Stück anliegen. Der lange Timeout trägt nicht zum Problem bei, weil er ja nur anfällt, solange kein Telegramm kommt. Aber er ist m.E. mit einer halben Sekunde zu großzügig angesetzt. Und der Timeout-der Socketabfrage (0.1s) fällt fast jedesmal an, so dass die Anzahl der verarbeitbaren Telegramme deutlich unter 5 pro Sekunde liegt.

Abhilfe ist einfach:

in /usr/sbin/wiregated.pl die Zeile mit

if ($select->can_read(.5)) {

suchen und durch

while ($select->can_read(.1)) {

ersetzen. Danach den daemon neu starten mit

/etc/init.d/wiregated restart

Und weg sind die Verzögerungen.

Analog gilt das Gleiche für Jumis knxd.

Ich habe hier nun manchmal 20 und mehr Telegramme in einer Sekunde, insbesondere wenn das Plugin Szenencontroller oder die Ebus-Kommunikation laufen. Die erzeugen nämlich immer einen ganzen Schwung Telegramme. Bisher führte das dazu, dass das Wiregate einige Sekunden brauchte, um den KNX-Bus abzuarbeiten. Jetzt nicht mehr.

Have fun,
Fry

[Fry]

Nach einem Tag Testung: mein Szenencontroller funktioniert nun endlich auf Knopfdruck SOFORT, auch der Russound-RIO.pl von ChrisM ist akzeptabel ("Realtime"), die Logiken ebenfalls, ....

Zusammenfassend @StefanW: ich schlage vor, diese Änderung sowie das Vorkompilieren in die nächste Release zu übernehmen. Dafür könnt ihr das Projekt, den wiregated.pl in C neu zu programmieren oder die Plugins in einem separaten Thread abzuarbeiten (wiregated.pl ist single-thread), vermutlich beenden. Zumindest in meiner Installation ist nun alles so, wie ich es mir von Anfang gewünscht hätte.

@alle: wer es auch ausprobiert - ich wäre dankbar für Feedback hier im Thread.

VG, Fry

[Fry]

...und noch was: Makkis ständige Schüsse gegen Perl (Memleaks, Geschwindingkeit) waren, nun ja, nicht nötig. Perl macht einen hervorragenden Job, und der wiregated.pl hätte in keiner anderen, mir geläufigen, Sprache diese Fähigkeiten entfaltet*

Have fun,
Fry

*Ausnahme sind möglicherweise Skriptsprachen, bei denen Perl-Elemente übernommen wurden.

[luigi4711]

kurze Rückfrage, Du änderst nicht nur von .5 auf .1, sondern auch if durch while, ist das richtig?

[Fry]

Ja, genau. Die Änderung if -> while ist die Hauptsache.

[ctr]

Könntest Du das bitte nochmal etwas im Detail erläutern? Eine Timingänderungen ist ja recht trivial und leicht zu erklären, aber was ändert sich denn in Deiner beschriebenen Endlosschleife durch die Verwendung von while statt if? Wenn es vorher schon eine Schleife gewesen ist, hast Du dann mit dem while nicht einfach nur eine zusätzliche Schleife geschaffen?

[StefanW]

Er sendet damit die KNX Pakete solange (while) welche anstehen und nicht nur ein Paket wenn mindestens eines (if) ansteht.

Stefan

[Fry]

Oben erklärt. Die Wartezeit bis zum Socket-Timeout begrenzt die Anzahl der verarbeitbaren KNX-Telegramme. Mit "while" bekommt der KNX-Bus (sowie 1-wire) absolute Priorität über Socket-Kommunikation. Das ist zumindest in meiner Installation das richtige.
Man kann das evtl. noch verfeinern, aber schaut es euch erstmal an - trust me & try it! Und gebt hier bitte Feedback über eure Erfahrungen damit.
Fry

[ctr]

Ergeben sich dadurch evtl implizit Probleme wenn merhfach Daten vom KNX abgearbeitet werden ohne die restlichen Funktionen der Endlos-Schleife zu gehen? Wenn mehrere den KNX Telegramme Socket-Kommunikation erzeugen/benötigen und/oder auf RRDs zugreifen?

In der if Variante wird das alles pro Telegramm abgearbeitet während es so zig Telegramme geben könnte bevor der Rest angetriggert wird. Könnte das in Situationen hoher Busauslastung (Programmierung?) unter Umständen zu Problemen führen?

[Fry]

Deshalb meine ich ja, es muss getestet werden.

Vor dem if/while-Patch ist es aber so, wenn mein Szenencontroller/Logikprozessor/Schluesselbrett/Ebus/CometVisu... (fast alles Wiregate-Plugins) so 10+ Telegramme absetzt, ist das Wiregate bis zu 30s blockiert, weil es Telegramme durchliest. In dieser Zeit hängt das WG hinter dem KNX-Bus. Es "vergisst" keine Telegramme, dafür sorgt der eibd, aber die Abarbeitung durch den wiregated.pl hängt hinterher.

Nach dem Patch ist das WG WESENTLICH zackiger. Nun ist es tauglich für "Echtzeitlogiken". Ich merke das vor allem am Szenencontroller. Mit dem simplen if/while-Patch (und dem Vorkompilieren der Plugins) ist der Szenencontroller nun so schnell, dass mit einem Tastendruck am Lichtschalter eine Szene (bis zu 20 KNX-Telegramme) SOFORT und AUF EINEN SCHLAG ausgelöst wird. Vorher war da oft eine längere Wartepause, weil zB gerade ein Schwung zyklischer Telegramme des Ebus-Plugins oder der CometVisu abgearbeitet wurden.

Neue Probleme erwarte ich übrigens nicht. Nur in Extremfällen (stark belasteter KNX-Bus) kann es sein, dass von außen kommende Socket-Kommunikation langsamer ist.

VG, Fry

[ctr]

Gebe Dir ja durchaus recht, das beantwortet übrigens vermutlich auch meine Beobachtung hier:
https://knx-user-forum.de/286140-post44.html

Wollte nur mal in den Raum werfen wo es potentiell krachen können, weil eine grundsätzliche Annahme (sobald ein Telegramm empfangen wird, kann es in den folgenden Funktionen abgearbeitet werden) nicht mehr zutrifft.

[Fry]

Wollte nur mal in den Raum werfen wo es potentiell krachen können, weil eine grundsätzliche Annahme (sobald ein Telegramm empfangen wird, kann es in den folgenden Funktionen abgearbeitet werden) nicht mehr zutrifft.

Stimmt nicht. Lies nochmal oben. Die Socket-Kommunikation bezieht sich auf INPUT, nicht OUTPUT.

Beispielsweise funktioniert das Russound_RIO-Plugin weiterhin unverändert.

Du müsstest also schon ein Beispiel konstruieren, wo ANKOMMENDE KNX-Telegramme und ANKOMMENDE Socket-Kommunikation unbedingt so verzahnt werden müssen, dass es mit der o.g. Modifikation "kracht".

[Chris M.]

Beim Durchlesen der Threads komme ich gerade durcheinander: geht es um Lesen (also Pakete die an die Logik gehen) oder um Senden (also Pakete die in der Logik generiert werden)?
(Oder gar beides?)

[Fry]

Es geht eigentlich ums Lesen. Wenn auf dem Bus 20-30 Telegramme innerhalb einer Sekunde kommen, braucht das (unmodifizierte) WG schon mal eine Weile, bis es die abgearbeitet hat. Es "vergisst" kein Telegramm, kommt aber kaum hinterher.

Ums Schreiben geht es nur in dem Sinne, dass das WG durch Logiken o.ä. durchaus eine Quelle vieler Telegramme sein kann, die im Umkehrschluss genau zu dem o.g. Problem führen.

Hoffe, jetzt ist es verständlich.

VG, Fry

[Fry]

Kurzer Zwischenstand: der Logikprozessor verwaltet nun 661 Logiken. Unter anderem zeitkritische Lichtlogiken. Alles ohne merkliche Verzögerung.

Ich sehe das als echten Durchbruch:

* "Vorkompilieren" der Plugins
* %plugin_cache
* while statt if in der Hauptschleife

@StefanW: bitte überlegt doch mal, ob ihr diese Änderungen nicht in den Hauptentwicklungszweig des wiregated.pl übernehmt. Sonst könnte es nämlich passieren, dass ich bald den Logikprozessor und andere Plugins nicht mehr kompatibel zum alten Wiregate halten kann/will, weil mir die Testplattform fehlt.

VG, Fry