[Guide] Ultra Low Power SSD NAS | 1G 0,85W Idle | 2.5G 1,00W Idle

Für so einen Zweck kann ich dir nur empfehlen mal Jellyfin anzuschauen, statt lediglich eine Freigabe über Samba zu planen. Mit Jellyfin kann man separate Profile für die Familienmitglieder einrichten und der Zugriff auf die Medien ist auch über den Webbrowser und diverse Apps möglich.
Danke für den Hinweis. Das schaue ich mir genauer an. (y)

Mit SATA ist es nicht möglich einen so niedrigen Idle Stromverbrauch zu erreichen.
Das war mir so nicht bewußt, macht aber, bei genauerer Betrachtung, Sinn.
Ja. Das System wird in der Regel über SSH und/oder ein Webinterface verwaltet. Bei der Verwendung von Armbian kann auch die Ersteinrichtung headless über SSH erfolgen.
Prima, danke für die Info!

btw: Ich habe mich jetzt vorerst für einen Lenovo m90q Gen4 entschieden (ein Thread im Unraid-Forum zur Lenovo-m-Serie hat mich getriggert). Dort können 2 NVME's sowie 1x SATA verbaut werden. Das RK3588-Projekt ist aber deshalb nicht gestorben sondern ich überlege, dieses genau für den Jellyfin-Use-Case (Bereitstellung von Medien für die Kinder/Familie) einzusetzen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das CM3588 gefällt mir. Das könnte meinen HP Microserver Gen8 ersetzen :unsure:. Jemand eine Idee wie viel Strom das ganze mit 4 SSD benötigt?

.... wobei die Anschaffungskosten mit 4x4TB SSD sich im Bereich von 1000€ bewegt. Das muss man durch Stromsparen erst mal wieder reinkommen :)
 
Zuletzt bearbeitet:
Es ist wohl so weit:

Sieht interessant aus. Würde mir ein kompakteres Layout und ein Gehäuse dafür wünschen, aber für den Anfang nicht schlecht.

Gibt es auch schon auf Amazon Marketplace mit Versand aus China ab 209€.

Jemand eine Idee wie viel Strom das ganze mit 4 SSD benötigt?

Ich schätze mal 2-3W im Idle. Vorrausgesetzt man findet ein Netzteil mit 90%+ Effizenz dafür und benutzt hocheffiziente SSDs.
 
Problem mAn ist momentan eher das noch nicht vorhandene/existierende(?) Gehäuse. Zumindest bin ich bei meiner Recherche noch auf keines gestoßen. Für das hier beschriebene Gerät gibt es ein tolles Metallgehäuse. So etwas würde ich mir auch für das NAS-Kit wünschen.
 
Update: Stromverbrauchswerte des NanoPi R6C 8GB mit verschiedenen Netzwerkkonfigurationen. Neue Vergleichsgrafik. Stromverbrauchstests von mehreren 2.5G Switches.


Mein ursprünglicher Messwert von 1,5W für das NAS mit 2.5G war anscheinend ohne aktives Energy Efficient Ethernet gemessen, da der verwendete Switch kein EEE unterstützt, obwohl er es laut Hersteller angeblich kann. Mit einem neuen D-Link 2.5G Switch verbraucht das NAS mit 2.5G Ethernet und EEE aktiv lediglich 1,00W!

Leider scheint es insbesondere bei günstigen 2.5G Switches viele schwarze Schafe zu geben, die kein EEE und im schlimmsten Fall überhaupt keine Energiesparmodi unterstützen. Dies ist in mehrfacher Hinsicht ein Problem, da nicht nur der Switch selbst mehr verbraucht und sehr warm wird, sondern auch die daran angeschlossenen Geräte mangels EEE mehr Strom verbrauchen und höhere Temperaturen aufweisen.

Ich kann nur jedem raten nach dem Kauf eines neuen Switches den Stromverbrauch zu messen und zu überprüfen ob der Switch tatsächlich EEE (802.3az) unterstützt. So sieht es aus wenn das EEE korrekt unterstützt wird (unter Linux):

