knx stack tp uart data link layer buffer overrun

[Ing-Dom]

Hi,
wir rätseln im OpenKNX Team gerade etwas über einen change:
https://github.com/OpenKNX/knx/commi...9278af4074eff8

mike ich denke der ist von dir. Ggf kannst du was dazu sagen.
Oder thesing

konkret

                        if (_platform.uartAvailable() > OVERRUN_COUNT)
                        {
                            print("input buffer overrun: "); println(_platform.uartAvailable());
                            enterRxWaitEOP();
                            break;
                        }​

fragen wir uns warum der buffer verworfen wird (eventuell fehlerhafte telegramme würde man ja über CRC erkennen.
Weiterhin gehen wir davon aus, dass der Wert 7 für eine plattform mit einem 8Byte Rx-Buffer gemacht ist, oder?
Gerade bei größeren Werten (z.B. 32Byte bei RP2040) könnten ja im bufer noch mehrere gültige telegramme enthalten sein, selbst WENN man einen Überlauf erkennt.

[mike]

Den Grund hatte ich im PR beschrieben. Bei einem Overrun von min. 7 Bytes, hat man gar keine Chance mehr die Daten zu verwenden. Man könnte das zwar noch Auswerten und hoffen das der CRC Fehler bereinigt, aber was dann? Um das Paket zu bestätigen ist die Zeit zu spät. Also wird der Sender es sowieso wiederholen, da er kein ACK bekommt.

[Ing-Dom]

hier ist der PR: https://knx-user-forum.de/forum/proj...buffer-overrun

nunja, der ACK ist ja nicht alles. Es könnte ja eine GroupAddressWrite sein, der von einem anderen Gerät geACKed wird und somit nicht wiederholt wird...

[mike]

Du meinst https://github.com/thelsing/knx/pull/184 , oder?

Ja, das kann auch sein, dass ein anderes Gerät das bestätigt und somit keine Wiederholung mehr erfolgt.
Wenn man dann diese historischen Daten im Puffer auswertet, dann müsste man im Kode vermeiden ein U_ACK_REQ zu schicken. Dann müsste man aber auch Erkennen wann der Overrun vorbei ist und man wieder synchron ist. Das erhöht die Komplexität.

Einfach den U_ACK_REQ trotzdem zu schicken könnte klappen. Ist aber eigentlich ausserhalb der Spezifikation/des Prokolls. D.h. man ist vom konkreten Verhalten der TPUART abhängig. Das gilt allerdings nur, wenn wir noch innerhalb des Empfangs des Pakets sind, das gerade ausgewertet wird. Und wenn es nun doch von uns bestätigt werden musste, weil wir die einzigen sind, die auf diese Gruppenadresse hören? Dann bekommen wir das Paket trotzdem nochmal. Das müsste dann auch behandelt werden, da wir evtl. ja schon auf das nicht bestätigte Paket hin eine Aktion ausgelöst haben. Komplex, oder?

Bei einem größeren Overrun, wie du ihn beschreibst mit "riesigem" Buffer, verarbeitest du das Paket vielleicht zu einem Zeitpunkt an dem die TPUART gerade ein weiteres Paket empfängt, das du aber nicht bestätigen möchtest. Jetzt wird aber das U_ACK_REQ geschickt und damit dennoch bestätigt.

[mumpf]

Vielleicht zum Hintergrund für mike: Ich untersuche gerade Fehler in meiner Logik-Applikation, die durch Telegramm-Bursts auf dem Bus verursacht werden. Also keine allgemein hohe Buslast, sondern "einfach" mal Situationen, bei den 20-30 Telegramme innerhalb einer Sekunde verschickt werden. Und da taucht

input buffer overrun

recht häufig auf. Und es gibt reproduzierbare Fälle, bei denen dann die Logiken nicht funktionieren, weil Telegramme verloren gegangen sind. Und ich habe mal versuchsweise den Wert von 7 auf 31 erhöht und die Fehler sind weg. Deswegen hier die Frage.

Also wird der Sender es sowieso wiederholen, da er kein ACK bekommt.

Ist das hier nicht eine falsche Annahme?
Wenn die GA auch noch mit einem anderen KO verbunden ist oder ein LK da ist, dann kommt doch ein ACK (von dem anderen Gerät) und es wird nicht wiederholt.

Und mit dem enterRxWaitEOP() wird der restliche UART geleert. Also die kompletten 32 Byte (beim RP2040) oder gar 64 Byte (beim SAMD) und damit auch mögliche weitere Telegramme.

Ist das wirklich ein korrektes Verhalten (keine Kritik, wirklich eine offene Frage):

Ich verwerfe 1 bis n Telegramme, weil ich beim ersten Telegramm kein ACK verschicken konnte.

Mit meiner Anpassung verarbeite ich das Telegramm und es gab möglicherweise keinen ACK (weil die GA wirklich nur das Sendende mit dem Empfangenden KO verbindet). Dann würde das Telegramm wiederholt werden. Wie unser knx-Stack darauf reagiert weiß ich nicht. Wird die Wiederholung dann verworfen oder triggert die nochmal die KO-Auswertung. Das muss ich schauen. Aber "gefühlt" verhält sich das besser/robuster als das verwerfen von Telegrammen.

Noch eine Überlegung zur Auswertung einer Wiederholung:
Eine Wiederholung kann es auch geben, wenn ein ACK von unserem Gerät gesendet wurde, weil ein anderes Gerät ein NACK geschickt hat. Wäre dann der gleiche Fall: Das erste Telegramm wurde verarbeitet und es kommt trotzdem eine Wiederholung. Weiß da jemand, wie sich der Stack verhält?

Deine Meinung hier mike ist sehr willkommen. Mir ist nicht klar, ob es nicht auch noch weitere Seiteneffekte geben könnte.

Gruß, Waldemar

[mike]

Offensichtlich hat aber nicht der TPUART-Kode das Problem mit den Bursts. Der Bus ist ja so langsam, da kann nichts überrennen.

Das Problem ist die Verarbeitung der Nachrichten im Logikteil, oder?

Die Meldung "input buffer overrun"-Meldung weist lediglich darauf hin, dass hier etwas falsch ist. Aber das ist nur der Überbringer der schlechten Nachrichten. Wenn man den OVERRUN_COUNT erhöht, dann erhält man die schlechte Nachricht nicht mehr. Es funktioniert sogar häufig besser als vorher. Aber was man eigentlich damit erreichst ist, dass das Problem woanders hingeschoben wird.

Die TPUART2 definiert in "3.2.3.1.8 U_AckInformation-Service":
This service is sent by the host after the address evaluation and must be
sent latest 1,7 ms after receiving the address type octet of an addressed frame.

Es gibt da keine Möglichkeit für einen Puffer. Ein Byte vielleicht, aber 32 oder 64 Bytes?
Das gleiche beim Senden. Der Sendepuffer hat einfaches FiFO-Verhalten. Aber ein ACK muss sofort geschickt werden und das ist im Protokoll so vorgesehen.

Daher ist meine "Meinung" (ich würde es fast als Fakt hinstellen wollen :-)), dass die beiden Puffer die wir jetzt bei der TPUART-Implementierung im seriellen Treiber haben (Sende- und Empfangspuffer) so klein wie nur möglich gehalten werden müssen. Die korrekte Lösung wäre die Abhandlung direkt im Interrupt der UART laufen zu lassen.

