[Guide] Ultra Low Power SSD NAS | 1G 0,85W Idle | 2.5G 1,00W Idle
- Ersteller ct100
- Erstellt am
ct100
Enthusiast
Thread Starter
- Mitglied seit
- 03.03.2004
- Beiträge
- 1.624
@Zyxx Ich habe diese Angebote verglichen (Mit Versand über Amazon, da keine Zollproblematik und unkomplizierte Rückgabe):
Durch den 5% Coupon beim NanoPC gleicher Preis für die Sets. Aber der NanoPC hat eMMC inklusive während man beim OrangePi ein extra Modul kaufen muss.
Wo hast du den OrangePi 5 Plus für 50€ weniger gefunden? Ist das mit Versand aus China? Oder gibt es noch ein günstigeres Set mit Plastikgehäuse irgendwo?
Durch den 5% Coupon beim NanoPC gleicher Preis für die Sets. Aber der NanoPC hat eMMC inklusive während man beim OrangePi ein extra Modul kaufen muss.
Wo hast du den OrangePi 5 Plus für 50€ weniger gefunden? Ist das mit Versand aus China? Oder gibt es noch ein günstigeres Set mit Plastikgehäuse irgendwo?
ct100
Enthusiast
Thread Starter
- Mitglied seit
- 03.03.2004
- Beiträge
- 1.624
Update: Armbian 24.5.0 Community & OMV 7, Neuer SSD-Vergleich inklusive der Samsung 990 Pro 4TB, Erfahrungsbericht nach über einem halben Jahr Betrieb.
-----------------
Mittlerweile gibt es Armbian 24.5.0 für den NanoPi R6C. Leider wurde der NanoPi R6C/S wie auch viele andere SBC-Modelle von Armbian auf Community Support heruntergestuft, was im Prinzip bedeutet dass es keine offiziellen Stable-Images mehr gibt. Die aktuelle Armbian Bookworm Community Trunk Version funktioniert aber soweit ohne Probleme.
OpenMediaVault wurde am 03.03.2024 in der Version 7 veröffentlicht. Damit ist es nun endlich nicht mehr Notwendig selbst Images über das Armbian-Build Script zu erzeugen.
Eine Neuinstallation sieht jetzt wie folgt aus:
1. Armbian Bookworm Minimal Community Image von https://www.armbian.com/nanopi-r6s/ herunterladen und auf SD-Karte schreiben (z.b. mit Etcher).
2. Die ArmbianEnv.txt kann am PC noch vor dem Einsetzen der SD-Karte in den NanoPi angepasst werden.
3. Den NanoPi mit der SD-Karte starten und über SSH verbinden. Ein Monitor oder Tastatur/Maus anzuschließen ist nicht notwendig. User/Passwort: root/1234
4. Neues Root Passwort vergeben. Ein neuer Benutzer muss hier nicht angelegt werden, das kann später über das OMV-Webgui erfolgen.
5. (Optional) Das System mit nand-sata-install von SD-Karte auf eMMC übertragen und ohne SD-Karte neu starten.
6. Das InstallScript von https://github.com/OpenMediaVault-Plugin-Developers/installScript über SSH ausführen.
7. Im OMV-Webgui anmelden und das System konfigurieren.
8. Fertig.
-----------------
Ich habe heute die Samsung 990 Pro 4TB mit 8nm Pascal-Controller und 236-Layer TLC V8 V-NAND im NanoPi getestet. Da die neue Armbian-Version zu leicht unterschiedlichen Verbrauchswerten führt, habe ich die Werte der anderen SSDs ebenfalls neu gemessen (siehe neuen Abschnitt im 1. Post).
Leider ist die 990 Pro eine Enttäuschung was den Verbrauch im niedrigsten APST State und ASPM L1 Modus angeht. Der 4GB große DRAM-Cache wird dabei sicherlich eine Rolle spielen, aber mir scheint auch, dass der 236-Layer V8 V-NAND nicht der große Durchbruch in Sachen Effizienz ist.
Von der Geschwindigkeit gibt es keinen großen Unterschied zwischen 990 Pro 4TB und NM790 4TB (auch nicht mit PCIe 4.0 x4). Da die 990 Pro 4TB aber deutlich teurer ist werde ich sie wahrscheinlich zurückgeben und mir mehr Lexar NM790 4TB kaufen.
Noch eine kleine Ergänzung für 0db Fans: Mir ist bei dem Test aufgefallen, dass ein Teil des minimalen Spulenfiepens am NanoPi R6C von der M.2 SSD kommt und nicht vom NanoPi selbst. Die NM790 hat die leisesten elektronischen Geräusche, danach kommt die SK Hynix Gold und am lautesten war die 990 Pro.
-----------------
Nachdem ich nun mehrere der NanoPi R6C als Mini NAS / Server über mehr als ein halbes Jahr im Betrieb habe hier mein Erfahrungsbericht:
- Als Mini-NAS mit mehreren Docker Containern inkl. Jellyfin: Wer mit 4TB Speicher auskommt und kein 4K Transcoding benötigt, für den ist es durch den niedrigen Verbrauch sehr gut geeignet. Ich konnte damit den Idle-Verbrauch einer ganzen Wohnung!!! auf 14W senken (Mit aktivem DSL/Netzwerk/WLAN/Server/Standby-Geräte ohne Kühl-/Gefriergeräte).
- Als externes Backup für einen Proxmox Host: Wer mit 4TB Speicher auskommt für den ist es perfekt. Da das System 24/7 läuft gibt es keine Probleme, dass die Verbindung zum Speicher in Proxmox plötzlich dauerhaft verloren geht (wenn man einen Backup-Server täglich automatisch starten und herunterfahren lässt).
Die größte Schwäche des NanoPi R6C ist definitiv die Software (Legacy Vendor Kernel) und insbesondere der Treiber des Realtek Ethernet Controllers. Wer plant den NanoPi mit 2.5G als NAS von verschiedensten PCs mit hohen Datenvolumen zu betreiben wird keine Freude damit haben. Es ist möglich mit hoher Last in bestimmten Konstellationen die Ethernet Verbindung des NanoPi stark zu verlangsamen oder zu crashen.
Um das System wirklich perfekt zu machen bräuchte es meiner Meinung nach eine gute Unterstützung im Mainline Kernel für den RK3588 inkl. fehlerfreier Realtek Ethernet Controller Kernel Treiber und eine gute Auswahl an günstigen/sparsamen 8TB M.2 SSDs.
-----------------
Mittlerweile gibt es Armbian 24.5.0 für den NanoPi R6C. Leider wurde der NanoPi R6C/S wie auch viele andere SBC-Modelle von Armbian auf Community Support heruntergestuft, was im Prinzip bedeutet dass es keine offiziellen Stable-Images mehr gibt. Die aktuelle Armbian Bookworm Community Trunk Version funktioniert aber soweit ohne Probleme.
OpenMediaVault wurde am 03.03.2024 in der Version 7 veröffentlicht. Damit ist es nun endlich nicht mehr Notwendig selbst Images über das Armbian-Build Script zu erzeugen.
Eine Neuinstallation sieht jetzt wie folgt aus:
1. Armbian Bookworm Minimal Community Image von https://www.armbian.com/nanopi-r6s/ herunterladen und auf SD-Karte schreiben (z.b. mit Etcher).
2. Die ArmbianEnv.txt kann am PC noch vor dem Einsetzen der SD-Karte in den NanoPi angepasst werden.
3. Den NanoPi mit der SD-Karte starten und über SSH verbinden. Ein Monitor oder Tastatur/Maus anzuschließen ist nicht notwendig. User/Passwort: root/1234
4. Neues Root Passwort vergeben. Ein neuer Benutzer muss hier nicht angelegt werden, das kann später über das OMV-Webgui erfolgen.
5. (Optional) Das System mit nand-sata-install von SD-Karte auf eMMC übertragen und ohne SD-Karte neu starten.
6. Das InstallScript von https://github.com/OpenMediaVault-Plugin-Developers/installScript über SSH ausführen.
7. Im OMV-Webgui anmelden und das System konfigurieren.
8. Fertig.
-----------------
Ich habe heute die Samsung 990 Pro 4TB mit 8nm Pascal-Controller und 236-Layer TLC V8 V-NAND im NanoPi getestet. Da die neue Armbian-Version zu leicht unterschiedlichen Verbrauchswerten führt, habe ich die Werte der anderen SSDs ebenfalls neu gemessen (siehe neuen Abschnitt im 1. Post).
Leider ist die 990 Pro eine Enttäuschung was den Verbrauch im niedrigsten APST State und ASPM L1 Modus angeht. Der 4GB große DRAM-Cache wird dabei sicherlich eine Rolle spielen, aber mir scheint auch, dass der 236-Layer V8 V-NAND nicht der große Durchbruch in Sachen Effizienz ist.
Von der Geschwindigkeit gibt es keinen großen Unterschied zwischen 990 Pro 4TB und NM790 4TB (auch nicht mit PCIe 4.0 x4). Da die 990 Pro 4TB aber deutlich teurer ist werde ich sie wahrscheinlich zurückgeben und mir mehr Lexar NM790 4TB kaufen.
Noch eine kleine Ergänzung für 0db Fans: Mir ist bei dem Test aufgefallen, dass ein Teil des minimalen Spulenfiepens am NanoPi R6C von der M.2 SSD kommt und nicht vom NanoPi selbst. Die NM790 hat die leisesten elektronischen Geräusche, danach kommt die SK Hynix Gold und am lautesten war die 990 Pro.
-----------------
Nachdem ich nun mehrere der NanoPi R6C als Mini NAS / Server über mehr als ein halbes Jahr im Betrieb habe hier mein Erfahrungsbericht:
- Als Mini-NAS mit mehreren Docker Containern inkl. Jellyfin: Wer mit 4TB Speicher auskommt und kein 4K Transcoding benötigt, für den ist es durch den niedrigen Verbrauch sehr gut geeignet. Ich konnte damit den Idle-Verbrauch einer ganzen Wohnung!!! auf 14W senken (Mit aktivem DSL/Netzwerk/WLAN/Server/Standby-Geräte ohne Kühl-/Gefriergeräte).
- Als externes Backup für einen Proxmox Host: Wer mit 4TB Speicher auskommt für den ist es perfekt. Da das System 24/7 läuft gibt es keine Probleme, dass die Verbindung zum Speicher in Proxmox plötzlich dauerhaft verloren geht (wenn man einen Backup-Server täglich automatisch starten und herunterfahren lässt).
Die größte Schwäche des NanoPi R6C ist definitiv die Software (Legacy Vendor Kernel) und insbesondere der Treiber des Realtek Ethernet Controllers. Wer plant den NanoPi mit 2.5G als NAS von verschiedensten PCs mit hohen Datenvolumen zu betreiben wird keine Freude damit haben. Es ist möglich mit hoher Last in bestimmten Konstellationen die Ethernet Verbindung des NanoPi stark zu verlangsamen oder zu crashen.
Um das System wirklich perfekt zu machen bräuchte es meiner Meinung nach eine gute Unterstützung im Mainline Kernel für den RK3588 inkl. fehlerfreier Realtek Ethernet Controller Kernel Treiber und eine gute Auswahl an günstigen/sparsamen 8TB M.2 SSDs.
Zuletzt bearbeitet:
ct100
Enthusiast
Thread Starter
- Mitglied seit
- 03.03.2004
- Beiträge
- 1.624
Also über SSH geht es definitiv nicht. Wenn man das Upgrade nicht headless macht und vorher Armbian auf Beta Branch umstellt, sollte es gehen.
Ich habe Armbian und OMV sicherheitshalber komplett neu installiert.
Hallo ct100, vielen Dank für diesen interessanten Beitrag!
Leider komme ich nur auf 1,3W-1,4W...
Mein Setup:
NanoPi R6C 8GB + Ugreen CD122 + Lexar NM790 1TB
Armbian_community 24.5.0-trunk.279 Bookworm with Linux 6.1.43-vendor-rk35xx
Leider komme ich nur auf 1,3W-1,4W...
Ich befürchte, das ist bei mir der Fall (EEE status: enabled - inactive). Was kann falsch konfiguriert sein?
Bash:
root@nanopi:~# ethtool --show-eee enP3p49s0
EEE settings for lan1:
EEE status: enabled - inactive
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: Not reportedMein Setup:
NanoPi R6C 8GB + Ugreen CD122 + Lexar NM790 1TB
Armbian_community 24.5.0-trunk.279 Bookworm with Linux 6.1.43-vendor-rk35xx
ct100
Enthusiast
Thread Starter
- Mitglied seit
- 03.03.2004
- Beiträge
- 1.624
Das liegt nicht an der Netzwerkkonfiguration sondern daran, dass du statt Legacy Kernel den Vendor Kernel installiert hast.
Im Armbian 5.10.y Legacy Kernel ist der Realtek r8125 Treiber enthalten mit dem sich sowohl EEE mit 2.5G als auch ASPM L1 für den Realtek 2.5G Ethernet Adapter aktivieren lassen.
linux-rockchip/drivers/net/ethernet/realtek at rk-5.10-rkr5.1 · armbian/linux-rockchip
Improved Rockchip Linux. Contribute to armbian/linux-rockchip development by creating an account on GitHub.
github.com
Im Armbian 6.1.y Vendor Kernel ist der r8125 Treiber nicht enthalten und dein Netzwerkadapter benutzt wohl den Realtek r8169 Kernel Treiber bei dem EEE und evtl. auch ASPM L1 deaktiviert ist.
linux-rockchip/drivers/net/ethernet/realtek at rk-6.1-rkr1 · armbian/linux-rockchip
Improved Rockchip Linux. Contribute to armbian/linux-rockchip development by creating an account on GitHub.
github.com
Welcher Treiber aktiv ist sieht du mit:
Code:
lspci -vvv | grep driverEs wird tatsächlich der von dir genannte Treiber genutzt:
Danke für die Aufklärung! Ich stecke in der Linux Materie nicht so tief drin...
Also müsste ich entweder ein älteres Image installieren oder einfach damit leben, richtig?
Was ich noch gefunden hatte: Was ist von einer nachträglichen Treiber Installation wie hier zu halten?
Code:
Kernel driver in use: r8169Also müsste ich entweder ein älteres Image installieren oder einfach damit leben, richtig?
Was ich noch gefunden hatte: Was ist von einer nachträglichen Treiber Installation wie hier zu halten?
Haste dazu mal ein Ticket (Issue) aufgemacht? Das kann ja prinzipiell nur im Laufe der "kontinuierlichen Verbesserung" verschlimmbessert worden sein. Glaube nicht, dass da soooo viel Code im Treiber geändert worden sein kann seit dem. Lohnt sich vielleicht.
ct100
Enthusiast
Thread Starter
- Mitglied seit
- 03.03.2004
- Beiträge
- 1.624
Das Einfachste ist wahrscheinlich mit dem Armbian Buildscript ein Image mit Legacy Kernel zu erzeugen.
In der Config für den NanoPi R6 gibt es Legacy, Vendor und Edge.
build/config/boards/nanopi-r6s.csc at main · armbian/build
Armbian Linux build framework generates custom Debian or Ubuntu image for x86, aarch64, riscv64 & armhf - armbian/build
github.com
Evtl. könnte Armbian den r8125 Treiber auch in den 6.1.y Vendor Kernel integrieren. Müsste man nachfragen.
In diesen Custom Vendor Kerneln wird sich keiner die Mühe machen das zu fixen. Wenn es einen Bug in bestimmten Konfigurationen mit EEE gibt wird es einfach ausgeschaltet... fertig.
Leider fehlt immer noch einiges für den Linux Mainline Support des SoC.
mainline-status.md · main · hardware-enablement / Rockchip RK3588 upstream enablement efforts / Notes for Rockchip 3588 · GitLab
Collabora GitLab
gitlab.collabora.com
Ich kann nur wärmstens das SmartPower 3 empfehlen (bspw. bei Pollin ohne Heckmeck zu beziehen), sieht man hier links im Bild (und ich werde Support dafür bald in den Monitoring-Modus von sbc-bench einbauen): https://github.com/ThomasKaiser/Kno...ick_Preview_of_ROCK_5_ITX.md#sata-power-ports
Danke für die detaillierten Tests, endlich mal wer, den das interessiert und der auch das nötige Wissen/Instrumentarium hat, das nicht nur stumpf zu testen sondern zu verbessern.
Code:
root@rock-5-itx:/home/radxa# . /usr/local/bin/sbc-bench.sh
root@rock-5-itx:/home/radxa# CheckPCIe
* ASMedia ASM1164 Serial ATA AHCI: Speed 8GT/s (ok), Width x2 (ok), driver in use: ahci, ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
* Realtek RTL8125 2.5GbE: Speed 5GT/s (ok), Width x1 (ok), driver in use: r8125, ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=150us PortTPowerOnTime=150us PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns T_PwrOn=10us
* Realtek RTL8125 2.5GbE: Speed 5GT/s (ok), Width x1 (ok), driver in use: r8125, ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=150us PortTPowerOnTime=150us PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=0ns T_PwrOn=10usUnd dann hab ich zu meinem Erstaunen feststellen müssen, dass die Armbian-Leute über Neujahr (vermutlich im Suff) den default cpufreq governor von ondemand (mit Tweaks, also io_is_busy=1 & Co.) auf schedutil umgestellt haben, was in Theorie der bessere/modernere/was-weiß-ich-noch-allesere Governor ist aber in der Praxis für ein deutliches Einbrechen von real-world Storage- und vor allem NAS-Performance (Netzwerk + Storage) sorgt, da zumindest in meinen Tests der cpufreq-Treiber die CPU-Cores nur auf niedrigen/mittleren Taktfrequenzen herumdümpeln läßt: https://github.com/armbian/build/pull/6120#issuecomment-2063923403
Ich wäre erfreut, wenn noch wer anders mal testen könnte, idealerweise mit Windows Explorer und parallel mit Helios LanTest (10GbE-Setting), weil der Explorer seit Windows 7 ein paar Tricks anwendet, mit denen das schedutil-Verhalten wegmaskiert werden könnte: http://www.helios.de/viewart-de.html?id=1711 (Link zu LanTest ebendort ganz unten).
Zuletzt bearbeitet:
Haldi
Enthusiast
- Mitglied seit
- 10.06.2012
- Beiträge
- 540
Es ist eben nicht nur ein "governor" der im Nachhinein sagt das die CPU zu 99% ausgelastet war und daher nun für die nächste iteration höher Takten muss, sondern es ist die Integration von EAS, Energy Aware Scheduling das im vornherein bereits vorhersieht wie viel Arbeit die CPU zu erledigen hat in der nächsten iteration.
Je nach dem ob nun WALT oder PELT zum Einsatz kommt sind da anderen Tuning Parameter vorhanden.
Im Grunde benötigt EAS aber ein PowerProfile das sagt auf welcher Stufe die CPU wie viel Strom verbraucht damit es funktionieren kann. Was für Server eigentlich nicht so wichtig ist sondern nur für Mobile geräte.
Je nachdem wie Schedutil implementiert ist hat es aber auch gewisse tuning Einstellungen die man Manuel modifizieren kann um die Performance zu verbessern...
Aber allzugut kenn ich mich mit dem Thema auch nicht aus.
Zuletzt bearbeitet:
Damit schedutil das überhaupt leisten könnte, braucht's aber korrekt gesetzte Properties wie dynamic-power-coefficient und/oder sched-energy-costs und natürlich fehlen die für den RK3588 in allen Kernel-Versionen: https://github.com/armbian/build/pull/6120#issuecomment-2067695778 und rk3588s.dtsi hier https://github.com/radxa/kernel oder da https://gitlab.collabora.com/hardwa...boot/dts/rockchip/rk3588s.dtsi?ref_type=heads
Und abgesehen von der Theorie reicht ein simpler Test in der Praxis, um sich zu überzeugen, dass schedutil in erster Linie dafür sorgt, die Taktfrequenzen niedrig zu halten, was nicht mal aus Sicht eines potentiell niedrigeren Verbrauchs einen Sinn macht, weil wir immer noch mit dem "race to idle"-Konzept zu tun haben und ein Task, der dreimal schneller erledigt ist, weil die Taktfrequenzen sofort nach oben schnellen am Ende sparsamer erledigt sein kann als wenn die Taktfrequenzen moderat bzw. niedrig bleiben. Das mit dem EAS funktioniert leider nur ganz oder gar nicht.
ct100
Enthusiast
Thread Starter
- Mitglied seit
- 03.03.2004
- Beiträge
- 1.624
Das ist aber für die Sekundärseite. Das Problem ist die Primärseite noch genauer zu messen z.b. um genauere Werte für die Effizienz von Netzteilen im Ultra-Low-Power Bereich zu haben.
Das AVM FRITZ!DECT200 ist für den Preis sehr gut. Viele 230V-Messgeräte sind unter 1W nutzlos.
Kennst du ein bezahlbares 230V-Messgerät mit besserer Messgenauigkeit unter 1W?
Das ist keine Überraschung, da durch ARM bigLittle und Intel Hybrid CPU Architecture ein neuer Governor notwendig wurde, und das ist eben schedutil. Ondemand wird nicht mehr wirklich weiterentwickelt.
Ich benutze schedutil schon seit Jahren.
Dann sollte man die korrekten Werte eintragen. Du wirst die Umstellung von ondemand zu schedutil als Default nicht aufhalten können.
Ich hab hier neben zwei FRITZ!DECT200 einmal sowas https://www.netio-products.com/en/device/powercable-rest-101x und einmal sowas https://www.netio-products.com/en/device/powerbox-4kx – ob die genauer messen weiß ich nicht, wobei sich ja eh die Schwierigkeit stellt, was die Referenz sein soll. Jedenfalls weichen die Fritzen voneinander ab und die NetIO-Teile liefern auf beiden Geräten an allen 5 Buchsen quasi identische Werte.
Und Hauptvorteil für mich: API, über das man die Dinger aus Tools raus befragen und in sinnigen Modi (Durchschnittswerte bildend und nicht nur zappelnde Kurve angucken) wirklich runter auf 10mW messen kann, um Optimierungen zu testen.
Ist mir alles bekannt – ich bin der Typ, der vor 7,5 Jahren in Armbian das für eine Board-Familie umgestellt und dann ein halbes Jahr später wieder zurückgestellt hat: https://github.com/search?q=repo:armbian/build+schedutil&type=commits
Und wer soll dieser "man" sein? Der SoC-Hersteller (Rockchip) hat die entsprechenden Properties
Edit: grad Situation mit Amlogic geprüft: da fehlten früher sogar die capacity-dmips-mhz-Properties komplett und alle haben sich gewundert, warum der Scheduler so gerne alles auf die kleinen A53-Cores packt und die A73 "schont".
Und wie bereits geschrieben: Auf RK3588 kommt durch simplen Wechsel zu schedutil erstmal nur "alles viel langsamer" raus, was man aber vermutlich unter Windows nicht mitbekommt, wenn man nur den einen Use Case "fette Dateien herumkopieren" berücksichtigt und alles andere, was ein NAS sonst noch in flott erledigen sollte (bspw. Directory Enumeration, Locking, kleine Dateien herumkopieren, etc. pp.), konsequent ignoriert.
Zuletzt bearbeitet:
Haldi
Enthusiast
- Mitglied seit
- 10.06.2012
- Beiträge
- 540
Hahahahahah nein!
Weiss nicht wie weit sich das in den letzten par Jahren verbesser hat... aber als EAS so langsam am kommen war und die ersten Smartphones von haus aus mit EAS ausgeliefert wurden hatten die Grossen hersteller noch keinen blassen was das ist oder wie man das aufüllt. Ich wette die nehmen heute auch noch alle einfach die Default values die sie vom SoC hersteller bekommen.
Ja, völlig klar. Ich wollte auch von den "großen Smartphone-SoC-Herstellern" schreiben, hab das SoC aber verschludert. Qualcomm, Samsung, HiSilicon, etc. – bei den Läden dürften sich Experten damit auseinandersetzen und auf Messungen beruhende Properties in die *.dtsi klatschen, wobei ich auch da Commits im Mainline-Kernel gesehen habe, die die Werte komplett in Frage gestellt und korrigiert haben (sinngemäß: mit dem Datenmüll kommt nie ein Task auf die little cores).
Und eben bzgl. Snapdragon 8cx Gen 3 geguckt (weil von Armbian "supported") und dort fehlen die Properties ebenso (ja, auch capacity-dmips-mhz) aber da gibt's qcom,freq-domain mit unterschiedlichen Werten je Cluster was vermutlich/hoffentlich Identisches bewirkt wie capacity-dmips-mhz+dynamic-power-coefficient oder es ist relativ egal, wohin der Scheduler Tasks senden will, weil das in Wirklichkeit eine Ebene drunter gesteuert wird (Firmware-BLOB).
Dafür spräche, dass wenn man auf bspw. auf dem Microsoft Dev Kit unter Windows ein Linux in WSL2 laufen läßt, dieses nicht vier A78C + vier X1C sieht sondern dem Gast deren acht X1C präsentiert werden. Und am Ende in der VM die single-threaded Performance absurderweise höher ist als wenn Linux nativ läuft: siehe die beiden "Qualcomm Snapdragon 8cx Gen 3"-Einträge hier: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
Nee, das ist Blödsinn, gerade die tinymembench- und ramlat-Werte angeguckt: wenn der SoC unter Windows bootet, ist die DRAM-Initialisierung drastisch besser als wenn Linux direkt gebootet wird (wurde) und deshalb schneidet die VM in Teilen besser ab. Und was man zumindest an den 7-ZIP-MIPS sieht, ist, dass in der VM der Scheduler keine Kontrolle darüber hat, auf welchen physischen Kernen der Wirt das Ganze scheduled – das wird aber auch schon nur an WSL2 liegen.
Ich hab mal versucht, schedutil auf RK3588 legacy ein wenig zu reparieren: https://github.com/armbian/linux-rockchip/pull/175 (die Werte sind zwar offensichtlicher Blödsinn aber was soll's, interessiert ja eh keinen)
@ct100 könntest Du mal bitte LanTest auf Dein NAS loslassen? Vorher/nachher wäre spannend aber zumindest bei einem schnellen Test hier tat sich eh nichts. Insofern wären LanTest-Nummern mit schedutil vs. performance spannender. Umschalten super simpel als root per:
@ct100 könntest Du mal bitte LanTest auf Dein NAS loslassen? Vorher/nachher wäre spannend aber zumindest bei einem schnellen Test hier tat sich eh nichts. Insofern wären LanTest-Nummern mit schedutil vs. performance spannender. Umschalten super simpel als root per:
Code:
for Cluster in /sys/devices/system/cpu/cpufreq/policy* ; do [[ -e "${Cluster}" ]] || break; echo performance >"${Cluster}/scaling_governor"; doneTja, stellt sich raus: auch dem ist nicht so, die Werte von den SoC-Vendors sind teils frei gewürfelt, teils falsch ermittelt: https://github.com/armbian/build/pull/6120#issuecomment-2075003397
Und auf der Basis soll schedutil dann sein 'energy aware scheduling" betreiben? Ein klein wenig unrealistisch würde ich sagen...
Und letzte Runde in diesem Selbstgespräch... je mehr man in Richtung schedutil / EAS guckt, desto schlimmer wird es, vor allem auf der Plattform, um die es hier im Thread geht: RK3588
github.com
Die beiden für schedutil unabdingbaren Properties capacity-dmips-mhz und dynamic-power-coefficient werden nach Anleitung falsch erzeugt (ARM rät zu Dhrystone obwohl ARM schon 14 Jahre vorher in epischer Breite davor gewarnt hat, dass dieser Benchmark von 1984, der zwar damals existente Computer passabel messen konnte, heute natürlich nur noch ein schlechter Witz ist) oder seitens der Hersteller willentlich oder unabsichtlich falsch befüllt.
Anfrage an Rockchip, ob sie vorhaben, die RK3588-Properties mal mit was Richtigem zu befüllen, ging gestern raus. Aber selbst wenn dynamic-power-coefficient mal richtig gesetzt sein sollte, ist der capacity-dmips-mhz -Wert, den Rockchip für die A55 gewürfelt hat, immer noch falsch. Dhrystone überschätzt die kleinen A55 systematisch aber Rockchip's Wert ist noch blöder als das, was man mit Dhrystone messen würde. Wobei, das ist ja ein reiner Compiler(flag)-Benchmark, also kann durchaus sein, dass sie bei RK durch Verwendung eines anderen Compilers zu anderem DMIPS-Quatsch kommen.
Jedenfalls mir jetzt endlich klar, warum mit schedutil alles abseits Volllast deutlich lahmer wird, die kleinen Kerne werden a) systematisch überschätzt und b) bleiben die Taktfrequenzen konsequent unten. Kann man wie schon zweimal erwähnt problemlos mit LanTest nachvollziehen. Aber natürlich nicht mit "Volllast-Benchmarks" wie Geekbench, Phoronix oder auch sbc-bench. Der tut's aber gut fürs Monitoring des ganzen Elends:
Kleine Dateien fliegen per SMB an und es wäre was zu tun (also Taktfrequenzen nach oben reißen und idealerweise Tasks auf die big Cores hieven) aber auf Basis der Schrott-Properties kann schedutil natürlich nicht anders, als zu versagen
Ich wollte mir jetzt grad noch den Inhalt von /sys/devices/system/cpu/cpu[04]/cpu_capacity vs. /sys/kernel/debug/energy_model/cpu[04]/ps:1800000 angucken bzw. mal nachrechnen, ob das, was sie beim Ermitteln der dynamic-power-coefficient-Properties durch Durchschnittswertbildung wegschmeißen auch nur ansatzweise durch die Formel des energy models wieder kompensiert wird. Aber eigentlich langweilt mich das Ganze an der Stelle langsam nur noch. Die Zeit ist wohl besser investiert, passende cgroup-Settings für Samba/OMV zu bauen nebst statischer IRQ-Affinity für RK3588-Devices...
Knowledge/articles/schedutil-and-EAS.md at master · ThomasKaiser/Knowledge
Contribute to ThomasKaiser/Knowledge development by creating an account on GitHub.
github.com
Die beiden für schedutil unabdingbaren Properties capacity-dmips-mhz und dynamic-power-coefficient werden nach Anleitung falsch erzeugt (ARM rät zu Dhrystone obwohl ARM schon 14 Jahre vorher in epischer Breite davor gewarnt hat, dass dieser Benchmark von 1984, der zwar damals existente Computer passabel messen konnte, heute natürlich nur noch ein schlechter Witz ist) oder seitens der Hersteller willentlich oder unabsichtlich falsch befüllt.
Anfrage an Rockchip, ob sie vorhaben, die RK3588-Properties mal mit was Richtigem zu befüllen, ging gestern raus. Aber selbst wenn dynamic-power-coefficient mal richtig gesetzt sein sollte, ist der capacity-dmips-mhz -Wert, den Rockchip für die A55 gewürfelt hat, immer noch falsch. Dhrystone überschätzt die kleinen A55 systematisch aber Rockchip's Wert ist noch blöder als das, was man mit Dhrystone messen würde. Wobei, das ist ja ein reiner Compiler(flag)-Benchmark, also kann durchaus sein, dass sie bei RK durch Verwendung eines anderen Compilers zu anderem DMIPS-Quatsch kommen.
Jedenfalls mir jetzt endlich klar, warum mit schedutil alles abseits Volllast deutlich lahmer wird, die kleinen Kerne werden a) systematisch überschätzt und b) bleiben die Taktfrequenzen konsequent unten. Kann man wie schon zweimal erwähnt problemlos mit LanTest nachvollziehen. Aber natürlich nicht mit "Volllast-Benchmarks" wie Geekbench, Phoronix oder auch sbc-bench. Der tut's aber gut fürs Monitoring des ganzen Elends:
Code:
sbc-bench -m
Time cpu0/cpu4/cpu6 load %cpu %sys %usr %nice %io %irq Temp DC(V)
11:30:35: 1416/ 408/ 408MHz 0.52 4% 2% 1% 0% 0% 0% 41.6°C 12.03
11:30:40: 1200/ 408/ 408MHz 0.48 0% 0% 0% 0% 0% 0% 40.7°C 12.03
11:30:45: 1200/ 408/ 408MHz 0.44 0% 0% 0% 0% 0% 0% 40.7°C 12.03
11:30:50: 1416/ 408/ 408MHz 0.41 0% 0% 0% 0% 0% 0% 40.7°C 12.05
11:30:55: 1200/ 408/ 408MHz 0.37 4% 1% 1% 0% 0% 0% 40.7°C 12.03
11:31:00: 1416/ 408/ 600MHz 0.42 11% 4% 4% 0% 2% 0% 40.7°C 12.03
11:31:05: 1200/ 408/ 408MHz 0.71 16% 9% 3% 0% 0% 3% 41.6°C 12.04
11:31:10: 1200/ 408/ 816MHz 0.81 23% 16% 1% 0% 0% 5% 42.5°C 12.02
11:31:15: 1200/ 408/ 408MHz 0.99 11% 8% 0% 0% 1% 1% 41.6°C 12.03
11:31:21: 1200/ 408/ 408MHz 0.91 13% 9% 0% 0% 0% 3% 41.6°C 12.03
11:31:26: 1416/ 408/ 408MHz 1.00 22% 16% 0% 0% 0% 3% 41.6°C 12.03
11:31:31: 1200/ 600/1008MHz 0.92 22% 17% 1% 0% 0% 3% 42.5°C 12.05
11:31:36: 1200/ 408/ 408MHz 0.92 19% 12% 1% 0% 1% 3% 42.5°C 12.03
11:31:41: 1200/ 408/ 408MHz 0.93 14% 7% 1% 0% 0% 5% 42.5°C 12.04Kleine Dateien fliegen per SMB an und es wäre was zu tun (also Taktfrequenzen nach oben reißen und idealerweise Tasks auf die big Cores hieven) aber auf Basis der Schrott-Properties kann schedutil natürlich nicht anders, als zu versagen
Ich wollte mir jetzt grad noch den Inhalt von /sys/devices/system/cpu/cpu[04]/cpu_capacity vs. /sys/kernel/debug/energy_model/cpu[04]/ps:1800000 angucken bzw. mal nachrechnen, ob das, was sie beim Ermitteln der dynamic-power-coefficient-Properties durch Durchschnittswertbildung wegschmeißen auch nur ansatzweise durch die Formel des energy models wieder kompensiert wird. Aber eigentlich langweilt mich das Ganze an der Stelle langsam nur noch. Die Zeit ist wohl besser investiert, passende cgroup-Settings für Samba/OMV zu bauen nebst statischer IRQ-Affinity für RK3588-Devices...
Zuletzt bearbeitet:
Selbstgespräch, nächster Teil:
Sportlich: Faktor 1,9 Unterschied in Abhängigkeit von Compiler-Version/-Settings. Auch sonst würde ich mal grob zustimmen, was Benchmark vs. Real-World angeht. Dann noch Coremark-Ergebnisse getrennt für beide RK3588-Cluster geschickt:
Also laut Coremark schafft ein A76 9675.433196 Iterations/Sec bei 1416 MHz, was ihn laut diesem Benchmark um Faktor 1,9 schneller macht als einen A55 bei gleicher Taktfrequenz (5031.561614 Iterations/Sec).
Das coremark-Binary, das sie nutzen, haben sie mitgeschickt. Warum das mit einem GCC 6.3.1 in 2017 gebaut wurde, sei mal dahingestellt. Ich habe mal den aktuellen Coremark in Ubuntu Jammy mit defaults übersetzt und (nicht so) überraschend ändern sich die Werte: verbessern sich mit GCC 11.3 gebaut um 15%. Kann aber grad nicht big.LITTLE getrennt testen, weil unterwegs und nur MacBook dabei, wo in einer Linux-VM keinerlei Kontrolle herrscht, auf welchem Core der Wirt-CPU ein Task läuft.
Dann waren noch die EAS-Meßergebnisse beigelegt für den RK3588, wobei auffällig ist, dass die DMIPS in Wirklichkeit Coremark-"Iterations/Sec" sind, wenn auch marginal abweichend von der Textausgabe weiter oben):
Problematisch bei der "Meßdaten"-Erfassung ist, dass sie falsch ist, denn Rockchip benutzt in allen SoCs seit ca. 10 Jahren PVTPLL, um die reale Taktfrequenz einzustellen, d.h. man kann zwar den cpufreq-Treiber anweisen, 2400 MHz zu wählen, aber das interessiert die Hardware nicht, da die wirkliche Taktfrequenz nur von drei Faktoren bestimmt wird: Chip-Qualität (Silicon Lottery), Supply Voltage und Temperatur. Ein A76, der mit 2400 MHz takten soll, wird in Wirklichkeit oftmals nur mit 2200 MHz takten. Mehr dazu in diesem Kommentar: https://www.collabora.com/news-and-...rce-boot-chain-for-rockchips-rk3588/#qcom4018
Heißt: das, was Rockchip da messen wollte, ist nicht das, was sie gemessen haben, was man auch auf einen Blick an der blauen Kurve da oben sieht, denn die darf rechts oben nicht mehr abflachen, wäre richtig gemessen worden.
Davon abgesehen wäre ja Sinn der Übung gewesen, die beiden Parameter capacity-dmips-mhz und dynamic-power-coefficient zu liefern, was nicht geschah bzw. nun teils verständlich ist.
capacity-dmips-mhz basiert auf "Benchmarking gone wrong" (Coremark genauso wie Dhrystone völlig offensichtlich nicht geeignet, den wirklichen Unterschied zwischen Performance- und Effizienz-Kernen richtig zu benennen) und dynamic-power-coefficient basiert auf "Measurements gone wrong" (Messungen, die von Phantasiewerten bzgl. Taktfrequenz ausgehen und PVTPLL ignorieren sind halt in Teilen wertlos, dazu kommt aber noch die Methodik des arithmetischen Mittels, die die ganze Idee an sich zum Scheitern verurteilen könnte – werde ich mir erst in paar Wochen angucken können).
Zwischenfazit: schedutil/EAS broken by design und/oder Implementierung. Kann (unter ARM) nicht richtig funktionieren.
Antwort schlug heute früh auf: 这个和dhrystone/coremark的版本，编译器选项的关系很大，我之前用的coremark测试出来结果是1.9倍左右。实际上，还要考虑真实的使用情况，A76/A55性能比较无法给出一个很好的量化值。
Sportlich: Faktor 1,9 Unterschied in Abhängigkeit von Compiler-Version/-Settings. Auch sonst würde ich mal grob zustimmen, was Benchmark vs. Real-World angeht. Dann noch Coremark-Ergebnisse getrennt für beide RK3588-Cluster geschickt:
Code:
A76@1416M
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 11369
Total time (secs): 11.369000
Iterations/Sec : 9675.433196
Iterations : 110000
Compiler version : GCC6.3.1 20170404
Compiler flags : -O2 --static -DPERFORMANCE_RUN=1 -lrt
Memory location : Please put data memory location here
(e.g. code in flash, data on heap etc)
seedcrc : 0xe9f5
[0]crclist : 0xe714
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0x33ff
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 9675.433196 / GCC6.3.1 20170404 -O2 --static -DPERFORMANCE_RUN=1 -lrt / Heap
A55@1416M
[ 185.372203][ T578] healthd: battery l=50 v=3300 t=2.6 h=2 st=3 c=-1600 fc=100 chg=au
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 21862
Total time (secs): 21.862000
Iterations/Sec : 5031.561614
Iterations : 110000
Compiler version : GCC6.3.1 20170404
Compiler flags : -O2 --static -DPERFORMANCE_RUN=1 -lrt
Memory location : Please put data memory location here
(e.g. code in flash, data on heap etc)
seedcrc : 0xe9f5
[0]crclist : 0xe714
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0x33ff
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 5031.561614 / GCC6.3.1 20170404 -O2 --static -DPERFORMANCE_RUN=1 -lrt / HeapAlso laut Coremark schafft ein A76 9675.433196 Iterations/Sec bei 1416 MHz, was ihn laut diesem Benchmark um Faktor 1,9 schneller macht als einen A55 bei gleicher Taktfrequenz (5031.561614 Iterations/Sec).
Das coremark-Binary, das sie nutzen, haben sie mitgeschickt. Warum das mit einem GCC 6.3.1 in 2017 gebaut wurde, sei mal dahingestellt. Ich habe mal den aktuellen Coremark in Ubuntu Jammy mit defaults übersetzt und (nicht so) überraschend ändern sich die Werte: verbessern sich mit GCC 11.3 gebaut um 15%. Kann aber grad nicht big.LITTLE getrennt testen, weil unterwegs und nur MacBook dabei, wo in einer Linux-VM keinerlei Kontrolle herrscht, auf welchem Core der Wirt-CPU ein Task läuft.
Dann waren noch die EAS-Meßergebnisse beigelegt für den RK3588, wobei auffällig ist, dass die DMIPS in Wirklichkeit Coremark-"Iterations/Sec" sind, wenn auch marginal abweichend von der Textausgabe weiter oben):
Problematisch bei der "Meßdaten"-Erfassung ist, dass sie falsch ist, denn Rockchip benutzt in allen SoCs seit ca. 10 Jahren PVTPLL, um die reale Taktfrequenz einzustellen, d.h. man kann zwar den cpufreq-Treiber anweisen, 2400 MHz zu wählen, aber das interessiert die Hardware nicht, da die wirkliche Taktfrequenz nur von drei Faktoren bestimmt wird: Chip-Qualität (Silicon Lottery), Supply Voltage und Temperatur. Ein A76, der mit 2400 MHz takten soll, wird in Wirklichkeit oftmals nur mit 2200 MHz takten. Mehr dazu in diesem Kommentar: https://www.collabora.com/news-and-...rce-boot-chain-for-rockchips-rk3588/#qcom4018
Heißt: das, was Rockchip da messen wollte, ist nicht das, was sie gemessen haben, was man auch auf einen Blick an der blauen Kurve da oben sieht, denn die darf rechts oben nicht mehr abflachen, wäre richtig gemessen worden.
Davon abgesehen wäre ja Sinn der Übung gewesen, die beiden Parameter capacity-dmips-mhz und dynamic-power-coefficient zu liefern, was nicht geschah bzw. nun teils verständlich ist.
capacity-dmips-mhz basiert auf "Benchmarking gone wrong" (Coremark genauso wie Dhrystone völlig offensichtlich nicht geeignet, den wirklichen Unterschied zwischen Performance- und Effizienz-Kernen richtig zu benennen) und dynamic-power-coefficient basiert auf "Measurements gone wrong" (Messungen, die von Phantasiewerten bzgl. Taktfrequenz ausgehen und PVTPLL ignorieren sind halt in Teilen wertlos, dazu kommt aber noch die Methodik des arithmetischen Mittels, die die ganze Idee an sich zum Scheitern verurteilen könnte – werde ich mir erst in paar Wochen angucken können).
Zwischenfazit: schedutil/EAS broken by design und/oder Implementierung. Kann (unter ARM) nicht richtig funktionieren.
Moin!
Ich bekomme die aktuellen Images einfach nicht zum laufen. Armbian_23.8.2_Nanopi-r6s_bookworm_legacy_5.10.160_minimal.img läuft sofort, also sollte ja meine generelle "Technik" funktionieren.
Das Problem fängt schon bei 2. an, da kann ich die ArbianEnv.txt nicht unter Windows anpassen, weil das Dateisystem auf der SD KArte nach dem flashen ext4 ist. Also umständlich mit einem anderen Linux PC gemountet und dort "replace fdtfile=rockchip/rk3588s-nanopi-r6s.dtb in /boot/armbianEnv.txt with fdtfile=rockchip/rk3588s-nanopi-r6c.dtb" befolgt. Hilft aber alles nichts, die rote SYS Lampe leuchtet nur und nix passiert.
Ich habe diese Images probiert:
Armbian_community_24.8.0-trunk.139_Nanopi-r6s_bookworm_edge_6.10.0-rc3_minimal.img.xz
Armbian_community_24.8.0-trunk.139_Nanopi-r6s_bookworm_vendor_6.1.43_minimal.img.xz
Hat jemand ne Idee?
ct100
Enthusiast
Thread Starter
- Mitglied seit
- 03.03.2004
- Beiträge
- 1.624
Der 2. Punkt ist ein "kann" kein "muss". Der NanoPi R6C bootet auch wenn man die armbianEnv.txt nicht vorher geändert hat.
Diese aktuellen trunk.xxx Images sind automatisch erzeugt, da gibt es keine Garantie, dass die funktionieren. Insbesondere der edge Kernel ist sehr experimentell.
Ich würde dir empfehlen mit dem Armbian Build Framework ein neues Bookworm Minimal Image mit Legacy Kernel zu erzeugen.
Zuletzt bearbeitet:
HisN
Legende
- Mitglied seit
- 09.06.2006
- Beiträge
- 31.920
Was funktioniert denn zur Zeit Deiner Meinung nach am besten, abgesehen von der AES-Problematik^^
Bei mir kommt die Tage ein
Friend lyelec cm3588 core board kit 2,5g rockchip rk3588 cpu entwicklungs board 4xpcie 2. 0 4k/8k cm3588 nas sdk kit 4 nvme hdmi in - AliExpress 7
Smarter Shopping, Better Living! Aliexpress.com
de.aliexpress.com
4x nvme-NAS an.
@tkaiser @ct100 @Haldi
Mit welchem OS-Image fange ich an? Da gehts ja schon los, wenn man die freie Auswahl hat^^
CM3588 - FriendlyELEC WiKi
Geplant ist ein Linux mit OMV. Ein träumchen wäre noch zfs als Filesystem für die Datenpartition. Aber das war auf dem Raspi5 schon erschreckend lahm beim schreiben (auch ohne Komprimierung).
Gewohnt bin ich das Raspberry-OS, also Debian.
Mit Debian bookworm anfangen, oder mit dem fertigen OVM-Image? rk3588-XYZ-openmediavault-6.1-YYYYMMDD.img.gz
Zuletzt bearbeitet:
HisN
Legende
- Mitglied seit
- 09.06.2006
- Beiträge
- 31.920
Als Laie gar nicht so einfach.
Ich hab tatsächlich ein passendes Minimal-Image von Armbian für den RK3588 gefunden (alter, warum sind die Bezeichnungen immer so kryptisch) auf eine SD-Karte gepackt und natürlich nicht davon gebootet.
Das System hat die SD-Card ignoriert und immer fleissig vom internen eMMC gebootet.
Also den internen Speicher über ein DevTool gelöscht, dann wollte er auch von der SD booten.
Kurz angemeldet und dann die SD in den eMMC geschrieben.
Kernel-Sourcen .. gibts für den nightly-build nicht. Also per Armbian-Config auf ein stable build gewechselt.
Kernel-Source installiert, ZFS installiert, OMV installiert.
Viel gelesen und mit x-systemd.automount die Laufwerke von meinem alten Filer durchgereicht, der nicht mehr ständig laufen wird. So kann ich drauf zugreifen, ohne ständig von Hand nachfummeln zu müssen.
Plex installiert.
Das ganze in ein Gehäuse geschraubt und im Technikraum untergebracht.
Soweit so gut.
Kann man eigentlich den "Guide" im 1. Post (der zur Zeit aus "nutze Armbian und füge diese Zeile in die Textdatei ein besteht) in irgend einer Form einem Laien etwas näher bringen? Z.b. indem man erklärt, wie man ein passendes Image aus den 1000 vorhandenen für seine Hardware findet? Und wie man das ganze von der SD auf eMMC bekommt?
Die Performance-Einbrüche die der Raspi5 mit dem 4xnvme-Head relativ regelmäßig produziert hat sind mit dem neuen Unterbau weg. Gefällt mir gut. Ist keine Rakete, aber völlig in Ordnung.
Das System braucht zur Zeit während Plex die neue Datenbank aufbaut und ich die SSDs vom Server aus befülle etwa 5W vom Shelly Plug S gemessen. Sauber. Wenn er nix tut geht er auf 3W runter.
Ich hab tatsächlich ein passendes Minimal-Image von Armbian für den RK3588 gefunden (alter, warum sind die Bezeichnungen immer so kryptisch) auf eine SD-Karte gepackt und natürlich nicht davon gebootet.
Das System hat die SD-Card ignoriert und immer fleissig vom internen eMMC gebootet.
Also den internen Speicher über ein DevTool gelöscht, dann wollte er auch von der SD booten.
Kurz angemeldet und dann die SD in den eMMC geschrieben.
Kernel-Sourcen .. gibts für den nightly-build nicht. Also per Armbian-Config auf ein stable build gewechselt.
Kernel-Source installiert, ZFS installiert, OMV installiert.
Viel gelesen und mit x-systemd.automount die Laufwerke von meinem alten Filer durchgereicht, der nicht mehr ständig laufen wird. So kann ich drauf zugreifen, ohne ständig von Hand nachfummeln zu müssen.
Plex installiert.
Das ganze in ein Gehäuse geschraubt und im Technikraum untergebracht.
Soweit so gut.
Kann man eigentlich den "Guide" im 1. Post (der zur Zeit aus "nutze Armbian und füge diese Zeile in die Textdatei ein besteht) in irgend einer Form einem Laien etwas näher bringen? Z.b. indem man erklärt, wie man ein passendes Image aus den 1000 vorhandenen für seine Hardware findet? Und wie man das ganze von der SD auf eMMC bekommt?
Die Performance-Einbrüche die der Raspi5 mit dem 4xnvme-Head relativ regelmäßig produziert hat sind mit dem neuen Unterbau weg. Gefällt mir gut. Ist keine Rakete, aber völlig in Ordnung.
Das System braucht zur Zeit während Plex die neue Datenbank aufbaut und ich die SSDs vom Server aus befülle etwa 5W vom Shelly Plug S gemessen. Sauber. Wenn er nix tut geht er auf 3W runter.
Zuletzt bearbeitet:
Ziemlich heftiger Preis oder? Bei Friendlyelec direkt gibts das Ding mit 16GB RAM und 64GB emcc für 174$: https://www.friendlyelec.com/index.php?route=product/product&product_id=294
Und ZFS könnte auch gehen, mit etwas Aufwand: https://www.reddit.com/r/RISCV/comments/tda69c/zfs_on_a_single_core_riscv_hardware_with_512mb/
HisN
Legende
- Mitglied seit
- 09.06.2006
- Beiträge
- 31.920
Wenn Du Shipping und Zoll drauf rechnest bist Du beim gleichen Preis den Aliexpress aufruft. Ich hab zum Kaufzeitpunkt fast 90$ Rabatt bekommen. Das fehlt bei der Preisangabe von FE.
Ich glaube mich zu erinnern das Versand schon 40$ rum beträgt.
Ich glaube mich zu erinnern das Versand schon 40$ rum beträgt.
Zuletzt bearbeitet:
Ich hab versucht das System auf die eMMC zu installieren, allerdings geht das nicht mit folgendem Fehler beim Booten. Hab viel dazu gegoogled, aber keine Lösung gefunden.
// Update: Musste alles neu installieren und habe das uboot-package vom update ausgeschlossen. Bisher OK.
// Update: Musste alles neu installieren und habe das uboot-package vom update ausgeschlossen. Bisher OK.
DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
LPDDR4X, 2112MHz
channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
Manufacturer ID:0x1
CH0 RX Vref:27.9%, TX Vref:19.8%,20.8%
CH1 RX Vref:27.1%, TX Vref:21.8%,20.8%
CH2 RX Vref:27.9%, TX Vref:19.8%,19.8%
CH3 RX Vref:27.1%, TX Vref:20.8%,20.8%
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 1560MHz
change to F0: 2112MHz
out
U-Boot SPL board init
U-Boot SPL 2017.09-armbian (May 21 2024 - 16:21:13)
unknown raw ID 0 0 0
unrecognized JEDEC id bytes: 00, 00, 00
Trying to boot from MMC2
spl: partition error
Trying fit image at 0x4000 sector
## Verified-boot: 0
## Checking atf-1 0x00040000 ... sha256(7efcd01a0f...) + OK
## Checking uboot 0x00200000 ... sha256(2f31ed4655...) + OK
## Checking fdt 0x0031ec90 ... sha256(c5d44f02b4...) + OK
## Checking atf-2 0x000f0000 ... sha256(da90adf3a4...) + OK
## Checking atf-3 0xff100000 ... sha256(1163474a5b...) + OK
Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000)
Total: 430.20/581.170 ms
INFO: Preloader serial: 2
NOTICE: BL31: v2.3():v2.3-589-g3389cfddaerrick.huang
NOTICE: BL31: Built : 10:14:29, May 9 2023
INFO: spec: 0x13
INFO: ext 32k is valid
INFO: ddr: stride-en 4CH
INFO: GICv3 without legacy support detected.
INFO: ARM GICv3 driver initialized in EL3
INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0
INFO: system boots from cpu-hwid-0
INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001
INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz
INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz
INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz
INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz
INFO: BL31: Initialising Exception Handling Framework
INFO: BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR: Error initializing runtime service opteed_fast
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x200000
INFO: SPSR = 0x3c9
U-Boot 2017.09-armbian (May 21 2024 - 16:21:13 +0000)
Model: NanoPi R6S
MPIDR: 0x81000000
PreSerial: 2, raw, 0xfeb50000
DRAM: 8 GiB
Sysmem: init
Relocation Offset: eda3f000
Relocation fdt: eb9f9960 - eb9fecd0
CR: M/C/I
Using default environment
optee check api revision fail: -1.0
optee api revision is too low
### ERROR ### Please RESET the board ###
Zuletzt bearbeitet:
