Problemanalyse Klana's RM auf Tinkerboard

[Baxxy]

Vielleicht sieht man mit strace was.

Man sieht leider nur die (sich wiederholende) Ausgabe die du schon gepostet hast.

Werksreset und dann einfach nur die regadom rüberkopieren und rega neustarten und schauen ob das schon reicht bzw. die Auslastung dann auch so hoch ist...

Hier bekomme ich keine klaren Erkenntnisse. Es scheint als würde die regadom dabei "aufgeräumt" (es fehlen ja alle Geräte). Dabei wird die Größe der regadom drastisch reduziert (~23MB auf ~4MB) was im Endeffekt dazu führt das das Speichern beim Ausloggen "schneller" geht und somit die ReGa kürzer die 100% CPU überschreitet.

Mal eine unwissenschaftliche Berechnung:
Größe regadom ~23MB, beim Ausloggen wird die homematic.regadom.new mit identischer Größe geschrieben.
"Speicherzeit" bis Version 3.73.9.20240130: ~15s --> ~ 1,5MB/s
"Speicherzeit" ab Version 3.75.6.20240316: ~55s --> ~ 0,42MB/s

Hier beim Testen verhält sich die 3.73.9.20240130 noch "normal".
@Klana meinte ja die geht bei ihm schon nicht mehr während @monte74 und @onkeltommy die 3.73.9.20240130 als "letzte funktionierende Version" bezeichneten.

Es liegt auch nicht am emmc, das Verhalten ab der 3.75.6.20240316 ist auch mit SD-Karte zu sehen.

[jmaus]

Werksreset und dann einfach nur die regadom rüberkopieren und rega neustarten und schauen ob das schon reicht bzw. die Auslastung dann auch so hoch ist...

Hier bekomme ich keine klaren Erkenntnisse. Es scheint als würde die regadom dabei "aufgeräumt" (es fehlen ja alle Geräte). Dabei wird die Größe der regadom drastisch reduziert (~23MB auf ~4MB) was im Endeffekt dazu führt das das Speichern beim Ausloggen "schneller" geht und somit die ReGa kürzer die 100% CPU überschreitet.

Komisch, wenn er die regadom aufräumt, dann vielleicht wegen den HmIP Gerätefiles die dann auf fehlen? vielleicht müsstest du die dann noch drinlassen und quasi nur die regadom + gerätefiles in eine frische installation übernehmen um zu sehen was los ist bzw. andere Effekte auszuschließen.

Mal eine unwissenschaftliche Berechnung:
Größe regadom ~23MB, beim Ausloggen wird die homematic.regadom.new mit identischer Größe geschrieben.
"Speicherzeit" bis Version 3.73.9.20240130: ~15s --> ~ 1,5MB/s
"Speicherzeit" ab Version 3.75.6.20240316: ~55s --> ~ 0,42MB/s

Hier beim Testen verhält sich die 3.73.9.20240130 noch "normal".
@Klana meinte ja die geht bei ihm schon nicht mehr während @monte74 und @onkeltommy die 3.73.9.20240130 als "letzte funktionierende Version" bezeichneten.

Es liegt auch nicht am emmc, das Verhalten ab der 3.75.6.20240316 ist auch mit SD-Karte zu sehen.

Ok, danke für die Tests. Wenn es wirklich so ist das die 3.73.9.20240130 die letzte "funktionierende" ist bzw. höhere Schreibraten der ReGaHss zulässt und quasi die 3.75.6.20240316 die erste version ist die mit dem Tinkerboard irgendwie probleme macht, dann sehe ich da mit Blick auf das ChangeLog nur einen Zusammenhang in der Umstellung von Kernel 6.1 zu Kernel 6.6 und den damit verbundenen Änderungen beim Linux Kernel. Komisch nur das die 6.6.x aber auch bei HomeAssistant und auch bei Armbian verteilt wird und dort bisher soweit ich sehe kann keine Problemmeldung eingegangen ist.

Was man nun machen könnte wäre mal den 6.1 Linux Kernel der 3.73.9.20240130 Version zu nehmen (das /zImage file im rootfs) und in die problematische Kernel 6.6 betriebene 3.75.6.20240316 bzw. neuer einfach hinzukopieren und dann neuzustarten. Es werden dann zwar einige Kernel module vom 6.6er kernel (und auch die Treiber für das RPI-RF-MOD, usw.) nicht geladen werden aber für die Tests bzgl. der Speicherzeit der regadom sollte das unerheblich sein. Hauptsache das System fährt mit dem 6.1er kernel ordnungsgemäß hoch und die ReGaHss lässt sich starten.

