RaspberryMatic – Firmware Upgrade Probleme - Analyse

[jmaus]

[...]
- egal wie lahm die Zentrale (oder dessen SD-Karte) ist, das Upgrade läuft durch
[...]
- die "Downtime" der Zentrale wird drastisch erhöht, grob gesagt verdoppelt

Das ist in der Tat den "Preis" den man eben für mehr Stabilität beim Update-Mechanismus bezahlt. Allerdings halte ich den für vertretbar und ganz so drastisch fällt der Unterschied gerade bei den modernen, schnellen RaspberryMatic-Arten (ova, tinkerboard, USB-SSD) ehrlich gesagt nicht aus. Auch macht man ein Update auch nicht täglich und wenn dann plant man normalerweise schon auch mehrere Minuten Downtime ein.

Ich persönlich finde die zusätzliche halbe Minute "Upgrade-Dauer" (alte Methode) akzeptabler als die teils doppelt so lange "Downtime" der Zentrale.
Zumal sich die halbe Minute ja sparen ließe wenn der Checksummen-Check nicht doppelt ausgeführt würde (alte Methode).

Die "alte Methode", (upload, entpacken, (prüfen) während die Zentrale "online" ist) sagte mir mehr zu.

Das (während die Zentrale online ist) war damals auch meine ursprüngliche Motivation, das in der laufenden WebUI zu erledigen. Allerdings ist das aber leider eben genau mit den Nebenwirkungen bei langsamen/alten Zentralenarten einhergegangen mit denen sich hier jetzt einige herumschlagen. Deshalb denke ich, ist das neue Verfahren nun eben von der herangehensweise konservativer und setzt mehr Wichtigkeit in die Zuverlässigkeit des Updates. Und ich denke der Punkt, das mit dem neuen Verfahren nun jede noch so langsame CCU-Hardware sich aktualisieren lässt zeigt das diese Herangehensweise im Zweifel eben die bessere ist.

[cloudman88]

Wäre es nicht gut die User zu informieren, dass ihre SD im Schneckentempo arbeitet?


Könnte das Update nicht die benötigte Zeit mitloggen und nach dem Start einen Hinweis ausgeben wenn die Zeiten auf eine extrem langsame SD schließen lassen?
Etwas wie' Das Update hat 33 Minuten benötigt. Eine schnellere SD ist empfohlen - link zu Wiki mit Erklärungen '

Macht soetwas Sinn? Oder ist es relativ egal weil die SD Performance absehen vom Update relativ egal ist.

Ich kann gern ein github issue erstellen .

[jmaus]

Etwas wie' Das Update hat 33 Minuten benötigt. Eine schnellere SD ist empfohlen - link zu Wiki mit Erklärungen '

Wenn dann sollte man eher die Schreib-Performance irgendwie messen (d.h. MB/sec) und dann ggf. warnen. Wüsste nun allerdings nicht genau wie man das bewerkstelligen sollte - auch ohne das man da auf dauer die SD Karte zu sehr belastet.

[cloudman88]

https://www.raspberrypi.org/blog/sd-card-speed-test/ dürfte etwas übertrieben sein. Eine interessante Info ist, dass also die sequentielle write performance > 10MB/s als Minium sehen .
Das tool dürfte allerdings etwas overkill sein.
Für eine grobe Einschätzung könnte man mit dd testen

Code: Alles auswählen

dd if=/dev/zero of=/var/tmp/speedTestFile bs=20M count=5 2>&1|tail -n 1|grep -o '[^,]*$' && rm /var/tmp/speedTestFile

Mein erster Versuch ein Tcl script zu schreiben

Code: Alles auswählen

set pipe [open "| /bin/dd if=/dev/zero of=/var/tmp/speedTestFile bs=20M count=5"]
set standard_output [read -nonewline $pipe]
set exit_status 0
if {[catch {close $pipe} standard_error] != 0} {
    global errorCode
    if {"CHILDSTATUS" == [lindex $errorCode 0]} {
        set exit_status [lindex $errorCode 2]
    }
}
puts "exit status: $exit_status"
 catch { exec /bin/sh -c "rm -f /var/tmp/speedTestFile"}
set comma [expr [string last , $standard_error] +2 ]

puts $comma
set speed [string range $standard_error $comma 99]
puts $speed

Leider bin mit dem Einbau in die Webpage überfordert ..

Der Test dauert nur ganz kurz und schreibt 100 MB. Eventuell könnte man den Test in das update script einbauen und vor dem upload laufen lassen. Oder als extra Button auf der Systemseite. Damit wäre auch eine Dauerbelastung der SD kein Thema.