Code:
> ethtool --show-eee enP3p49s0
EEE settings for enP3p49s0:
        EEE status: enabled - active
        Tx LPI: 0 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
                                   2500baseX/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
                                    2500baseX/Full
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full
                                                 2500baseX/Full


Zum Thema stromsparende 2.5G Netzwerke:

- D-Link als Switch Hersteller sticht was das Thema Energiesparen angeht sehr positiv heraus. Sparsam im Idle und das EEE funktioniert an verschiedensten Geräten einwandfrei.

- Im Idle mit aktivem EEE verbrauchen 1G Verbindungen an 2.5G Switches fast genau so viel wie 2.5G Verbindungen. D.h. wer z.B. einen 8 Port 1G Switch durch einen 8 Port 2.5G Switch ersetzt, obwohl nur wenige Geräte 2.5G-fähig sind, verbrät pro 1G Gerät ~0,25W mehr im Switch. In diesem Fall ist es besser einen Kombiswitch wie den D-Link DMS-107 zu kaufen, oder die 1G Geräte in die LAN-Ports des Internet-Routers zu stecken.

- Eine minimale 2.5G Konfiguration (1x Router, 1x 2.5G Switch, 1x NAS, 1x PC) hat im Vergleich zu einer minimalen 1G Konfiguration (1x Router, 1x NAS, 1x PC) einen Mehrverbrauch von ~2W im Idle (vorausgesetzt EEE ist an allen Geräten aktiv).

- Managed Switches, PoE-Switches, Switches mit mehr als 8 Ports und/oder Lüftern verbrauchen signifikant mehr Energie und eignen sich in der Regel nicht für ein sehr stromsparendes Netzwerk.


Kombination von externen Netzteilen mehrerer Geräte:

- Mehrere Einzelnetzteile z.b. von NAS, Switch, Router etc. durch ein einzelnes USB-C Netzteil mit mehren Ausgängen und USB-C to DC Adapter zu ersetzen führt nicht zu einem geringeren Gesamt Idle-Verbrauch, da die Netzteile nicht effizient genug sind in niedrigen Lastbereichen.

- Wenn alle Geräte die gleiche Spannung akzeptieren ist es möglich durch ein einziges, hocheffizientes Single Voltage Netzteil ein wenig im Idle einzusparen. Lohnt sich aber meiner Meinung nach nur wenn man dies mit einer DC USV kombinieren kann.
 
Zuletzt bearbeitet:
Mittlerweile gibt es Armbian Bookworm mit 6.7 Edge Kernel für den NanoPi R6 und Openmediavault 7 Beta. Ich habe das auf einem meiner NanoPi getestet.

Leider alles noch sehr Experimentell selbst für ein Headless NAS. Für einen produktiven Einsatz definitiv nicht zu empfehlen.

Was den Idle-Verbrauch angeht deutlich schlechter wie der 5.10.y Legacy Vendor-Kernel. ASPM L1 funktioniert nur teilweise und im Realtek 8169 Kernel Treiber ist EEE für 2.5G deaktiviert.

Anscheinend verfügt der RK3588 SoC über sehr viele Clock-Gates und Sub-Clock-Gates, die um Energie zu sparen dynamisch während des Betriebs ein- und ausgeschaltet werden müssen. Dies scheint noch nicht korrekt im Kernel implementiert zu sein. Laut dem Upstream Entwickler lassen sie so lange die Clock-Gates einfach dauerhaft eingeschaltet, was aber Energie verschwendet.

(ab 7:01:03)

Hier mal ein Idle-Messwert (an der Steckdose):

R6C8GB MMC32GB + SD32GB + LEXAR4TB (ARMBIAN 23.11 BOOKWORM EDGE,SDBOOT,NOASPML1,NOEEE,LAN2.5G) = 2,86W


Danach habe ich noch einige Windows-Samba Transfertests mit großen Dateien zwischen verschiedenen Windows 10 PCs und dem NanoPi R6C NAS (am 2.5G LAN Port) gemacht und bin dabei leider auf einen Bug im Realtek r8125 Linux Hersteller-Treiber für die Realtek RTL8125BG NIC gestoßen:

