KNX DISCONNECT_REQUEST kurz nach Mitternacht

[gulp2k]

Als kurzes Update, bei mir läuft Edomi im Proxmox Container. Leider ist die IO Performance nicht die beste... jedenfalls hab ich festgestellt das beim Klonen einer anderen Maschine bei Edomi SeqErrors aufgetreten sind. Deutet wirklich auf ein Resourceproblem hin.

[DerSeppel]

Gesehen hab ich sie nur per eibd und Edomi. Ob sie auf dem TP auch zu sehen sind, muss ich noch probieren. Werde erst einmal noch Wireshark bemühen.

LK ist keiner im Einsatz. Ring schließe ich aus. Sind jeweils zufällige Telegramme von unterschiedlichen Segmenten. Sprich aus dem Keller, Og, EG, Garage.
Müsste man das nicht auch permanent sehen, wenn es einen Ring gäbe?

[DerSeppel]

Habe jetzt nochmal die letzten Logik-Anteile vom BananaPi auf Edomi migriert und den knxd dort abgeschaltet. Habe trotzdem noch diese sporadischen Telgramm-Bursts.
Jetzt gibt es also nur noch Edomi und den MDT Router. Dass alle Geräte in der Installation nen Sockenschuss haben und gelegentlich diese Bursts senden, glaube ich irgendwie nicht.
Wireshark habe ich noch nicht probiert, mal sehen ob ich das auf dem Pi zum laufen bekomme.

[DerSeppel]

Habe tshark angeschmissen auf dem BananaPi und zufällig den Fehler schon fangen können. Nur sind meine Protokollkentnisse nicht ausreichend um den Fehler zu erkennen.
Es ist wieder ein Paket des Stromzählers, aber ich denke das ist eher eine statistische Frage. Er sendet recht oft und dann viele Daten am Stück. Trat auch schon beim PM und Glastaster auf.

Das hier ist das Telegramm, welches wiederholt wurde, im Trace 255 mal zu sehen!

Frame 13153: 63 bytes on wire (504 bits), 63 bytes captured (504 bits)
Ethernet II, Src: Weinzier_00:b4:7b (00:24:6d:00:b4:7b), Dst: IPv4mcast_17:0c (01:00:5e:00:17:0c)
Internet Protocol Version 4, Src: 192.168.1.201, Dst: 224.0.23.12
User Datagram Protocol, Src Port: 3671, Dst Port: 3671
KNXnet/IP
    Header
    Body
        cEMI
            messagecode: L_Data.ind (0x29)
            add information length: 0 octets
            Controlfield 1: 0xbc
                1... .... = Frametype: 1
                ..1. .... = Repeat: 1
                ...1 .... = System-Broadcast: 1
                .... 11.. = Priority: 0x3
                .... ..0. = Acknowledge-Request: 0
                .... ...0 = Confirm-Flag: 0
            Controlfield 2: 0xd0
                1... .... = Destination address type: 1
                .101 .... = Hop count: 5
                .... 0000 = Extended Frame Format: 0x0
            Source Address 1.1.3
            Destination Address 8/3/42 or 8/810
            NPDU length: 5 octets
            00.. .... = TPCI: UDT (Unnumbered Data Packet) (0x0)
            .... ..00  10.. .... = APCI: A_GroupValue_Write (0x0002)
            data: 00000000

Danach ist dieser Frame zu sehen:

[B]13409    21791.325919    192.168.1.201        224.0.23.12    KNXnetIP    60        ROUTING_LOST_MESSAGE 3671 > 3671[/B]
Frame 13409: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: Weinzier_00:b4:7b (00:24:6d:00:b4:7b), Dst: IPv4mcast_17:0c (01:00:5e:00:17:0c)
Internet Protocol Version 4, Src: 192.168.1.201, Dst: 224.0.23.12
User Datagram Protocol, Src Port: 3671, Dst Port: 3671
KNXnet/IP
    Header
    Body
        Structure Length: 4 octets
        DeviceState: 0x00
            .... ...0 = KNX Fault: 0
            .... ..0. = IP Fault: 0
            0000 00.. = reserved: 0x00
        NumberofLostMessages: 98

