Paralleles verarbeiten von Befehlen?

[meti]

Ich hab hier den Nachfolger BAOS 771 (~2012) liegen. Der schickt falsche Längenangaben in L_Data.Con Frames. Das war bis ETS 5 egal, dann wurde das geprüft und nix funktioniert mehr. Evtl ist das bei dem Vorgänger und knxd ähnlich.

(Siehe auch https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/851441-verbindungs-probleme-ets5-mit-weinzierl-knx-ip-baos-771?p=898347#post898347 )

[Smurf]

Du kannst problemlos eine Sendeverzögerung einbauen, das geht mit dem "pace"-Filter, siehe Doku.

Wahrscheinlich speichert das BAOS-Ding gar kein Paket zwischen, und ihm ist der knxd zu schnell. Sowas nennt sich "fataler Programmierfehler". Es gehört sich einfach nicht, den Empfang eines Pakets zu quittieren, wenn man es dann wegschmeißt.

Und ja, die bessere Idee ist (leider), ein aktuelles Gateway zu kaufen. Mit solchem Unfug will man sich nicht wirklich rumschlagen.

[Raudi]

Hmm... Danke für den Tipp, aber das scheint doch etwas anderes zu sein, denn hier funktioniert es ja grundsätzlich, nur der knxd schickt scheinbar seine Frames via TCP raus, so wie er sie rein bekommt, und das nicht in sortierter Reihenfolge. Ein Kommando ist noch nicht abgeschlossen, da kommt schon der Start für das nächste.

Wenn ich versuche die Ausgabe vom tcpdump mal den einzelnen Kommandos zuzuordnen, dann würde ich diese Reihenfolge interpretieren:

A-1 17:03:01.520100 IP srv44.42930 > 192.168.77.50.3671: UDP, length 21
A-2 17:03:01.528550 IP 192.168.77.50.3671 > srv44.42930: UDP, length 10
B-1 17:03:01.537150 IP srv44.42930 > 192.168.77.50.3671: UDP, length 21
B-2 17:03:01.545161 IP 192.168.77.50.3671 > srv44.42930: UDP, length 10
B-3 17:03:01.548165 IP 192.168.77.50.3671 > srv44.42930: UDP, length 21
B-4 17:03:01.548269 IP srv44.42930 > 192.168.77.50.3671: UDP, length 10
A-3 17:03:01.553087 IP 192.168.77.50.3671 > srv44.42930: UDP, length 21
A-4 17:03:01.553135 IP srv44.42930 > 192.168.77.50.3671: UDP, length 10
C-1 17:03:01.554203 IP srv44.42930 > 192.168.77.50.3671: UDP, length 21
C-2 17:03:01.564553 IP 192.168.77.50.3671 > srv44.42930: UDP, length 10
D-1 17:03:01.571314 IP srv44.42930 > 192.168.77.50.3671: UDP, length 21
D-2 17:03:01.579454 IP 192.168.77.50.3671 > srv44.42930: UDP, length 10
D-3 17:03:01.582426 IP 192.168.77.50.3671 > srv44.42930: UDP, length 21
D-4 17:03:01.582485 IP srv44.42930 > 192.168.77.50.3671: UDP, length 10
C-3 17:03:01.587604 IP 192.168.77.50.3671 > srv44.42930: UDP, length 21
C-4 17:03:01.587723 IP srv44.42930 > 192.168.77.50.3671: UDP, length 10
E-1 17:03:01.588365 IP srv44.42930 > 192.168.77.50.3671: UDP, length 21
E-2 17:03:01.599267 IP 192.168.77.50.3671 > srv44.42930: UDP, length 10
E-3 17:03:01.619795 IP 192.168.77.50.3671 > srv44.42930: UDP, length 21
E-4 17:03:01.619937 IP srv44.42930 > 192.168.77.50.3671: UDP, length 10

Ich glaube bei dem Versuch wurden auch 3 Jalousien angesteuert. Also bei 3 Kommandos waren die Frames in der korrekten Reihenfolge (B,D,E), 2 Komandos wurden durch andere unterbrochen (A,C).

Ich kann natürlich nicht sagen, ob das eine Eigenschaft vom BAOS ist, oder ob andere IP Interfaces damit klar kommen. Der BAOS scheint damit aber ein Problem zu haben.

[Raudi]

Wird durch die "Sendeverzögerung" denn alles gleich verzögert? Weil es kommen ja 5 Pakete nahezu zur gleichen Zeit rein und wenn die alle gleich verzögert werden, dann ist das Ergebnis ja gleich.

Das BAOS Teil braucht vermutlich eine Funktion, wo die Anforderungen im knxd in eine Queue gespeichert werden und dann Kommando für Kommando übers Netzwerk rausgeschickt werden.

[Raudi]

Ich habe mal die Zeile in der knxd.conf wie folgt angepasst:

KNXD_OPTS="-e 1.2.65 -E 1.2.66:24 -B pace -c -u /tmp/eib -b ipt:192.168.77.50"

Aber gleiches Verhalten. Das ist doch korrekt so, oder?

● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-10-17 21:16:56 CEST; 10min ago
TriggeredBy: ● knxd.socket
Main PID: 2434678 (knxd)
Tasks: 1 (limit: 4575)
Memory: 572.0K
CPU: 313ms
CGroup: /system.slice/knxd.service
└─2434678 /usr/bin/knxd -e 1.2.65 -E 1.2.66:24 -B pace -c -u /tmp/eib -b ipt:192.168.77.50

Da stehen die Parameter jedenfalls...

Zum testen habe ich auch nun einfach die 5 Zeilen in eine Datei geschrieben und ausgeführt. Die wurden dann schnell nacheinander ausgeführt, was aber scheinbar zu schnell ist. Denn von den 5 Kommandos wurden wieder nur 3 ausgeführt.

Aber mal ne bescheidene Frage: Wo finde ich die Doku? Oder sagen wir mal eine Seite auf der die möglichen Filter beschrieben stehen...

Im Readme steht:

In v0.14, the main queueing system will pace packets for the slowest device. If you don't want that, use the "queue" filter on the slow device(s).

Also evtl. auch mal queue testen? Oder was macht queue?

[Smurf]

Wird durch die "Sendeverzögerung" denn alles gleich verzögert?

Natürlich nicht. Mir ist durchaus klar, dass das nix bringen würde.

Wieso liest du nicht einfach die Doku? Da steht drin was der Filter tut – nämlich genau das, was dein kaputtes(sorry) Modul braucht.

[Smurf]

Dein Befehl ist so nicht korrekt. Ein Filter muss direkt vor der Schnittstelle angewendet werden, die er beeinflussen soll. Nicht irgendwo sonst.

Die Doku ist im Source in der Datei "doc/inifile.rst".

[Raudi]

Würde ich gerne, aber ich habe die Doku noch nicht gefunden... Ich habe schon auf der git Seite das Wiki gewälzt, aber auch da noch nichts gefunden, sorry. Oder habe ich Tomaten auf den Augen? 🤔

[bmx]

Guckst Du hier https://github.com/knxd/knxd/blob/main/doc/inifile.rst

[Raudi]

Ja, habe ich nun auch gefunden...

Aber komplizierter geht es nicht.

Da gibt es eine /etc/default/knxd, die aber in einer systemd Umgebung nicht verwendet wird, da kommt die /etc/knxd.conf zum Einsatz, darin soll aber nun auf eine /etc/knxd.ini verwiesen werden.

Anstatt in der /etc/knxd.conf eine Beispiel Parameter Zeile zu schreiben, warum aktiviert man nicht gleich den Parameter für die knxd.ini und macht das Beispiel in die ini-Datei...

Das muss man erstmal alles durchblicken...

Und Dokumentation, da steht so vieles im Wiki, da suche ich doch dort. Die inifile.rst hatte ich unter Doc sogar schon gesehen, aber bin nicht auf die Idee gekommen, dass eine Datei mit der Endung "rst" was zum lesen ist...

O.k. ich teste mal weiter und werde berichten...

Aber besten Dank für die Hinweise! 👍

[Raudi]

o.k. ich denke nun habe ich es verstanden:

# /usr/lib/knxd_args -e 1.2.65 -E 1.2.66:24 -c -B queue --arg=delay=250 -B pace -b ipt:192.168.77.50
[B.pace]
delay = 250
filter = pace
[C.ipt]
driver = ipt
filters = queue,B.pace
ip-address = 192.168.77.50
[main]
addr = 1.2.65
cache = A.cache
client-addrs = 1.2.66:24
connections = C.ipt
systemd = systemd

Und die Ausgabe dann in die knxd.ini.

Und was soll ich sagen, es sieht gut aus, so funktioniert es nun. 😉

Nochmals vielen Dank!

[Smurf]

Superb.

Kannst du das bitte ohne delay=250 ausprobieren und berichten, ob es dann immer noch funktioniert? Die Standardeinstellungen sollten nämlich eigentlich genau passen für solche Situationen; wenn nicht, mag ich sie korrigieren.

[Smurf]

und ja ich weiß dass das auch einfacher geht, ich bin nur der Einzige der sich um den knxd kümmert im Moment, und er steht auf meiner Prioritätenliste zu weit unten. Leider.

[Raudi]

Gewachsene Strukturen, wie man so schön sagt... Werde ich heute Abend noch mal testen...

[Raudi]

Jau, delay weg gelassen und funktioniert auch, hatte irgendwie ein besseres Gefühl mit... 😉

# /usr/lib/knxd_args -e 1.2.65 -E 1.2.66:24 -c -B queue -B pace -b ipt:192.168.77.50
[B.ipt]
driver = ipt
filters = queue,pace
ip-address = 192.168.77.50
[main]
addr = 1.2.65
cache = A.cache
client-addrs = 1.2.66:24
connections = B.ipt
systemd = systemd