KNX DISCONNECT_REQUEST kurz nach Mitternacht

[gaert]

Das Backup (egal ob automatisch oder manuell) wird ohne Besonderheiten per TAR (exec) erledigt (zuvor werden diverse DBs geflushed und mit einem write-lock versehen - aber natürlich nicht die KNX-DBs, die sind nämlich im RAM).

Das Ganze wird aber in einem eigenen Prozess gestartet und beeinflusst die KNX-Kommunkation daher nicht - es sei denn, Dein System packt das nicht oder irgendwelche PHP- oder OS-Optionen funken dazwischen.

Die Ursache des Problems muss wohl mit Deinem Setup zu tun haben, sonst wäre dieser Thread hier deutlich lebendiger

[Nanosonde]

Die Ursache des Problems muss wohl mit Deinem Setup zu tun haben, sonst wäre dieser Thread hier deutlich lebendiger

Da hast Du wohl leider recht.

Werde mal weiter forschen....

[Nanosonde]

So, der Fehler ist nun weg.

Offenbar ist es die uralte Kernel-Version (2.6.32) im Zusammenspiel mit der neueren HW gewesen.
Ich nutze nun einfach einen aktuellen Kernel 4.9.10 und das Problem ist plötzlich komplett weg.

Ich habe den neuen Kernel einfach mit "make oldconfig" basierend auf der Config des alten Kernels konfiguriert.
Dabei wurden alle neuen Optionen mit Default-Werten belassen.

Danke an alle für die Kommentare.

[starwarsfan]

Hallo miteinander

So, der Fehler ist nun weg.

Interessant!

Offenbar ist es die uralte Kernel-Version (2.6.32) im Zusammenspiel mit der neueren HW gewesen.
Ich nutze nun einfach einen aktuellen Kernel 4.9.10 und das Problem ist plötzlich komplett weg.

Ich habe den neuen Kernel einfach mit "make oldconfig" basierend auf der Config des alten Kernels konfiguriert.
Dabei wurden alle neuen Optionen mit Default-Werten belassen.

Das hier diskutierte Problem hatte ich auch eine Zeit lang und habe den Thread aus diesem Grund mit grossem Interesse verfolgt. Es wäre gut, wenn Du die genaue Vorgehensweise zum Update des Kernels dokumentieren würdest!

Im Moment habe ich das Problem sporadisch und wenn es auftritt, dann i.d.R. zu einer ziemlich "geraden" Zeit, also bspw. 3-4 Sekunden nach 17:00 Uhr. Aber eben sporadisch und bis jetzt ist es mir (abgesehen von der Zeit des Auftretens) nicht gelungen, irgendein Muster herauszufinden.

Meine Edomi-Instanz läuft als VM mit zwei Cores und 4G Memory unter Proxmox auf einem IBM x3850M2. Auf der Maschine laufen noch eine Handvoll weiterer VMs aber mit 4x Quad Xeon XP und 128G RAM hat es genug Reserven.

Danke an alle für die Kommentare.

Kein Ding, hiermit erneut geschehen.

[Robby]

[TR]
[TD]2017-02-15 00:42:43 496526 KNX 10392 ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=7, Soll-Wert=8 / Raw: 061004200016042507002900bce011285d0502008000 ERROR[/TD]
[TD]2017-02-15 18:19:01 985599 KNX 10392 ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=25, Soll-Wert=26 / Raw: 061004200015042519002900bce011256002010080 ERROR[/TD]
[TD]2017-02-16 13:48:40 009200 KNX 10392 EDOMI @ CE | CONNECTIONSTATE_REQUEST / Timeout nach 5s / ErrMsg: Kein CONNECTIONSTATE_RESPONSE vom Router erhalten ERROR[/TD]
[TD]2017-02-16 13:48:40 020136 KNX 10392 KNX-Verbindung verloren. ERROR[/TD]

Habe auch manchmal das Problem das Edomi die Verbindung zum Router verliert, oder vielleicht auch umgekehrt.

Habe auch einen MDT SCN-IP000.02 und als Hardware ein MSI N3150I ECO Board: Bei mir halten sich die Fehler noch im Rahmen.

[starwarsfan]

Oh, die Info zum IP-KNX-Übergang fehlt noch. Bei mir via Wiregate oder Enertex IP-Interface möglich. Es spielt keine Rolle, was ich verwende, der Mitternachtsfehler ist damals auf beiden aufgetreten, momentan aber nicht mehr vorhanden. Der momentane sporadische Fehler tritt aber ebenfalls auf beiden Schnittstellen auf.

[WagoKlemme]

Ich habe die identische Hardware von Robby und kenne auch den Fehler. Für mich scheint es einen Zusammenhang mit der Anzahl der max. möglichen Anzahl an Telegrammen zu geben (global_knxMaxSendRate), da die IP-Schnittstelle scheinbar einen kleineren Puffer hat. Mit 20 fahre ich ganz gut. Über 20 gibt es schon Fehler beim Initscan.
Robby welche Rate hat Du ?
Rein logisch betrachtet kann es um Mitternacht schon eher auftreten, da es zum Tageswechsel ja schon fast ein "Telegrammgewitter" gibt.

[Robby]

Robby welche Rate hat Du ?

Ich habe die maximale Rate auf 20 stehen.
Beim "aktivieren" treten die Fehler auch nicht auf.
Im Log sieht man auch keine "Datenflut" wenn die Datenverbindung abreist.
Ich werde das auch mal weiter beobachten.

[gaert]

Ich habe eine Rate von 20/s mit dem berühmten Eibmarkt-Router und bislang noch nie(!) einen Fehler gehabt (seit nunmehr über 2 Jahren). Mein Atom-Hardware kennt Ihr ja (Intel DT2800 oder so ähnlich). Der Router hat in der Tat ein Puffer für 150 Telegrammen - wenn ich die Rate z.B. auf 30 erhöhe, ist auch er manchmal überfordert (eben wenn z.B. beim Initscan sehr viele Telegramme losgelassen werden - und auch entsprechend viele Antworten zurückkommen).

[WagoKlemme]

Der Fehler tritt sehr sporadisch auf, manchmal wochenlang nicht. Deshalb ist es auch kein Problem für mich.
Als ich die Telegrammrate testhalber mal auf 27 hatte, kam der Fehler schon regelmässig.

Edit: Um Mitternacht hatte ich allerdings nie diesen Fehler, immer tagsüber.

[gaert]

20/s ist vermutlich schon relativ viel - je nach Router/Schnittstelle. Das arme Ding muss ja auch die Empfangsseite noch bedienen, so dass ggf. >40/s Telegramme zu verarbeiten sind. Die KNX-Spec gibt zwar theoretisch noch mehr her, jedoch bezweifle ich bei einigen Modellen stark, dass diese damit klar kämen.

Eine Zeit lang (mit dem HS damals) hatte ich sogar nur 10/s eingestellt, da ich damals noch eine EIB-Doktor(?)-Schnittstelle hatte - lange vor EDOMI hatte ich mit VisualBasic rumgespielt Die 10/s sind durchaus noch erträglich, allerdings fühlt sich der Bus dann schon z.T. etwas träge an (z.B. bei großen Szenen kann man fast mitzählen, wie die Lampen an gehen).

[Nanosonde]

Das hier diskutierte Problem hatte ich auch eine Zeit lang und habe den Thread aus diesem Grund mit grossem Interesse verfolgt. Es wäre gut, wenn Du die genaue Vorgehensweise zum Update des Kernels dokumentieren würdest!

Offensichtlich hat es von gestern auf heute eine neue Stable-Version 4.9.11 gegeben.
Ich beziehe mich jetzt mal auf diese. Ich hatte ja noch mit der 4.9.10 getestet.

Abhängigkeiten installieren

yum install wget
yum install bc
yum install openssl openssl-devel
yum groupinstall "Development Tools"
yum install ncurses-devel
yum install hmaccalc zlib-devel binutils-devel elfutils-libelf-devel

Kernel runterladen und entpacken

cd /usr/src/kernels/
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.11.tar.gz
tar xfz linux-4.9.11.tar.gz

Kernel konfigurieren

cd /usr/src/kernels/linux-4.9.11
cp /boot/config-2.6.32-431.el6.x86_64 ./.config
make olddefconfig <--- wie make oldconfig, nur mit "recommended defaults", erspart das viele "ENTER" drücken. ;-)

Kernel bauen und installieren