Auf meiner proxmox raspberrymatic bekomme ich ca. 250 MB/s +/- 10% (PCEngines APU2 / SATA SSD)

Wie sage ich mach gern ein github issue dazu wenn ihr meint es würde Sinn machen. Keine Ahnung ob es viele der Kandidaten mit sehr langsamen SDs anregen würde in eine schnellere SD zu investieren

[jmaus]

Der Test dauert nur ganz kurz und schreibt 100 MB.

Wundert mich nicht das es nur ganz kurz dauert und bei dir 250MB zeigt, denn du lässt auf /var/tmp schreiben und das liegt eben im RAM weil es ein tmpfs ist

Eventuell könnte man den Test in das update script einbauen und vor dem upload laufen lassen.

Naja, davon halte ich beides nicht soviel, ehrlich gesagt. Wer probleme mit der Geschwindigkeit hat muss das eben von hand testen. Da jetzt ein dd einzubauen das 100mb bei bedarf auf die sd karte schreibt scheint mir overkill zu sein. Muss ich mal recherchieren ob es da nicht andere wege gibt die write performance so zu messen das man das ggf via watchdog integrieren lassen kann und dann warnt wenn sie unter einen gewissen wert fällt.

[cloudman88]

Ok
/var/temp war dann nicht so optimal. Da bei mir ein Update eh in ein paar Minuten durch ist habe ich mich kurz gewundert aber nicht groß gezweifelt
dd habe ich genommen weil es auf der Box ist und gleich die Schreibgewindigkeit anzeigt.
Nur vor dem Update um eben nicht regelmäßig die SD zu beanspruchen.

Aber ja ich bin auch nicht überzeugt, dass es einen wahnsinnig großen Nutzen hat. Ich war nur erstaunt mit welchen SDs manche ein System betreiben in das sie doch relativ viel investiert haben - vielleicht weil sie gar nicht wissen was sie da einsetzen

Und mit deinem letzten Patch dürften die timeouts auch Geschichte sein.

[jmaus]

Ok, nun hab ich mir dieses Raspberry Pi Agnostics tool das @cloudman88 hier vorgebracht hat etwas näher angeschaut. Dabei handelt es sich im Grund "nur" um eine graphische Oberfläche um das "fio" Kommandozeilenprogramm herum. D.h. es nutzt das fio programm, speichert diese Werte zwischen und stellt diese in der GUI dar.

Da es fio auch unter buildroot gibt habe ich den selben fio-basierten Test nun mal zur Upate-Routine hinzugefügt. D.h. Bevor das eigentlich update nun durchgeführt wird, macht er diesen Test und gibt dann die Testergebnisse aus und ggf. auch eine Warnung wenn dabei ein langsames Disk Medium festgestellt wird.

Aussehen tut das dann wie folgt:

Für ein schnelles Medium, z.B.

Code: Alles auswählen

[...]
[4/7] Checking storage performance.....sequential write: 458.29 MB/s (OK: > 10.0 MB/s), random write: 91530 IOPS (OK: > 500 IOPS), random read: 8414 IOPS (OK: > 1500 IOPS), PASSED
[...]

Und wenn die Grenzwerte unterschritten werden sieht das dann wie folgt aus:

Code: Alles auswählen

[...]
[4/7] Checking storage performance.......................sequential write: 4.88 MB/s (WARN! < 10.0 MB/s), random write: 600 IOPS (OK: > 500 IOPS), random read: 346 IOPS (WARN! < 1500 IOPS), WARNING: Update process will take considerable time!
[...]

D.h. nun sollte man ein entsprechendes Feedback und auch einen gewissen Anhaltspunkt haben wenn die Schreib/Leseperformance des darunter liegenden Storage systems entsprechend langsam ist und das zu einem sehr langsamen Firmware-Update führen kann.

[akimoto]

Lässt sich das auch in MONIT einbinden?

[jmaus]

Lässt sich das auch in MONIT einbinden?

Ja? Willst du wirklich das der Watchdog ständig/regelmäßig auf deine SD Karte etwas draufschreibt bis diese den Geist aufgibt?

[tomg1970]

Hallo, ich habe gerade auch versucht das aktuelle Update 3.57.5.20210424 einzuspielen.
https://github.com/jens-maus/RaspberryM ... 6.20210703

RaspberryMatic-3.59.6.20210703-ova.zip
251 MB

Bisher ging das immer ohne Probleme. Beim Update auf 3.59.6.20210703 habe ich nun gefühlt unendlich gewartet
und letztendlich startete die PROXOMOX LXC nicht mehr korrekt. Wie soll ich vorgehen bzw. wie kann ich herausfinden,
warum das Update dieses Mal nicht klappt?