Das Lesen vom NAS ist in allen Konstellationen (verschiedene PCs und Switches) am Maximum der Ethernet-Verbindung (1G und 2.5G).

6eegEiw.png

cW5R4Qx.png


Beim Schreiben mit 1G gibt es die üblichen kleinen Kerben durch den Kernel Schreibcache auf dem NanoPi. Diese lassen sich durch einen kleineren Cache entfernen (1600MB vs 80MB).

jcRmVOY.png

5fUuLFQ.png


Wenn man aber von einem Windows 10 PC mit Realtek RTL8125BG 2.5G Netzwerkkarte mit 2.5G Verbindung auf den NanoPi (mit allen Energiesparmodi an) schreibt, bekommt man lediglich ~16MB/sec. Also viel langsamer als die 1G Verbindung mit gleichen Einstellungen! Iperf3 zeigt eine Bandbreite von nur 92.2Mbit/sec an.

Ilsqu5e.png


Wenn man am NanoPi eine der beiden Energiesparmodi (ASPM L1 oder EEE) ausschaltet, oder einen Switch ohne EEE Unterstützung dazwischen hat, kommt man in der Kombination wenigstens auf stark schwankende ~170MB/s. Besser... aber immer noch weit entfernt vom ~280MB/s Optimum. Laut iperf3 ist die Bandbreite 1.71Gbit/sec.

4v6s6Xg.png


Beide Energiesparmodi (ASPM L1 und EEE) zu deaktivieren führt zu einem ähnlichen Ergebnis.

J2CiYtS.png


Eigentlich sollte der Treiber verhindern, dass die NIC während eines Transfers in Energiesparmodi wechselt. Und diese extreme Schwäche der RX Seite ist definitiv nicht normal. Mir ist auch nicht klar wieso es ausgerechnet von Realtek RTL8125BG (Windows) zu Realtek RTL8125BG (Linux) so schlimm ist.

Der aktuelle Windows Treiber für den Realtek RTL8125BG hat diese Probleme nicht.

Als Alternative gibt es nur noch den Realtek r8169 Kernel-Treiber, aber im 5.10.y Legacy Vendor-Kernel ist nur eine sehr alte Version davon. Wahrscheinlich muss man hier auf einen Mainline Kernel mit besserer RK3588 Unterstützung warten, der auch einen aktuellen Realtek r8169 Treiber mitbringt.
 
Mittlerweile gibt es Armbian Bookworm mit 6.7 Edge Kernel für den NanoPi R6 und Openmediavault 7 Beta. Ich habe das auf einem meiner NanoPi getestet.

Leider alles noch sehr Experimentell selbst für ein Headless NAS. Für einen produktiven Einsatz definitiv nicht zu empfehlen.

Was den Idle-Verbrauch angeht deutlich schlechter wie der 5.10.y Legacy Vendor-Kernel. ASPM L1 funktioniert nur teilweise und im Realtek 8169 Kernel Treiber ist EEE für 2.5G deaktiviert.

Mega Thread, auch wenn ich jetzt ärmer bin !!!
Gerät soll morgen ankommen, und ich möchte auch richtung OMV gehen. Was wäre denn da jetzt die empfehlung, Armbian_23.8.1_Nanopi-r6s_bookworm_legacy_5.10.160_minimal.img wenn ich richtig verstanden habe ?
 
Leider sind die Images auf der Armbian Download Seite nicht Ideal im Moment. Edge Kernel ist zu Experimentell und für Debian Bookworm gibt es nur OMV 7 Beta.

Am besten über https://github.com/armbian/build ein Custom Image erzeugen: Armbian 23.11.x NanoPi R6S Bullseye Legacy 5.10.y Minimal.

Das kann man dann später auf Debian Bookworm mit OMV 7 upgraden, wenn OMV 7 als Stable released wird.
 