Was man parallel dann auch noch testen könnte wäre mal sich die Ausgabe im RecoverySystem bzgl. der RW Speeds anzuschauen wenn er ein Updateprozess durchläuft. Dann testet er ja den Speed des darunterliegenden Mediums. Vielleicht fällt da ja bereits was auf.

Und was natürlich auch noch helfen könnte wäre, wenn ich das Backup bzw. die regadom mal hier hätte und damit testen könnte um zu sehen ob ich das irgendwie reproduziert bekomme mit meinen eigenen Tinkerboards, dann könnte ich da mit meinen Mittels auch noch das Eine oder Andere mir genauer anschauen. Der Tipp von @jp112sdl war aber auch schon nicht schlecht mal mit dem strace genauer hinzuschauen was da so passiert und das dann mit den Ausgaben der früheren Versionen zu vergleichen ob die ReGa sich hier unter den problematischen Versionen anders verhält.

[Baxxy]

Da muss ich mal schauen was ich da umgesetzt bekomme. Wenn @Klana sein OK gibt bekommst du das Backup später.

Die einfachen Schreib-Tests mit dd zeigten nur minimale Unterschiede.
Was aber noch aufgefallen ist:
Wenn ich mit der 3.75.7.20240420 eine Firmware zwecks Downgrade über die WebUI-Funktion hochlade, dann ist die Uploadrate definitiv geringer als bei der 3.73.9.20240130.

Die Ausgaben vom Recovery bezüglich RW-Speed gucke ich mir später mal an.

[Baxxy]

die Ausgabe im RecoverySystem

warum auch immer ließ sich die Ausgabe des Recovery nicht im Browser ansehen, daher hier von Hand:

Code: Alles auswählen

3.75.7.20240420 --> 3.73.9.20240130: sequential write: 13.84 MB/s / random write: 705 IOPS / random read: 1905 IOPS
3.73.9.20240130 --> 3.75.7.20240420: sequential write: 16.69 MB/s / random write: 737 IOPS / random read: 1962 IOPS 

Unterschiede ja, aber nicht soo groß. (Daten sind von SD-Karten-Boot)

Aber, ich habe mir mal den Spaß gemacht und die Zeit für UP/Downgrade gestoppt.
(System mit dem Backup von @Klana. Zeit gilt ab "hochladen" in der WebUI (kein Backup anlegen) inklusive zügigem durchklicken aller "Dialoge" bis ich wieder in der WebUI bin.)
3.75.7.20240420 --> 3.73.9.20240130: 12:30
3.73.9.20240130 --> 3.75.7.20240420: 10:40

wäre mal den 6.1 Linux Kernel der 3.73.9.20240130 Version zu nehmen (das /zImage file im rootfs) und in die problematische Kernel 6.6 betriebene 3.75.6.20240316 bzw. neuer einfach hinzukopieren und dann neuzustarten

Das mit dem Kernelimage-Austausch habe ich zwar hinbekommen, danach ist das Tinker-S aber quasi unbenutzbar. Lokal am Monitor komme ich zwar dran, remote geht aber nix mehr.

Auswertung:
Grundsätzlich kann ich die Probleme der betroffenen Tinker-S Nutzer ab 3.75.6.20240316 hier nachvollziehen. Das Tinker-S läuft gefühlt mit angezogener Handbremse was m.E. ein Problem des OS ist und nichts mit den jeweiligen "Programmierkünsten" der User zu tun hat.

Da ich hier mit meiner Expertise am Ende bin übergebe ich das Backup an Jens.

[Xel66]

Das Tinker-S läuft gefühlt mit angezogener Handbremse was m.E. ein Problem des OS ist und nichts mit den jeweiligen "Programmierkünsten" der User zu tun hat.

Es mag ja sein, dass es durch irgendwelche Prozesse ausgelastet ist oder I/O langsam abläuft. Wenn aber nach Aktionen der DC nach oben schießt, kann das eher nichts mit der langsamen Arbeitsweise des Systems zu tun haben. Genau so dürfte es wenig Auswirkungen auf den CS haben. Dieses sind ja auch zwei immer wieder angeführte Symptome.

Gruß Xel66

[jmaus]