Kann jemand nochmal den HopCount (Routing Counter?) erläutern? Der zählt doch meines Wissens runter von 7? Was wird denn alles als HOP gezählt?

[Nanosonde]

DerSeppel
Hi!

Zur Beschreibung von ROUTING_LOST_MESSAGE steht hier: http://calimero.sourceforge.net/docs...stMessage.html

The routing lost message is used to inform about the fact, that routing messages were lost due to an overflow in the LAN-to-KNX queue, i.e. a router receives more IP packets than it is able to deliver to the KNX network.

Um den HOP Counter würde ich mir keine Gedanken machen. Beim HOP Counter geht es ja darum, dass jeder Router diesen Zähler um 1 verringert. Ist der HOP Count 0 wird die Nachricht verworfen und nicht weitergeleitet.

Was mich aber interessiert:
Edomi kann ja nur per TUNNELING mit dem Router kommunizieren. Schau Dir doch mal genau diese Kommunikation an.
Der Trace von oben zeigt ja nur das, was der KNX Router per Multicast weiterleitet.
Es geht beim TUNNELING nur um die UDP Pakete zwischen den beiden IP-Adressen Router und Edomi.

Im Übrigen finde ich interessant, dass die MAC Adresse des MDT Routers aus dem Weinzierl-Pool stammt. Ist der MDT Router ein umgelabelte Weinzierl-HW?

[WagoKlemme]

Im Übrigen finde ich interessant, dass die MAC Adresse des MDT Routers aus dem Weinzierl-Pool stammt. Ist der MDT Router ein umgelabelte Weinzierl-HW?

Ältere Geräte (mit Hilfsspannung) definitiv Weinzierl. Bei den neueren Geräten weiss ich es nicht.

[Sonnengruesser]

Ich schmeiß hier mal kurz meinen Senf dazu:
Hab eine Logik erstellt, wo um Mitternacht per "täglich"-trigger eine KNX-Adresse gesetzt wird - ganz simpel Eingangsbox->Ausgangsbox
Wenn ich die Logik aktiviere, bekomme ich den sequence error, wenn ich sie nicht aktiviere (z.B. den Trigger per Vergleich mit Systemzeit auf 02:00 setze), dann bekomme ich den Sequence error nicht.

Das Phänomen, dass um Mitternacht der Bus vollgespammt wird, hab ich schon mal beobachtet (damals noch ohne diese Logik). Hab damals aber keinen Fehlereintrag bekommen. Vielleicht haben diese 2 Themen gar nicht die gleiche Ursache?

[DerSeppel]

DerSeppel
Um den HOP Counter würde ich mir keine Gedanken machen. Beim HOP Counter geht es ja darum, dass jeder Router diesen Zähler um 1 verringert. Ist der HOP Count 0 wird die Nachricht verworfen und nicht weitergeleitet.

Ausgehend von 7 als StartCounter bedeutet das aber doch, dass das Paket 2x geroutet wurde, oder? Eigentlich gibt es doch nur den Router zwischen TP und IP in meinem Fall.

Habe mal tshark auf der Edomi-Maschine angeschmissen und trace jetzt die Verbindung zwischen Edomi und Router, wie du vorgeschlagen hast.
Ich hoffe dass ich dieser Tage dazu komme noch nen rPi zum loggen an den TP zu hängen.

Die Weinzierl HW - zumindest die erste Version - bekommst du unter allerlei exotischen Namen: Somfy, Lingg&Janke, etc.

[Nanosonde]

Das Phänomen, dass um Mitternacht der Bus vollgespammt wird, hab ich schon mal beobachtet (damals noch ohne diese Logik). Hab damals aber keinen Fehlereintrag bekommen. Vielleicht haben diese 2 Themen gar nicht die gleiche Ursache?

Ich gehe fest davon aus, dass manche Berichte über SEQErrors auf unterschiedliche Ursachen zurückzuführen sind.
Der Bus-Spam könnte sowas auch sein.