So. der r6c ist da, die nvme leider noch nicht.
image erzeugt, auf ne microsd gebügelt.
gebootet
basic config, apt update & apt upgrade,
kein monitor, keine tastatur angeschlossen.
leider dümpelt der bei 1,9-2 Watt. hab das rasperry netzteil. gemessen mit nem shellyplug und nem elv energymaster expert.
auch wenn ich das ethernet trenne, komm ich nicht unter 1,7W

was hab ich vergessen/falsch gemacht ?

Code:
root@nanopi-r6s:~# dmesg | grep powersave

[    3.946034] Kernel command line: root=UUID=1252c811-2b65-43cc-8a01-fd2c04c18515 rootwait rootfstype=ext4 splash=verbose console=ttyFIQ0 console=tty1 consoleblank=0 loglevel=1 ubootpart=208c8310-a280-1e4c-b890-e2e3b16555c5 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u pcie_aspm.policy=powersave  cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 earlycon=uart8250,mmio32,0xfeb50000 coherent_pool=1m irqchip.gicv3_pseudo_nmi=0

root@nanopi-r6s:~# ethtool --show-eee enP3p49s0

EEE settings for enP3p49s0:

      EEE status: enabled - inactive

      Tx LPI: 0 (us)

      Supported EEE link modes:  100baseT/Full

                                1000baseT/Full

                                2500baseX/Full

      Advertised EEE link modes:  100baseT/Full

                                  1000baseT/Full

                                  2500baseX/Full

      Link partner advertised EEE link modes:  Not reported

root@nanopi-r6s:~# uname -a

Linux nanopi-r6s 5.10.160-legacy-rk35xx #1 SMP Tue Nov 28 02:45:16 UTC 2023 aarch64 GNU/Linux

root@nanopi-r6s:~#
 
Welches Raspberry Netzteil genau verwendest du? Produktcode? Kann das mehr als 5,1V?
 
Mit anderen Netzteilen (anker nano pro, apple macbook, ...) gleiches spiel.
ich hab jetzt mal hxxps://armbian.lv.auroradev.org/archive/nanopi-r6s/archive/Armbian_23.2.7_Nanopi-r6s_bullseye_legacy_5.10.110_minimal.img.xz ausprobiert, und siehe da, ich komm auf 0.9/1W
Wo bin ich falsch abgebogen ? gab es eine besonderheit beim custom-build ?
 
Mit anderen Netzteilen (anker nano pro, apple macbook, ...) gleiches spiel.

Mit diesen Netzteilen ist es nicht möglich auf <1W zu kommen. Zu ineffizient im Idle-Lastbereich des NanoPi. Und wenn das Netzteil USB PD kann, dann schaltet der NanoPi von 5V auf eine höhere Eingangsspannung um, was ineffizienter ist als purer 5V Betrieb.

ich hab jetzt mal hxxps://armbian.lv.auroradev.org/archive/nanopi-r6s/archive/Armbian_23.2.7_Nanopi-r6s_bullseye_legacy_5.10.110_minimal.img.xz ausprobiert, und siehe da, ich komm auf 0.9/1W

Dieses Image war eins der ersten Images mit Support für den NanoPi R6S. Da sind einige Bugs im Device Tree und im Kernel fehlen etliche Patches. Das würde ich nicht dauerhaft benutzen.

Wo bin ich falsch abgebogen ? gab es eine besonderheit beim custom-build ?

Eigentlich nicht. Höchstens Armbian hat in den aktuellsten Trunk-Builds einen neuen Bug eingebaut. Auf meinen NanoPi läuft Armbian 23.11.1 Bullseye Legacy Minimal ohne Probleme.

Hier nochmal die häufigsten Ursachen für einen erhöhten Idle-Verbrauch:

- Ineffizientes Netzteil und/oder Eingangsspannung >5V durch USB PD.
- USB3 OTG DT Bug im Image. Führt dazu, dass der USB3-Port nicht mehr funktioniert und der Idle-Verbrauch dauerhaft steigt. Wurde behoben mit Armbian 23.8.x.
- 2.5G Netzwerkadapter nicht korrekt konfiguriert. Führt dazu dass er nicht in den Energiesparmodus wechselt.
- ASPM L1 nicht aktiv (lässt sich prüfen mit "lspci -vvv | grep LnkCtl:").
- EEE nicht aktiv (lässt sich prüfen mit "ethtool --show-eee enP3p49s0").
 
