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
suchen und durch
ersetzen. Danach den daemon neu starten mit
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
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
Code:
if ($select->can_read(.5)) {
Code:
while ($select->can_read(.1)) {
Code:
/etc/init.d/wiregated restart
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
Kommentar