Wenn bei der Verarbeitung der Pakete zu viel Zeit benötigt wird, dann kommt es zu Overruns. Wichtig ist die Aufruf-Frequenz des TPUART-Kodes. Dieser funktioniert nur dann immer korrekt wenn er unter 3ms immer wieder aufgerufen wird.

Ich sehe aber durchaus, dass das in der Main-Loop-Architektur beim Arduino eine ziemliche Herausforderung ist. Ich hatte da in https://github.com/thelsing/knx/pull/171 unter dem Teilcommit "New state RX_L_ADDR; loop load adaption" versucht das zu verbessern. Stellt der TPUART-Kode fest, dass er zu selten gerufen wird, was ja unfair ist, dann fängt er auch an unfair zu werden und gibt die CPU nicht mehr ab, wenn er gerade am Adressfeld ist, um die zeitlichen Anforderungen der TPUART wenigstens bei den Paketen zu erfüllen wo er gerade zeitlich passend aufgerufen wird. D.h. es gehen zwar u.U. viele Pakete verloren, aber die die er verarbeitet, die sind dann auch korrekt. D.h. das löst nicht das Problem (zu seltener Aufruf) aber es stabilisiert die Kommunikation etwas.

Du könntest im Logikteil Puffern und dann während der Abarbeitung (die Anscheinend zu lange dauert) immer mal wieder den TPUART-Kode aufrufen. Der benötigt so gut wie keine Zeit, wenn nichts zu tun ist und nimmt sich ansonsten nur die minimale Zeit die nötig ist.