danke für die hilfe. ich steh aber noch immer auf dem schlauch
das 23.2.7 image hab ich nur zum testen genommen, damit komm ich ja in den bereich 1W. Feintuning (richtiges netzteil) kann ich ja machen wenn ich von den 2W runter komme.
nochmal von scratch angefangen :
Bash:
git clone --branch=v23.11 https://github.com/armbian/build
./compile.sh build BOARD=nanopi-r6s BRANCH=legacy BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bullseye
dd if=Armbian-unofficial_23.11.0-trunk_Nanopi-r6s_bullseye_legacy_5.10.160_minimal.img of=/dev/sdb bs=1M
mount /dev/sdb1 /tmp/sdb1
sed -i 's/r6s/r6c/g' /tmp/sdb1/armbianEnv.txt
sed -i '1s/^/extraargs=pcie_aspm.policy=powersave\n/' /tmp/sdb1/armbianEnv.txt
umount /dev/sdb1
-> was mir auffällt, du schreibst von 23.11.1 , bei mir steht 23.11.0-trunk

karte in den nanopi, booten, warten.

Code:
ssh 10.0.0.58
root/1234
script durcharbeiten
und dann das "tuning"
Bash:
root@nanopi-r6s:~# ethtool --set-eee enP3p49s0 eee on
root@nanopi-r6s:~# ethtool --show-eee enP3p49s0
EEE settings for enP3p49s0:
    EEE status: enabled - active
    Tx LPI: 0 (us)
    Supported EEE link modes:  100baseT/Full
                               1000baseT/Full
                               2500baseX/Full
    Advertised EEE link modes:  100baseT/Full
                                1000baseT/Full
                                2500baseX/Full
    Link partner advertised EEE link modes:  100baseT/Full
                                             1000baseT/Full
root@nanopi-r6s:~# cat /sys/module/pcie_aspm/parameters/policy
default performance [powersave] powersupersave
root@nanopi-r6s:~#lspci -vvv | grep LnkCtl
Command 'lspci' not found, but can be installed with:
apt install pciutils
root@nanopi-r6s:~# apt install pciutils
root@nanopi-r6s:~# lspci -vvv | grep LnkCtl
        LnkCtl:    ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
        LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
        LnkCtl3: LnkEquIntrruptEn- PerformEqu-
pcilib: sysfs_read_vpd: read failed: Input/output error
        LnkCtl:    ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
        LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-

sieht für mich ok aus ?
es bleibt aber bei 1.9W
ich seh den fehler nicht.
 
Spannend. Aus "Verzweiflung" hab ich das gleiche Image mal ins emmc geschrieben.
Damit komm ich jetzt auf 1W.
 
Spannend. Aus "Verzweiflung" hab ich das gleiche Image mal ins emmc geschrieben.
Damit komm ich jetzt auf 1W.

Sehr merkwürdig. Ich bezweifle aber, dass der microSD Controller für den Unterschied verantwortlich ist. Da das Booten von eMMC wesentlich schneller ist hat es evtl. eine Auswirkung auf die Netzwerkkonfiguration.

Wenn du das Ugreen Netzteil benutzen würdest, könnte man mit meinen Messwerten leichter eingrenzen welche Komponente für den Mehrverbrauch im Idle verantwortlich ist. Oder hast du evtl. ein USB Messgerät, um nach dem Netzteil messen zu können?

Was du noch überprüfen könntest wäre der Takt des SoC mit "cpufreq-info". Und ob der korrekte Governor eingestellt ist (schedutil).

Die Netzwerkkonfiguration mit "nmcli" (Stock Armbian) bzw. "networkctl" (nach Installation von OMV mit dem Install Script).

-> was mir auffällt, du schreibst von 23.11.1 , bei mir steht 23.11.0-trunk

