CCU sporadisch langsam

[frd030]

Ok

Code: Alles auswählen

WENN Portweiterleitung = existiert
DANN Portweiterleitung ausmachen

Aber ich denke, dann hätte er noch ganz andere Probleme

[jmaus]

Was auch problematisch ist (und ein Grund dafür ist, dass keine Funktelegramme gesendet werden können):

Code: Alles auswählen

user.err kernel: [30534.357666] eq3loop: eq3loop_write_master() mmd_hmip: not enought space in the buffers. free space = 29, required space = 46
[...]

Den Fehler findet man häufiger in der Suche, jedoch habe ich auf die Schnelle den Grund für eine solche Meldung nicht finden können.

Vielleicht ballert irgendein BidCos Gerät den Funkmodul zu, so dass die HmIP Queue nicht abgearbeitet werden kann.

Den Quellcode für das eq3loop device findet man ja hier:

https://github.com/eq-3/occu/blob/maste ... har_loop.c

und Patches die Alex und auch ich dafür noch umgesetzt haben hier:

https://github.com/jens-maus/RaspberryM ... n1_1.patch

Und ganz oben in eq3_char_loop.c findet man BUFSIZE. Siehe:

https://github.com/eq-3/occu/blob/maste ... loop.c#L61

Vor einiger Zeit hatte ich den sogar mal angehoben, aber dann diese Änderung auf Anraten von Alex wieder zurückgenommen weil er der Meinung ist (und ich auch), das das nur die Symptome bekämpft. Der Punkt ist einfach, das der eq3_char_loop ja einfach "nur" die Pakete von dem Master device (/dev/eq3loop) zu seinem jeweiligen slave device (/dev/mmd_XXXX) quasi durchroutet bzw. diese verteilt. Und wenn diese Fehlermeldungen "not enough space in the buffers" kommen, deutet das darauf hin, das hier wohl in der Tat zuviele Pakete auf ihn einballern (weil ggf. zuviel Aktivität) oder der Abnehmer die nicht schnell genug abnimmt... Und wenn man die Buffer jetzt einfach nur erhöhen würde, dann kommt man sicherlich schnell zu dem Punkt, das die Pakete nicht mehr schnell genug zum jeweiligen Homematic Stack (rfd, hmipserver) vordringen könnten (weil sie zulange in der Queue liegen) und man da dann in gewisse timeouts bzgl. der akzeptierten Antwortzeiten kommt.

Also ja, der aktuelle "best guess" bzgl. dieser Fehlermeldungen ist AFAIR, das zu viele Pakete eintrudeln und der jeweilige Abnehmer (HMIPServer, rfd) diese aus irgendwelchen Gründen nicht schnell genug losbekommt.

[jp112sdl]

das zu viele Pakete eintrudeln und der jeweilige Abnehmer (HMIPServer, rfd) diese aus irgendwelchen Gründen nicht schnell genug losbekommt.

Bezieht sich eq3loop_write_master auf die Richtung Funkmodul->Schnittstellprozess - oder - Schnittstellprozess->Funkmodul.

Ich hatte es so verstanden, dass der HMIPServer Sendetelegramme ins Funkmodul kippt (mmd_hmip) und dieses den Puffer dann nicht (schnell genug) abarbeitet.
Evtl. ja sogar wegen CarrierSense? Ich hab keine Ahnung, wie eQ-3 das Clear Channel Assessment (CCA) beim CC1310 implementiert hat.

[jmaus]

das zu viele Pakete eintrudeln und der jeweilige Abnehmer (HMIPServer, rfd) diese aus irgendwelchen Gründen nicht schnell genug losbekommt.

Bezieht sich eq3loop_write_master auf die Richtung Funkmodul->Schnittstellprozess - oder - Schnittstellprozess->Funkmodul.

Ich hatte es so verstanden, dass der HMIPServer Sendetelegramme ins Funkmodul kippt (mmd_hmip) und dieses den Puffer dann nicht (schnell genug) abarbeitet.

Klar, hast recht. Hab es falsch herum aus dem Kopf geholt mmd_hmip geht ja direkt ins Funkmodul via multimacd. Also geht es von rfd/hmipserver -> Funkmodul über den multimacd. Also entweder kann der das nicht schnell genug verarbeiten oder (und das ist wahrscheinlicher) kann der Coprozessor auf dem Funkmodul die Funkpakete nicht aussenden (ggf. wegen Listen-before-talk und zu hohem CS, ja.). Aber das sind auch wiederrum nur gewisse vermutungen meinerseits. Quellcode von multimacd existiert ja nicht und erst recht nicht vom Funkmodul