Beim Erstellen dieses Thread ging es mir darum, dass diese Fehler bei mir immer dann auftreten, wenn eine bestimmte Last auf dem System ist.
Die reine CPU-Last scheint aber nicht das wirkliche Problem für einen Performance-Engpass oder so zu sein.
Ich vermute eher ein Problem bei der I/O-Last. Das wird ja quasi durch das Backup (TAR) um Mitternacht erzeugt.

Zwischendurch dachte ich, dass es doch irgendwie mit dem KNX-Tunnel-Interface und dem Netzwerk zusammenhängt.
Ich habe jetzt neben dem MDT Tunnel-Interface auch mal den "knxd" mit Merten KNX-USB getestet. Der "knxd" lief dabei als Tunnel-Interface.
Was soll ich sagen.... der SeqError tritt immer noch auf.

Daraufhin habe ich jetzt mal ein "ping -f" (flood ping) von dem Rechner und auf den Rechner gemacht.
Interessant ist, dass in meinem LAN über 10 Minuten tatsächlich bis zu 50 Pakete verloren gehen.
Beide Rechner haben die fast gleiche HW (Asrock Deskmini 110, CPU unterschiedlich) und hängen an einem unmanaged TP-Link Switch mit 50cm Patchkabel.

Ich habe nun alle Statistikdaten des Linux-Kernels auf beiden Geräten ausgewertet.
Fazit:
* Auf keinem der Rechner wird auf Ethernet-Ebene ein verlorenes oder fehlerbehaftetes Paket angezeigt.
* Auch der Linux Netzwerkstack sagt, dass keine Queue oder Eingangsbuffer vollgelaufen sind.

Was passiert denn nun mit den verlorenen Paketen?
Beim Ping-Flood wird ja für ein ECHO-Request ein Punkt gesetzt und bei einem ECHO-Reply wieder gelöscht.
Sieht man nun mehrere Punkte, bedeutet das verlorene Pakete. Das zeigt dann die Statistik auch bei Programm-Ende an.

Vielleicht ist "ping -f " auch nicht das Mittel der Wahl, sondern eher "iperf".

Jetzt kommt noch ein ABER:
Oben hatte ich von I/O-Last gesprochen. Ich hatte aber jetzt auch schon SeqErrors, ohne dass es Mitternacht war (TAR) und ohne dass ich irgendwelche Tests laufen hatte. Ich weiß nur, dass ich sie durch I/O-Last (SSD/HDD oder Netzwerk) recht schnell produzieren kann.
Dabei spielt das KNX-Interface offenbar keine Rolle. Der SeqCounter ist ja auch nur Teil des Tunnel-Protokolls und nicht der KNX-Telegramme auf Bus-Ebene.
Es ist also etwas, dass durch die Verwendung von IP hinzukommt.

Was passiert denn bei Euch, die auch immer mal wieder SeqErrors haben, wenn Ihr einen "ping -f" auf einen anderen Host macht?
Gehen dort auch Pakete flöten? Zeigt der Linux-Kernel aber auch keine Verluste an?

1) "ifconfig" oder "ip -s link" oder "cat /proc/net/dev"
2) "cat /proc/net/softnet_stat"
3) "cat /proc/net/netstat"

Details: https://blog.packagecloud.io/eng/201...netsoftnetstat

Die Rechner-HW nutzt den eingebauten Intel-Ethernet MAC mit dem Linux E1000E Kernel Modul.
uname -a: Linux edomi 4.10.1-1.el6.elrepo.x86_64 #1 SMP

[Nanosonde]

Ich glaube, dass ich bei mir nun den Fehler auf den Netzwerkkartentreiber E1000E unter Linux eingrenzen konnte.
Vorher hatte ich noch einen anderen Switch ausprobiert, mit dem hatte ich aber immer noch verlorene Pakete, die nirgendwo gezählt wurden.
Dann habe ich nochmal eine USB3 Ethernetkarte ausprobiert und dort hatte ich nur 2 verlorene Pakete. Hier hätte es natürlich auch der USB sein können, der selbst in der BULK-Klasse Daten verlieren darf, sein können.
Auch andere Link-Geschwindigkeiten (10/100) brachten keine Verbesserung bzgl. der Paketverluste.