Das liegt daran, dass ich ein 23.08.0-trunk Image installiert hatte, dass per apt auf 23.11.1 (stable) geupdatet wurde.
 
Danke für die vielen Tips.
Ich habe den Übeltäter gefunden. Die microsd.
Keine Schreibfehler oder andere Auffälligkeiten, aber es ist genau diese eine Karte die das erzeugt. Die hat schon ein Jahr (im Betrieb) auf dem Buckel, eine andere, jüngere gleichen Typs (SD high endurance) zeigt das Verhalten nicht.

Edit: wenn jetzt endlich Mal das paket mit der nvm und dem Netzteil kommt, kann ich mich ans Finetuning machen.
 
"gefühlt" liegen die werte ein wenig zu hoch, der elv energy master zeigt weniger an. aber zum vergleich denke ich brauchbar.

netzteile.png
 
Deine Messwerte sehen plausibel aus. 5V Netzteile am Besten, dann die USB-C PD Netzteile mit höheren Spannungen.

Für <1W brauchst du das Ugreen CD122 18W.
 
Ich muss mich jetzt erstmal um die switching seite kümmern, da pusste ich zuviel in die luft.
2.5g+eee+vlans+jumboframes........da sieht es noch mau aus
 
Sehr schöner Beitrag! Interessant was da geht, und als BackUp NAS sehr spannend.
 
Eine PoE Variante wäre mal was, wenn man eh nen Switch mit PoE hat... wäre das wirklich prima ohne auf externe Netzteile noch extra setzen zu müssen. Und dann doch so ein 5 GbE oder 10 Gbe SFP+ Port, auch wenn es dann bei 2-3W liegen würde, wäre wirklich perfekt.
 
Heute den MokerLink 2G08110GS probiert, der wird bei servethehome mit 1.6W idle/0.7w pro port beschrieben.
Meiner braucht 2.4W idle, 0.7w pro port.
Kein EEE, deswegen geht er zurück.
Schade, der wäre schön preiswert gewesen.
 
@ct100 Erstmal vielen Dank für deine Mühe - sehr nützliche Infos, auch für andere Systeme.

Ich weiß nicht, ob du nen github account hast, aber für das hier:

Code:
git clone --branch=v23.11 https://github.com/armbian/build

./compile.sh build BOARD=nanopi-r6s BRANCH=legacy BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bullseye

könnte man einfach mal ein github-Repository mit einer Github-Action erstellen, wo das ganze als <release>.img als Download angeboten wird. Es wäre sogar möglich, das image vor dem Release zu mounten und die Änderungen der Einstellungen fürs Stromsparen direkt einzuspielen, so das man das nicht mehr manuell durchackern muss.

DEIN Fachwissen muss man erstmal haben und für viele wäre es bestimmt einfacher, ein fertiges Image von gh runterzuladen und draufzuspielen.

Ich habe leider kein solches Gerät, aber falls Interesse besteht, könnte ich zumindest was GH-Actions betrifft helfen...

Ich frage mich ob es ein effizienteres Netzteil als das Ugreen 18W gibt. Vielleicht hat jemand einen Tipp?
Ich finde die Tests von AllThingsOnePlace auf Youtube immer sehr aufschlussreich und genau. Ist zwar auch ein "ich verdien Geld mit Affiliates" Channel, aber die Ergebnisse wirken sauber.

Hier sind die Empfehlungen von 5W - 300W für 2023:

Auch ein UGreen 20W ganz oben, ich weiß nicht ob es deins ist, aber ich glaube du bist schon sehr nah am Optimum.
 
DEIN Fachwissen muss man erstmal haben und für viele wäre es bestimmt einfacher, ein fertiges Image von gh runterzuladen und draufzuspielen.

Ich habe leider kein solches Gerät, aber falls Intere