make <--- das dauert jetzt ziemlich lange. Die Module werden auch gebaut.
make modules_install <--- installiert die neuen Kernel-Module unter /lib/modules
cp arch/x86_64/boot/bzImage /boot/vmlinuz-4.9.11
cp ./.config /boot/config-4.9.11
cp ./System.map /boot/System.map-4.9.11
cp ./Module.symvers /boot/symvers-4.9.11
gzip /boot/symvers-4.9.11

Initramfs erzeugen

cd /boot/
dracut -f ./initramfs-4.9.11.img 4.9.11

GRUB anpassen
Hier sollte man einfach seinen vorhanden Eintrag nochmal kopieren und entsprechend anpassen.
Ich habe bei der CentOS-Installation die Defaults mit LVM gelassen, so dass es bei mir so aussieht.

title CentOS (4.9.11)
        root (hd0,0)
        kernel /vmlinuz-4.9.11 ro root=/dev/mapper/vg_edomi-lv_root rd_LVM_LV=vg_edomi/lv_root rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=de-latin1-nodeadkeys rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=vg_edomi/lv_swap LANG=de_DE.UTF-8 rd_NO_DM
        initrd /initramfs-4.9.11.img

Wichtig!
Ohne das Erzeugen des Inhalts für die Ramdisk, funktioniert der Bootvorgang später nicht, da das Root-Dateisystem nicht gefunden werden kann.
Sollte der Kernel nicht funktionieren, kann beim Bootvorgang einfach der alte Kernel ausgewählt werden.

Generall hoffe ich, dass Edomi auch bald mal auf neueren Distributionen ohne Verrenkungen lauffähig sein wird.
So wie ich das sehe, hängt das momentan defacto nur an dem uralten bcompiler, den es wohl nur bis PHP5.3 oder gibt.

Alte Software auf neuer Hardware ist gerade bei Linux sehr oft ein Problem.

Update#1: Abhängigkeiten zum Bauen des Kernels hinzugefügt.

[Nanosonde]

Also nur nochmal als kleine Hilfestellung für andere Leute mit ominösen Fehlern bzgl. Sequence-Counter-Abweichung und Disconnects:
1) Kabel prüfen
2) Switches prüfen (ich konnte bei meinem Managed Switch sehen, dass am Edomi-Port und am Gateway-Port weder RX- noch TX-Fehler auftraten.
3) Evtl. mal andere Ethernet Geschwindigkeiten ausprobieren

Wenn das als Fehlerquelle zusammen mit dem Gateway ausgeschlossen ist, sollte man mal das Linux auf seiner HW unter die Lupe nehmen.
1) Last auf allen Cores erzeugen
2) I/O Last erzeugen für die HDD/SSD
3) I/O Last erzeugen für das Netzwerk

Bei mir konnte ich sehen, dass das Problem beim alten Kernel nur auftrat, wenn die SSD beteiligt war. Reine CPU-Last bewirkte nichts.
Als weiteren Test hatte ich es auch mit einer USB-Netzwerkkarte getestet. Interessanterweise zeigt das System das gleiche Problem wie unter Last mit SSD Beteiligung und Onboard-Netzwerkkarte.

[SeatSLF]

20/s ist vermutlich schon relativ viel - je nach Router/Schnittstelle. Das arme Ding muss ja auch die Empfangsseite noch bedienen, so dass ggf. >40/s Telegramme zu verarbeiten sind. Die KNX-Spec gibt zwar theoretisch noch mehr her, jedoch bezweifle ich bei einigen Modellen stark, dass diese damit klar kämen.

Eine Zeit lang (mit dem HS damals) hatte ich sogar nur 10/s eingestellt, da ich damals noch eine EIB-Doktor(?)-Schnittstelle hatte - lange vor EDOMI hatte ich mit VisualBasic rumgespielt Die 10/s sind durchaus noch erträglich, allerdings fühlt sich der Bus dann schon z.T. etwas träge an (z.B. bei großen Szenen kann man fast mitzählen, wie die Lampen an gehen).

Mit der aktuellen Firmware läuft bei mir der Enertex Router mit eingestellten 35/s ohne Fehler.

[SebastianBaeumler]

Hallo

zum bauen des Kernels habe ich bei einem CentOS 6.5 Minimal habe ich noch folgende Pakete installieren müssen.

yum install wget
yum install bc
yum install openssl openssl-devel
yum groupinstall "Development Tools"
yum install ncurses-devel
yum install hmaccalc zlib-devel binutils-devel elfutils-libelf-devel


Gruß,
Sebastian