Nach ein wenig Recherche zum Treiber e1000e für das Onboard-LAN, kam ich auf den Paramter "InterruptThrottleRate".
Dieser steht per default auf "dynamic conservative". Diesen habe ich nun auf 0 gesetzt, also abgeschaltet.
Jedes Paket generiert nun einen IRQ. Auf dem Edomi sicherlich kein Problem, was die CPU-Last angeht. Dadurch wird die Latenz für kleine Pakete verbessert.

Das Kernel-Modul e1000e wird nun in /etc/modprobe.conf/e1000e.conf wie folgt geladen:

options e1000e InterruptThrottleRate=0

Und was soll ich sagen....siehe da.... beim "ping -f" keine Paketverluste mehr!
Auch bei zusätzlichen TAR-Aktionen keine Paketverluste und keine SeqErrors mehr unter Edomi!

Eine genaue Erklärung für dieses Phänomen habe ich nicht. Könnte da etwas im Treiber kaputt sein bzgl. der dynamsichen Anpassung der InterruptThrottleRate?
Oder ist das evtl. bzgl. kleiner - vermeinlich unwichtiger Pakete - vielleicht sogar so gewollt? Vergessen wir nicht, dass bei ICMP (ping) und UDP mit Paketverlusten ohne Wiederholung durch den Netzwerkstack im Gegensatz zu TCP zu rechnen ist.

Bitte schaut doch mal bei Euch nach, welcher Treiber bei Euch zum Einsatz kommt.
Ist das vielleicht nur ein Problem bei neuerer Intel-Hardware?

In meinen beiden Deskmini 110 werkelt jeweils eine Intel I219V. Der Treiber ist dann der E1000E.

[Nanosonde]

So. Kurzer Zwischenstand:
Das "ping -f" lief seit gestern die ganze Nacht durch. Es ist kein einziges Paket mehr verloren gegangen.
Auch Edomi hat um Mitternacht keinen SeqError produziert.




Hoffentlich war es das jetzt.

Achso. Getestet wurde das jetzt nicht mit dem MDT Interface, sondern mit der Kombi knxd/Merten USB Interface.
Und der Kernel wurde vor den ganzen Tests gestern auch noch aktualisiert:
Linux edomi 4.12.2-1.el6.elrepo.x86_64 #1 SMP Sat Jul 15 13:11:55 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux

Es liegt nicht an der neuen Kernelversion, sondern an dem Parameter InterruptThrottleRate des e1000e Treibers.

[gulp2k]

Hm, nachdem bei mir Edomi in der VM mit Virtio Netzwerkkarte läuft hab ich wohl ein anderes Problem...

[Nanosonde]

Hm, nachdem bei mir Edomi in der VM mit Virtio Netzwerkkarte läuft hab ich wohl ein anderes Problem...

Mhmm. Was nutzt Du denn? Virtualbox? KVM?
Was für eine Karte ist denn die reale Karte?

Wie oben schon geschrieben, kann ich das Phänomen auch nicht erklären.
Vielleicht ist die Ursache ja noch eine ganze andere.

Was mich wundert, ist, dass ja jetzt eigentlich mehr Interrupts erzeugt werden als vorher.
Man würde ja eher erwarten, dass das jetzt Probleme bereitet.

[gulp2k]

Nutze Proxmox/KVM mit Intel Treiber igb, hab hier aber das ganze über vswitch + Bond laufen. Eventuell spielt das mit rein?!

[Nanosonde]

Nutze Proxmox/KVM mit Intel Treiber igb, hab hier aber das ganze über vswitch + Bond laufen. Eventuell spielt das mit rein?!

Vielleicht ist es ja nicht das Gastsystem bei Dir, sondern direkt im Hostsystem.
Verlierst Du denn da Pakete? Z.B. bei "ping -f"?