Ich hab keine Ahnung, wie eQ-3 das Clear Channel Assessment (CCA) beim CC1310 implementiert hat.

Also davon hast DU definitiv mehr Ahnung als ich und das kann ich dir daher beim besten Willen nicht beantworten. Ich nehme nur wahr, das wenn auch der multimacd und die Firmware des Funkmodules offen zur Verfügung stehen würde wir inzwischen wirklich hier genug geballte Kompetenz auf verschiedenen Ebenen hätten um das (und andere) Thema alleine abzufrühstücken. Für den SCo hattest du ja schon ne eigene Firmware rausgebracht, wie wäre es mit einer eigenen Firmware für den RPI-RF-MOD (**träum**)

[TomTB]

Hallo zusammen,
vielen Dank für die Diskussion und dass Ihr Euch die Mühe macht, auf die Hinweise im Systemprotokoll einzugehen.
Ich muss nochmal sagen, dass ich in den letzten Monaten schlicht keine Zeit hatte, irgendetwas an meiner Heim-IT zu machen. Insofern müsste das Problem im System liegen. Fremde Webseiten, die zu Hängern führen könnten, frage ich nicht ab.
Mir ist gestern was aufgefallen, was zur Diskussion um den Funk passen könnte: Ich habe einen Schaltaktor HmIP-BS2 für einen Lichtschalter im Arbeitszimmer. Da scheint sich der Taster (also der Aufsatz draußen) verklemmt zu haben. Möglicherweise hat der Aktor um sein Leben gefunkt. Ich habe die "Verklemmung" gelöst und werde das ganze jetzt mal weiter beobachten. Gestern Abend und heute Morgen konnte ich keine Verzögerungen bemerken.
Freundliche Grüße, Tom

P.S.: Natürlich ist bei mir die Portweiterleitung ausgeschaltet

[jp112sdl]

mit einer eigenen Firmware für den RPI-RF-MOD

So lange HmIP eine verschlossene Schachtel bleibt, ist das nicht möglich.

Möglicherweise hat der Aktor um sein Leben gefunkt.

Könnte durchaus möglich sein.
Wenn der in seinen eigenen DC läuft, macht er erstmal Pause, dann ist auch erstmal Ruhe und alles geht für eine gewisse Weile, bis es wieder losgeht.
Man würde das sehen, wenn "Homematic Funk" auf "Alles loggen" steht.

[TomTB]

Das "Entklemmen" des Schaltaktors HmIP-BS2 hat nur kurzzeitig geholfen. Das Problem mit der verzögerten Reaktion der CCU trat wieder auf und hat sich über die folgenden Wochen verstärkt. Das Fehlerbild ließ vermuten, dass die CCU mit irgendwas ziemlich stark beschäftigt ist. Daher habe ich mal die Prozessorlast geprüft. Dabei hat sich herausgestellt, dass der CCU-Historian konstant mit mindestens 80 Prozent CPU-Last läuft und in Spitzen über längere Zeit auf 100 Prozent steht.
Daraufhin habe ich den CCU-Historian deinstalliert. Jetzt ist seit einer Woche Ruhe. Ich werde das noch ein paar Wochen beobachten. Falls alles ruhig bleibt und der CCU-Historian der Bösewicht ist, müsste ich ihn wohl auf einen separaten Raspi auslagern.
Tom

P.S.: Der CCU-Historian lief über Monate unauffällig auf der CCU

[McPan]

...
Vielleicht mal den USB Stick tauschen, denn

Code: Alles auswählen

user.info usbmount[254]: /dev/sda does not contain a filesystem or disklabel

...

Diese Meldung ist wahrscheinlich eher unkritisch, da es sich beim /dev/sda um die Gerätdatei des Sticks und nicht um eine Partition handelt. Dort ist vermtulich in der Tat weder ein Label, noch ein Dateisystem vorhanden.

Code: Alles auswählen

blkid /dev/sda

liefert da Einzelheiten.

[TomTB]

Danke für den Hinweis. Den USB-Stick hatte ich auch als nächstes auf der Uhr. Erstmal will ich noch etwas abwarten, ob das Problem nicht doch wieder auftritt. Dann USB-Stick-Tausch und Neuanwerfen des Historians und wenn das Problem wieder auftaucht dann separates System.
Freundliche Grüße, Tom

[TomTB]

Nach zwei Wochen ohne Auffälligkeiten habe ich den USB-Stick gegen eine SSD ausgetauscht und den CCU-Historian wieder installiert.
Das werde ich jetzt weiter beobachten.
Freundliche Grüße, Tom