Ansonsten gäbe es noch die Möglichkeit das Busy-Flag zu verwenden. Man kann der TPUART sagen, dass man Busy ist. Dann lehnt die alle Pakete ab. Das ist aber im Stack nicht implementiert.

[Ing-Dom]

Danke mike dass du das mal so fundiert erläuterst, ich predige schon ewig loop Zeiten < 1ms aufgrund des ACKs, aber so richtig hören wollte das noch keiner...
und ich muss zugeben dann war ich auch zu faul bzw. hab mich lieber mit was anderem beschäftigt.

7 Byte im Buffer dürften überschlägig > ca 7ms loop zeit bedeuten oder hab ich mich verrechnet?

[mike]

7 Byte im Buffer dürften überschlägig > ca 7ms loop zeit bedeuten

Ja das könnte hinkommen.

Ich hatte den Wert in der Praxis ermittelt. Der Wert ist quasi das Maximum das in meinem Setup noch funktioniert hat. Somit ist das schon grenzwertig.

[thesing]

Ich kann hier gar nicht viel Weiteres beitragen, da von mir lediglich die initial hingehunzte TPUART Implementierung war.

Für mich klingt das so als ob man die Ausgabe erweitern sollte: "Your loop() function takes too much time!"

Ich denke auch das man langsam an die Grenzen kommt was auf einer CPU ohne ein RTOS so machbar ist.

[mumpf]

Danke für eure Antworten, speziell für Deine Einschätzung, mike.

Aber ich möchte hier eines klarstellen: Ich untersuche Extremfälle, keinesfalls den "straight forward" Fall (für den gilt alles gesagte: kurze loop()-Zeiten, häufiges Aufrufen von knx.loop() usw.).
Es hat willisurf über 2 Wochen gekostet, sein durchaus komplexes Beispiel so weit zu reduzieren, dass man es überhaupt untersuchen konnte (vielen Dank dafür) und es dauerte nochmal 2 Wochen für uns beide, die Problemstelle zu finden. Es geht also keinesfalls darum, dass bei jedem loop irgendwo 5-10ms verbraten werden. Es geht darum, dass es bei Telegramm-Bursts zu Fehlern kommen kann. Der Anfangsverdacht war auch der, dass 2 unabhängige Kanäle sich doch "irgendwie" beeinflussen. Also durchaus ein ernsthafter Fehler, den ich unbedingt verfolgen wollte, da er für ein nichtdeterministisches Verhalten sorgt -> für ein Logikmodul der Supergau. Nach der Untersuchung zeigt sich, dass im Stack einfach Telegramme verloren gehen. Und das "nur", weil kein ACK gesendet werden konnte.

Ich möchte vermeiden, dass wir hier über zu lange loop-Zeiten diskutieren, zumindest mir ist klar, dass man hier aufpassen muss und keine Zeit "verplempern" sollte. Wobei bei dem vorliegenden Fall sicherlich meine Verarbeitung der KO-Callbacks vom Stack zu den Verzögerungen führt - auch ein Aspekt, der bei mir schon länger auf der TODO-Liste steht.

Ich würde gerne diskutieren, ob die Behandlung dieser an sich seltenen, aber möglichen Situation so korrekt ist.

Offensichtlich hat aber nicht der TPUART-Kode das Problem mit den Bursts. Der Bus ist ja so langsam, da kann nichts überrennen.

Da stimme ich Dir zu, aber es ist IMO nicht ausreichend, immer nur zu sagen "an dem Teil liegt es nicht", da der Stack ja von einer Applikation genutzt wird und man das Zusammenspiel betrachten muss.

Das Problem ist die Verarbeitung der Nachrichten im Logikteil, oder?

Nicht im Allgemeinen, nein. Das Problem hier ist, dass einige der Telegramme wieder was gesendet haben, was dann auch vom selben Modul empfangen wurde, was KO-Callbacks getriggert hat, die jeder für sich zwar schnell, aber alle in Summe wohl zu langsam prozessiert werden (muss ich noch genauer untersuchen).

Die Meldung "input buffer overrun"-Meldung weist lediglich darauf hin, dass hier etwas falsch ist.

Dagegen sage ich nichts... nur stelle ich die darauffolgende Aktion in Frage.

Wenn man den OVERRUN_COUNT erhöht, dann erhält man die schlechte Nachricht nicht mehr. Es funktioniert sogar häufig besser als vorher.

Genau! Wenn es häufig besser ist, warum also die schlechtere Lösung?

Aber was man eigentlich damit erreichst ist, dass das Problem woanders hingeschoben wird.

Sehe ich nicht. Mit Wiederholungen muss man sowieso klar kommen, weil auch im Normalbetrieb (also nach einem korrekten ACK) trotzdem welche kommen können. Dass man keinen überflüssigen ACK bei einer "verspäteten" Verarbeitung mehr sendet, ist ein Punkt, den ich mir noch anschauen muss.

Deine anderen Beschreibungen (möglichst kleine Buffer, spezialfall RX_L_ADDR, Busy) will ich hier nicht alle zitieren außer der "Quintessenz":

D.h. es gehen zwar u.U. viele Pakete verloren, aber die die er verarbeitet, die sind dann auch korrekt.

Alles läuft darauf hinaus, dass man Telegramme verliert. Aber nicht weil sie nicht empfangen werden können, sondern nur, weil kein ACK timinggerecht gesendet werden kann.

Das ist IMO praxisfremd, zumindest ehe ich das anders: Ich werde doch nicht viele korrekte Pakete ignorieren, nur um bei einem mal rechtzeitig ein ACK verschicken zu können. Vor allem, weil KNX ja ein optimistisches ACK verwendet (es reicht, wenn einer bestätigt). An sich ist das ACK nicht wirklich wichtig, viel relevanter ist das NACK, um zu signalisieren, dass man selber was nicht empfangen hat, obwohl andere es empfangen (und geACKed) haben.

Die TPUART2 definiert in "3.2.3.1.8 U_AckInformation-Service":
This service is sent by the host after the address evaluation and must be
sent latest 1,7 ms after receiving the address type octet of an addressed frame.

Ich hab das leider nicht in der KNX-Spec gefunden (hab nur die 2.1, vielleicht hast Du ja was neueres). Das was ich bisher gelesen habe, sagt durchaus was über das Timing vom ACK. Aber ich erinnere mich nicht daran, dass irgendwo steht, dass man das Telegramm verwerfen sollte, nur weil man kein ACK verschicken konnte. Verworfen werden Telegramme nach meinem Verständnis nur, wenn sie kaputt sind (unvollständig, falscher CRC, ...). Aber ich kenne die Spec sicherlich nicht besonders gut.

Zusammenfassung:

• Es geht mir nicht um Normalbetrieb, sondern um Extremfälle, die selten auftreten
• Ich bin daran interessiert, korrekt empfangene Telegramme zu prozessieren und sie nicht zu verwerfen.
• Ein fehlendes ACK ist für das sendende Gerät wichtig, für das empfangende sollte das nicht zum Ignorieren von Telegrammen führen
  Anders gesagt: Die Korrektheit eines Telegramms ist nicht davon abhängig, ob ein ACK verschickt werden konnte.
• Wiederholungen können auch jederzeit im Normalbetrieb passieren und müssen unabhängig von dieser Problematik behandelt werden können
• "Out-of-Order-ACK" sollte man nicht machen, das ist noch zu untersuchen.

Soweit meine Meinung,
Gruß, Waldemar

[traxanos]

Ich sehe das übrigens auch so. Gerade der RP2040 hat auch noch den Nachteil, dass bei Nutzung des Flashs alles pausiert. Auch wenn man FreeRTOS nutzen würde. Und mir ist das ACK ehrlich gesagt total egal, weil es imho Fehler auf dem Bus verhindern soll. Sonst müsste jedes Gerät das Telegramm bestätigen.

Ich hätte sogar lieber eine größstmöglichste Queue, damit man die Telegramme bei der Nutzung des Flash "nachverarbeiten" können. Imho könnte man auch dubletten in der Queue erkennen und als ein Telegramm werten.

[mike]

Ich hab das leider nicht in der KNX-Spec gefunden

Sorry, das mit dem Verweis auf die TPUART-Spec war keine vollständige Quellenangabe. Das ist aus dem "SIEMENS KNX EIB TP-UART 2-IC MANUAL" (Release: June 2013). Hier https://www.opternus.com/fileadmin/_...0130806_01.pdf ist das August Release.
In diesem Dokument ist die Kommunikation zwischen dem TPUART-Chip und dem Host (µC) definiert.

Genau! Wenn es häufig besser ist, warum also die schlechtere Lösung?

Da habe ich jetzt lange drüber Nachgedacht und festgestellt das ihr Recht habt. Obwohl der Puffer an dieser Stelle eigentlich keinen Sinn ergibt hat er doch eine positive Wirkung und er fängt zu lange Loop-Zeiten ab (in vielen Fällen).

Am besten wäre hier eine Änderung bei der der OVERRUN_COUNT in z.B. KNX_OVERRUN_COUNT umbenannt wird und nur definiert wird, wenn er nicht schon definiert ist. Damit ist das Quasi für jeden einstellbar. Beim Default würde ich persönlich es gut finden diesen auf dem aktuellen Wert zu belassen.

Ich finde das gruselig da das Außerhalb der Spezifikation ist, aber es funktioniert wobei es teilweise "rumpeln" könnte.

Also, Pakete die sowieso ignoriert werden verhalten sich genauso wie vorher, nur das keine Meldung mehr kommt.
Pakete die eigentlich bestätigt werden müssten, werden von der TPUART nicht bestätigt. Da hat man Glück wenn ein anderer Busteilnehmer das bestätigt. Wenn die Logik der einzige Listener ist, dann kommt es zu unerwünschten Paketwiederholungen, was im Burst-Fall eher unglücklich ist. Aber da kann man ja den Pro-Tipp geben einfach einen weiteren Busteilnehmer auf diese Adresse hören zu lassen (wenn einem dann noch Einfällt woher das Problem kam).
Da der Stack nur Ignore und ACK verwendet (also nie NACK oder Busy) gibt es keine weiteren Fälle zu beachten. Wird der Stack erweitert, dass er auch NACK und Busy senden können soll hat man hier ein Problem. Aber z.Z. gibt es kein Problem.

Das "aus versehen" bestätigen eines falschen Pakets wiegt in der Regel auch nicht schwer, wenn es von einem anderen Busteilnehmer sowieso bestätigt wird. Der Fall das es nur einen Listener gibt, dieser gerade nicht antwortet und man damit die eigentlich erwünschte Wiederholung unterdrückt, ist wohl eher esoterischer Natur.

Bei der Puffergröße muss man beachten, dass der Puffer möglichst nicht voll werden sollte. Bei einem vollem Puffer setzt die Serielle zwar ein Flag, das wird aber im Stack nicht ausgewertet (kann nicht, da es nicht durchgereicht wird). In dem Fall werden die Pakete nicht mehr vollständig gespeichert. Da muss man auf den CRC hoffen. Hier gleich vorweg: Ich habe in meiner Installation schon gesehen, dass mit dem CRC ein fehlerhaftes Paket nicht erkannt wurde.
Wenn beim Abarbeiten des Puffers im KO-Callback Zeit "vertrödelt" wird, muss man bedenken das einem die serielle Schnittstelle u.U. per Interrupt weitere Daten nachschiebt und den Puffer evtl. wieder anschlagen lässt (hatte ich bei mir so gesehen). Man hat dann also ziemlichen Müll im Puffer (also Fragmente diverser Pakete). Ein größerer Buffer hilft hier natürlich, zieht aber nach sich, dass man noch länger in diesem "Out-of-Spec"-Modus verweilt.