Grundsätzlich kann ich die Probleme der betroffenen Tinker-S Nutzer ab 3.75.6.20240316 hier nachvollziehen. Das Tinker-S läuft gefühlt mit angezogener Handbremse was m.E. ein Problem des OS ist und nichts mit den jeweiligen "Programmierkünsten" der User zu tun hat.

Da ich hier mit meiner Expertise am Ende bin übergebe ich das Backup an Jens.

Danke Baxxy für deine Analysen. Ich hab inzwischen auch einfach mal auf gut Glück ein paar Änderungen bzw. Kernel patches ausgetauscht gegen die die das Armbian Projekt für deren Kernel 6.6 nutzt. Vielleicht entfesselt das ja das Tinkerboard bereits und dann wäre das zumindest ein Ansatz um weiter zu schauen. Wenn du also bitte noch mit dem morgigen nightly snapshot schauen könntest ob vielleicht eine Besserung eintritt wär das hilfreich.

[jmaus]

Das Tinker-S läuft gefühlt mit angezogener Handbremse was m.E. ein Problem des OS ist und nichts mit den jeweiligen "Programmierkünsten" der User zu tun hat.

Es mag ja sein, dass es durch irgendwelche Prozesse ausgelastet ist oder I/O langsam abläuft. Wenn aber nach Aktionen der DC nach oben schießt, kann das eher nichts mit der langsamen Arbeitsweise des Systems zu tun haben. Genau so dürfte es wenig Auswirkungen auf den CS haben. Dieses sind ja auch zwei immer wieder angeführte Symptome.

Wie ich in dem anderen Thread bereits ausgeführt habe, kann ich mir bei ganz schlechter Performance des zugrundeliegenden OS/Boards vorstellen das es dazu zwangsläufig zu einer erhöhung der DC kommen kann, einfach weil dann vielleicht das System Funktelegramme wiederholen muss weil es in Timeouts oder ähnliches rennt. Und das wiederrum kann natürlich auch zu einem erhöhten CS führen weil damit ja das Funkband zwangsläufig etwas ausgelasteter wird. Aber das nur nebenbei. Bleiben wir mal bitte bei der Sache der Analysen bzgl. der möglichen Performanceprobleme des OS unter einem Tinkerboard...

[Baxxy]

Dieses sind ja auch zwei immer wieder angeführte Symptome.

Ich bin da grundsätzlich bei die Xel.
Ich kann aber inzwischen auch mit Gewissheit sagen das in den letzten beiden RM-Versionen für das Tinker-S irgendwas faul ist was das ganze System beeinträchtigt.
Auch kann ich sagen das eQ-3 mit der 3.75.7 am HmIP-Server bezüglich Multicast - Routing/Repeating geschraubt hat was unter Umständen zu höherem DC und ggf. auch häufigeren CS-Spitzen führt. Mehr "kann" ich dazu nicht sagen.

Klana's System liegt hier "nackt" vor mir. Es ist relativ groß und besteht primär aus HmIP-Geräten. Ich habe stichprobenartig in ein paar Programme gelunscht, konnte aber erstmal nichts negatives feststellen. Das ganze sieht mir eher nach "Musterschüler-Programmierung" aus.

[Baxxy]

Vielleicht entfesselt das ja das Tinkerboard bereits

Hoffen wir mal das Beste. Gucke ich mir dann morgen an.

[Xel66]

... kann ich mir bei ganz schlechter Performance des zugrundeliegenden OS/Boards vorstellen das es dazu zwangsläufig zu einer erhöhung der DC kommen kann, einfach weil dann vielleicht das System Funktelegramme wiederholen muss weil es in Timeouts oder ähnliches rennt.

Da, verglichen mit moderneren Systemen, eine CCU2 sehr schwachbrüstig daherkommt, müsst dann der DC dieser ggf. auch (etwas) höher gegenüber der potenteren Hardware sein. Und ich denke mal, die "Probleme" sind eher auch nur gefühlter Natur, weil das WebUI und Dateioperationen vergleichbar zäh daherkommen. Aber im Normalbetrieb (also ohne dass der Anwender im WebUI rumklickt) langweilt sich einen CCU-CPU nur, da das System im Grunde (aus historischen Gründen) ja sehr ressourcenschonend designt ist. Lediglich Addons nehmen nicht zwangsweise darauf Rücksicht. Aber wir werden es erleben, wenn die Handbremse des Kernel gelöst ist und die das Bord mit voller Performance läuft. Bin gespannt.

Gruß Xel66