Als ich mit diesem Thread angefangen habe, gab es auf der Armbian Download Seite für den NanoPi R6 (https://www.armbian.com/nanopi-r6s/) noch jede Menge Bullseye Images und ein extra Image-Archiv.

Leider hat Armbian dann immer mehr Images entfernt und mittlerweile ist die Seite von Images mit Edge Kernel dominiert, die aber noch nicht produktiv einsetzbar sind.

Jetzt lohnt es sich nicht mehr noch ein Bullseye Image zu erzeugen, da OpenMediaVault kurz vor dem 7.0 Release steht (https://www.openmediavault.org/?page_id=1271) und damit kann man dann das normale Bookworm CLI 5.10 Legacy Image von Armbian nehmen.

Ich finde die Tests von AllThingsOnePlace auf Youtube immer sehr aufschlussreich und genau. Ist zwar auch ein "ich verdien Geld mit Affiliates" Channel, aber die Ergebnisse wirken sauber.

Habe mir am Anfang sehr viele Videos von Ihm angeschaut. Aber als ich realisiert habe, dass der NanoPi (und wahrscheinlich auch die anderen RK3588s SBCs) im reinen 5V Betrieb die niedrigsten Idle-Verbräuche hat, waren seine Tests der ganzen USB-C PD Netzteile nicht mehr besonders hilfreich.

Wenn es ein Netzteil gibt, dass das Ugreen CD122 18W im Idle schlagen kann, dann ist es wahrscheinlich ein sehr simples USB-A oder DC-Netzteil.
 
Jetzt lohnt es sich nicht mehr noch ein Bullseye Image zu erzeugen, da OpenMediaVault kurz vor dem 7.0 Release steht
Ja, das stimmt vermutlich. Ich dachte nur an eine automatisierte Integration deiner Anpassungen per Loop-Device. So hätte man immer das neueste / beste Image als "fix und fertig" Download. Ich lese hier ohnehin nur so mit und freue mich über den Thread. Ich konnte da für meinen x64 Homeserver ne Menge Optimierungsinfos mitnehmen, aber ich kann das Gerät leider nicht als "Hauptserver" einsetzen. Ich hatte drüber nachgedacht, das ganze als Reiserouter/NAS mit OpenWRT zu betreiben. Aber das ist erstmal zurück gestellt, Urlaub mach ich so schnell keinen und da tuts auch ne USB-Festplatte.
 
@ct100 ich möchte an dieser Stelle auch nochmal Danke sagen.
Da ich was flottes aber sparsames fürs Homeoffice haben wollte und mal was anderes als das klassische intel/AMD Zeugs, habe ich die letzten Wochen viel im Web recherchiert und bin letzten Endes aufgrund deiner Tests hier auf den RK3588 aufmerksam geworden.
Es sah vielversprechend aus und daher orderte ich dann den Orangepi 5 plus 8GB mit dem RK3588 (ohne s) inkl. Gehäuse, Lüfter und Netzteil.

Der Einsatzzweck ist zwar nicht der NAS Betrieb, aber... eventuell ist es ja trotzdem interessant.
Die zwei 2,5GB NICs sind praktisch, eine ins Heimnetz an die andere kann ich auch mal Arbeit anschließen die ich mit nach Hause nehme.
Zweimal HDMI nehme ich ebenfalls für beide Monitore gerne mit.
Und wenn man den Lüfter nicht an 5V anschließt, sondern an die 3.3V Pfosten, ist er sogar leise :d

Ich habe den ganzen Schrank voller Odroids und alter Raspberries, die hatten mir aber alle für den Alltag nicht genug Leistung.
Der hier ist nun wirklich einer der Kandidaten wo ich sagen muss: Ich vermisse bisher nichts und das obwohl noch alles von der SD Karte läuft.
Mal schauen welche NVMe ich hier verbauen werde.
 
@Zyxx Ich hätte an deiner Stelle eher den NanoPC T6 genommen, weil man dort für praktisch den gleichen Preis ein massives Metallgehäuse inkl. Passivkühlung bekommt.

Diese Mini-Lüfter produzieren nicht nur Lärm, sondern verbrauchen auch locker 0,3-0,9w (je nach Modell und Drehzahl) was beim geringen Idle-Verbrauch des RK3588 eine Menge ist.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh