Schaltverzögerung Weinzierl 730

[henfri]

Hallo,

vielen Dank. Ich werde es testen, sobald ich die v0.14 kompiliert kriege.

Gruß,
Hendrik

[Smurf]

Also. Das "Pace"-Modul macht Folgendes.

• wenn ein Paket gesendet wird, dann geht der Status auf BUSY und der Timer startet. Der endet, wenn das Paket (voraussichtlich) auf den Bus gesendet wurde.
• Vor Ablauf des Timers empfangene Pakete werden gezählt.
• wenn der Timer abläuft, und zwischendrin Pakete gekommen sind, wird der Zähler wieder auf Null gesetzt und weiter gewartet.
• Ansonsten (d.h. der Zähler ist immer noch Null) geht der Status auf IDLE und das nächste Paket wird abgerufen (das ist das "Filter::send_Next();" am Ende von "timer_cb").
• Wenn der Timer nicht läuft, dann werden ankommende Pakete auch nicht gezählt und führen folglich auch nicht zu irgendeiner Verzögerung.
• Dass das Problem nur bei einer einzigen Adresse auftritt, ist in dieser Form unmöglich. Wie soll das gehen? der Verzögerungscode greift nicht auf irgendwelche Adressen zu.

So. Wenn das Problem trotzdem auftritt, dann muss man sich wohl mit dem Debugger an den knxd hängen und gucken was da passiert. Insbesondere haben die Zähler für ankommende Pakete in dieser Methode gefälligst Null zu sein, schließlich hat sie der letzte timer_cb-Aufruf gelöscht.
Alternativ könnte man zumindest ein Log ins Netz stellen in dem das auftritt, nicht nur die Zeile die das Problem meldet. Insbesondere muss da auch die "out:"-Zeile drin vorkommen, mit der PaceFilter::send_Next() den Timer startet.

NB: Bitte mit der aktuellen Version testen!

[Smurf]

Ich schaus mir gleich mal an.

[henfri]

Hallo,

Smurf / Matthias:

Das hier diskutierte Problem

Good case:
Layer 2 [12:C.pace/B.ipt 30.488] in 2/2 0.030000/0.001000/0.750000: delay more, for 0.046 sec

Bad case:
Layer 2 [12:C.pace/B.ipt 558.147] in 99/4 0.030000/0.001000/0.750000: delay more, for 2.230 sec

Ein Blick in den Code zeigt, dass das Problem die Variable nr_in ist, die durch empfangene Nachrichten (recv_L_Data (LDataPtr l)) immer weiter inkremtiert wird und erst von timer_cb zurückgesetzt wird, nachdem eine Nachricht gesendet wurde (wodurch sich die zweite zu sendende Nachricht um Sekunden verzögern kann).

ist das Gleiche, wie dieses, oder?

Gruß,
Hendrik

[schuma]

Bei mir läuft seit ewig die 12. Die funktioniert einfach...

[Tqm]

Bin jetzt auch durch googeln auf diesen Threat gestossen....
Hardware Siemens IP-Router N146
Gibt es nun schon eine Lösung oder habt Ihr nun die Version 0.12 im Einsatz?

[schuma]

Ja, die 12

[henfri]

Welche knxd Version ist eigentlich die letzte, die dieses Problem nicht hat? Ist es die 0.12?

[Theseus]

Hallo zusammen,
die von Smurf eingebauten Traces ergeben folgendes:

Good case:
Layer 2 [12:C.pace/B.ipt 30.488] in 2/2 0.030000/0.001000/0.750000: delay more, for 0.046 sec

Bad case:
Layer 2 [12:C.pace/B.ipt 558.147] in 99/4 0.030000/0.001000/0.750000: delay more, for 2.230 sec

Ein Blick in den Code zeigt, dass das Problem die Variable nr_in ist, die durch empfangene Nachrichten (recv_L_Data (LDataPtr l)) immer weiter inkremtiert wird und erst von timer_cb zurückgesetzt wird, nachdem eine Nachricht gesendet wurde (wodurch sich die zweite zu sendende Nachricht um Sekunden verzögern kann).

Smurf
Könntest du mit dieser Voranalyse nochmal einen Blick auf das Problem werfen? Ich möchte ungern in deinem Code rumbasteln, ohne alle Zusammenhänge von knxd zu verstehen.

Gruß,
Paul

[klotzek]

Hallo Alle,

ich bin durch googeln auf diesen Thread gekommen. Mein Verhalten war ebenfalls, dass der erste Tastendruck, der nach längerer Zeit eingegeben wurde stark, bis in den Minutenbereich, verzögert war. Dann ging's wieder. Das Ganze nur an einer Adresse, die ein Szene ansteuert. Alle anderen Adressen gingen ohne Probleme. Die Szene wird übrigens per Taster und per Bewegungsmelder angesteuert. Bei beiden das gleiche Verhalten.
Ich bin gestern zurück auf 0.12 und das Problem war sofort behoben. Sicher keine elegante Lösung, aber wie sagt man? Tore zählen!

Viele Grüße,
Jürgen

[kgu]

Hallo Zusammen, ich habe das selbe Verhalten wie hier beschrieben. Ich habe einen Raspi 3 der mit einem Gira KNX-Router kommuniziert. Ich habe das Verhalten erst in der SmartVisu vermutet, dann im Apache2 und hatte daher auf die SmartVisu 2.9 umgestellt und auf nginx als Server .. das Verhalten ist jetzt nach der Umstellung so wie oben beschrieben. Vorher mit dem Apache2 hatte ich nach dem ersten Befehl bis zu 10min! Verzögerung. Nach der Umstellung auf nginx und die neue Smartvisu sind es nur noch 45sek .. eine deutliche Verbesserung, aber wenn wir da noch etwas runterkommen, wäre mir das sehr recht. Ansonsten stimme ich Smurf zu.. ich will eigentlich nicht zurück auf die 0.12 von knxd ich hätte gern die neue Version mit verbesserten Verhalten.

Meine Konfiguration-Zeile ist diese hier:
KNXD_OPTS="-u /tmp/eib -e 0.0.1 -E 7.0.100:8 -c -A delay=50 -B pace -b ipt:192.168.178.97"

ich habe den Eintrag von Smurf in der fpace-Datei geändert und wollte knxd neu comilieren. Dabei bleibt aber mein Raspi3 hängen (komplett :/) ich werd es morgen nochmal versuchen. Gibt es hier sonst noch neue Erkenntnisse?

[netzlaff]

Bin nochmal wieder zurück auf die 0.14.24-3 zurück gegangen, da der Updater von OpenHABian mit der installierten 0.12 und den nicht erfüllten Abhängigkeiten zur anderen Pakete nicht mehr klar gekommen ist. Das war letzte Woche Mittwoch oder Donnerstag. Aber wieder keine Änderung. Die darauf folgenden Nächte oder frühen Morgen ist mir der ganze Rechner irgendwann stehen geblieben. Hier konnte ich dann nur noch Aus- und Einschalten. Komischerweise läuft der Rechner seit Samstag bis heute stabil, keine Abstürze und vor allem keine Verzögerungen der Rules und KNX-Trigger. Das macht mir das Debugging noch viel schwerer, auch wenn ich mich freue, dass aktuell alles läuft.

[schuma]

Gucke mal ob Du wirklich auf die 0.12 zurück gegangen bist.

knxd --version

[netzlaff]

Reihe mich jetzt mal ein bei den 0.14-Verzögerern. Ich habe meine alte OH 2.0 Installation durch OpenHABian 2.2 ersetzt, alle Rules etc. mit übernommen und auf die aktuelle 0.14 knxd gesetzt. Seitdem habe ich das Problem, das Rules, welche auf KNX-Veränderungen triggern, zwischen 0 bis auch mal 45 Sekunden verzögert getriggert werden. So ein Verhalten hatte ich vorher nie. Habe dafür unter OH2 schon einen Thread offen, weil ich bis dahin knxd nicht in Verdacht hatte. Jetzt bin ich aber auf diesen Thread gestoßen und würde fast sagen, dass meine Probleme auch hier rühren. Testweise habe ich nun die 0.12 installiert, die ersten Tests, welche ich von der Arbeit aus direkt zu Hause gesteuert habe, zeigten dass die Rules nun wieder sofort (max. 100msec verzögert) getriggert werden, und die Rules sofort greifen.

Ich würde mich auch zu Debug-Zwecken zur Verfügung stellen, ein Wechsel zurück auf die 0.14 wäre kein Thema.

EDIT: Jetzt komme ich nach Hause und schon triggern die Rules wieder nicht ordentlich. Hatte gerade eine Verzögerung von gut 30 Sekunden...

[schuma]

Nur eine kurze Rückmeldung:
Bin jetzt auch wieder auf die 0.12 zurück gegangen.
Und auch bei mir funktioniert nun wieder alles wie gewohnt.
Damit werde ich bei mir den Stand 0.12 einfrieren. Muss ja nur funktionieren, das reicht ja schon.