Für mich ist das immer noch zu gruselig als das ich den Puffer verwenden würde. Es gibt ja noch eine Sache (Überraschung :-)), die auf korrektes Timing angewiesen ist: Das Abbrechen von Übertragungen mit geringer Priorität. Soll jetzt ein Paket höherer Priorität gesendet werden, dann wird die Übertragung durch NAK abgebrochen, eine Pause gemacht und dann kommt die höher priorisierte Übertragung. Bekommt man diese Daten "live", dann kann man das Anhand der Zeiten erkennen. Aus dem Puffer kann man aber keine Zeitinformationen ablesen, d.h. die Pause bekommt man nicht mit. Bei meinen Analysen von Übertragungen während der Programmierung hatte ich sowas häufig gesehen. Hier z.B. zweimal hintereindaner:
Double_EOPR.png

Die Übertragung fängt mit BC (niedrige Prio) an, dann kommt ein NAK auf dem Bus (von unserer TPUART). Wir bekommen das nur Anhand der Pause mit (die im Puffer nicht vorhanden ist) und es geht weiter mit dem Echo unseres Pakets (wir haben den Bus bekommen). Dann bekommen wir ein ACK was uns die TPUART via 8B meldet. Wir starten den Upload eines weiteren Pakets in die TPUART (obere Zeile zu TPUART). Währenddessen versucht der andere Teilnehmer es erneut (B0) und bekommt wieder ein NAK. Diesmal von jemand anders, da wir noch nicht mit dem Upload durch sind. Nach der Pause gewinnen wir erneut den Bus und können unser Paket absetzen (ganz am Ende kann man noch den Beginn vom ACK sehen).

D.h. hier, quasi ohne Puffer, klappt das wunderbar mit der 8ms Pause wieder Aufzusynchronisieren. Aus dem Puffer liest man dagegen "BC B0 11 ..." und stellt irgendwann fest, dass das Müll ist. Damit ist das Paket "B0 11 ..." aber verloren. Schade wenn wir darauf hätten reagieren wollen.

Aber auch das ist wohl eher selten, da wir hier einen Ausschnitt aus einer Programmierung sehen. Im Normalfall sendet der Stack auch mit niedriger Prio (wobei ich da gerade ein bisschen unsicher bin). Also wenn während eines Bursts nicht gerade eine Programmierung erfolgt, hat man hier kein Problem.

[willisurf]

Aber da kann man ja den Pro-Tipp geben einfach einen weiteren Busteilnehmer auf diese Adresse hören zu lassen

Ich habe bei mir inzwischen einen Linienkoppler (ich brauche sonst keinen) so konfiguriert, das alle Telegramme ein ACK bekommen und ich sehe nur Vorteile (insbesondere auch, da ich einen X1 habe).

Wichtig ist das NACK.

[traxanos]

ich bin zwar nicht so fit im knx stack, aber ich hätte ja erwartet, das man den buffer zeitlich betrachten muss. denn im endeffekt möchte man auch die Wiederholungen filtern. wenn ich also im buffer 3x für eine ga einen wert habe, möchte ich beim verarbeiten nur den letzten (aktuellsten) wert haben.

Am besten wäre hier eine Änderung bei der der OVERRUN_COUNT in z.B. KNX_OVERRUN_COUNT umbenannt wird und nur definiert wird, wenn er nicht schon definiert ist.

Das war auch meine erste Idee und wäre auch dafür. Gerade mit dem KNX_ Prefix.

Wenn beim Abarbeiten des Puffers im KO-Callback Zeit "vertrödelt" wird, muss man bedenken das einem die serielle Schnittstelle u.U. per Interrupt weitere Daten nachschiebt und den Puffer evtl. wieder anschlagen lässt (hatte ich bei mir so gesehen).

Das ist "vertrödelt" wird ist bei uns vermutlicher weniger ein Problem. Das größere Problem ist, dass der Interrupt "pausiert" wird beim RP2040 und ich vermute das hierbei deutlich mehr Probleme entstehen können.

Ich habe bei mir inzwischen einen Linienkoppler (ich brauche sonst keinen) so konfiguriert, das alle Telegramme ein ACK bekommen und ich sehe nur Vorteile (insbesondere auch, da ich einen X1 habe).

Finde ich garnicht so schlecht.