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

[ct100]

@fse1 Ich habe heute mal die Sekundärseite mit einem meiner USB Messgeräte, dem ich am ehesten vertraue, nachgemessen (A3 USB Tester). Die Ergebnisse sind oben im 1. Post als Diagramm und in Textform darunter.

Das Ugreen 18W Netzteil ist echt beeindruckend. Ein wenig über 1W hat es einen Wirkungsgrad von >90%.

Bei den microSD-Karten ist absolut kein Unterschied zwischen 32GB und 128GB messbar.

Das 8GB Modell des NanoPi R6C verbraucht in der Tat etwas mehr als das 4GB Modell im Idle. ~0,02W / 0,025W

Leider habe ich die Lexar NM790 2TB nicht mehr, um den Unterschied zwischen dem 2TB und dem 4TB Modell zu messen, ist aber wahrscheinlich <0,035W.

Die Lexar NM790 4TB verbraucht auch ohne PCIe ASPM L1 weniger im Idle als die SK Hynix Gold P31 2TB. Die Gold P31 ist definitiv nicht mehr die sparsamste SSD für Low Power Systeme oder Laptops.

 

[JackF87]

So, habe jetzt auch mein NanoPi R6C 4GB mit Gehäuse.

- Samsung PRO Endurance 128 SD
- Lexar NM790 4TB M.2 NVME SSD
- Ugreen CD122 70273 18W.

- Armbian_23.2.7_Nanopi-r6s_bullseye_legacy_5.10.110_minimal
- OpenMediaVault 6.6.0 + miniDNLA

Mein ELV Energy Master zeigt im Idle 1,0 Watt an.

Leserate unter Win11 vom SMB konstant 113 MB/s.
Allerdings die Schreibgeschwindigkeit schwankt stark zwischen 60 - 90 MB/s.

 

[ct100]

Armbian_23.2.7_Nanopi-r6s_bullseye_legacy_5.10.110_minimal

Bitte bei diesem Image beachten, dass es alt ist und zwischenzeitlich viel geändert wurde in Armbian.

Wenn man dieses Image auf Kernel 23.05.x updated mit apt bekommt man den USB3 OTG Bug (https://github.com/armbian/linux-rockchip/commit/e38dbd29767d8c3300c95c5362d17898c65ff1a3), der den USB3-Port funktionsunfähig macht und gleichzeitig den Idle Verbrauch um 0,3w erhöht. Dieser Bug ist erst in Kernel 23.08.0-trunk gefixed.

Man kann von diesem Image nicht automatisch auf 23.08.0 upgraden weil in Armbian die Kernel von verschiedenen Boards zusammengeführt worden sind: https://forum.armbian.com/topic/29087-migration-to-rk35xx-linuxfamily/ (Achtung diese Anleitung ist nur für den nightly Branch. Wenn man auf dem stable Branch ist am besten warten bis 23.08.0 offiziell released wurde)

Mit "apt list linux* --installed" kann man sehen welche Versionen von U-Boot/DTB/Kernel aktuell auf dem System installiert sind (Beispiel für ein per Build Framework erzeugtes 23.08.0-trunk Image):

linux-dtb-legacy-rk35xx/now 23.08.0-trunk--5.10.160-S8cae-D6ba1-P0000-C57caHfe66-HK01ba-Vc222-B18f9 arm64 [installed,local]
linux-image-legacy-rk35xx/now 23.08.0-trunk--5.10.160-S8cae-D6ba1-P0000-C57caHfe66-HK01ba-Vc222-B18f9 arm64 [installed,local]
linux-u-boot-nanopi-r6s-legacy/now 23.08.0-trunk--2017.09-Sddc9-P7af9-He8c0-Vc92c-Bb358 arm64 [installed,local]

Wenn man ein aktuelles 23.08.0-trunk Image haben will geht das derzeit nur mit dem Build-Framework (https://github.com/armbian/build). Die Images auf der Armbian Download Seite (https://www.armbian.com/nanopi-r6s) sind leider alle von April/Mai.

Leserate unter Win11 vom SMB konstant 113 MB/s.
Allerdings die Schreibgeschwindigkeit schwankt stark zwischen 60 - 90 MB/s.

Das liegt an der Kombination aus SoC und Realtek RTL8211F Transceiver am 1G WAN-Port. Da scheint es einen Software-Bug zu geben, der sich auf die Schreibgeschwindigkeit auswirkt, je nachdem welche NIC am anderen Ende ist. Ich hoffe das wird noch in Armbian gefixed.

Mit dem 2.5G LAN-Port solltest du die volle Geschwindigkeit beim Lesen und Schreiben haben (für ca. +0,3W idle im 1G-Modus).

 

[JackF87]

Mit dem 2.5G LAN-Port solltest du die volle Geschwindigkeit beim Lesen und Schreiben haben (für ca. +0,3W idle im 1G-Modus).

Nicht wirklich, Schreibgeschwindigkeit ist etwas konstanter mit dem 2.5G Port, aber nicht nennenswert schneller.
Werde demnächst die 23.08.0-trunk testen.

 

[ct100]

Update: Sonstige Hinweise ergänzt. Mehr Details zum Mehrverbrauch bei Verwendung des 2.5G LAN-Ports. Neuer Stromverbrauchswert für das NanoPi R6C 8GB Modell mit eMMC Boot und 2.5G LAN-Port.

@JackF87 Kannst du mal einen Screenshot machen während des Schreibens auf das NAS? Sieht es so aus wie die 2. oder 3. Grafik auf diesem Bild?

Wenn du beim Schreiben nicht mal zeitweise auf 11xMB/s kommst kann das auch an deinem SMB-Client liegen.

 

[JackF87]

Habe jetzt 23.08.0-trunk mit OMV 6.7.1-1 und folgenden Einstellungen.

Use sendfile
Asynchronous I/O

write cache size = 2097152
min receivefile size = 16384
getwd cache = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
read raw = yes
write raw = yes

 

[ct100]

write cache size = 2097152
min receivefile size = 16384
getwd cache = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
read raw = yes
write raw = yes

Diese Extra Samba Optionen kannst du alle löschen. Wieso?

write cache size -> kein Effekt, Größe des Write Cache wird vom Linux Kernel bestimmt
min receivefile size -> kein Effekt, funktioniert nur für nicht signierte Verbindungen
getwd cache -> kein Effekt, bereits Standard in Samba
socket options -> Nodelay bereits Standard, Rest macht das System automatisch
read/write raw -> Kein Effekt, da Samba die Caches des Linux Kernel benutzt


Die Performance des 1G WAN-Ports kannst du erhöhen wenn du EEE mit "ethtool --set-eee eth0 eee off" deaktivierst. Das würde ich aber nicht empfehlen, da ist es besser gleich den 2.5G LAN-Port zu benutzen.

Die Performance des 2.5G LAN-Ports sieht gut aus. Die zwei Kerben kommen vom Write Cache des Linux Kernels. Samba schreibt am Anfang nichts auf die SSD sondern alles in den Write Cache des Linux Kernels bis der voll ist. Dann wird der Cache in einem Rutsch auf die SSD geschrieben -> Kerbe in der Grafik.

Du kannst die Kerben entfernen, indem du den Kernel Write Cache mit "echo 1 > /proc/sys/vm/dirty_ratio" oder einer festen Einstellung unter "/etc/sysctl.d/" auf ein Minimum reduzierst, aber im Alltag ist es besser einen großen Write Cache zu haben (Standard ist 20% vom RAM).

Wenn du einen niedrigen Idle Stromverbrauch auch mit dem 2.5G LAN-Port haben willst musst du dafür EEE aktivieren (siehe 1. Post in diesem Thread).

 

[JackF87]

Danke, mit dem 2.5G LAN-Port und "ethtool --set-eee enP3p49s0 eee on" ist das NAS jetzt perfekt für mich.

 

[ct100]

@JackF87 Daran denken, dass der Befehl bei jedem Systemstart neu ausgeführt werden muss.

Ich verwende dazu einen Systemd Service:

nano /etc/systemd/system/enable-eee.service

[Unit]
Description=Enable Energy Efficient Ethernet
Requires=network.target
After=network.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/sbin/ethtool --set-eee enP3p49s0 eee on

[Install]
WantedBy=multi-user.target

systemctl enable enable-eee.service

Dann Neustarten und überprüfen ob der Befehl korrekt ausgeführt wurde:

systemctl status enable-eee.service

 

[ct100]

Update: Armbian 23.08.1 wurde auf dem Stable Branch veröffentlicht. Ältere Armbian Bullseye Images lassen sich per apt oder im OpenMediaVault Webinterface auf die neuste Version upgraden.

Ich habe mehrere Bugs an OpenMediaVault gemeldet und diese wurden alle mit Version 6.8.0 behoben.

Das OMVExtras InstallScript (https://github.com/OpenMediaVault-Plugin-Developers/installScript) wurde ebenfalls mit Version 2.0.0 gefixed.


Damit sollte jetzt mit Armbian 23.08.1, InstallScript 2.0.0 und OpenMediaVault 6.8.0 alles ohne weitere Anpassungen funktionieren.


Lediglich das Energy Efficient Ethernet für den 2.5G LAN-Port muss man noch von Hand aktivieren. Der von Armbian in den Custom Kernel kopierte R8125 Treiber hat leider als default Einstellung "ENABLE_EEE = n".

linux-rockchip/drivers/net/ethernet/realtek/r8125 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

 

[-->Andy<--]

Wo bestellt ihr den den NanoPI? Die Lieferzeiten auf der Homepage sind leider sehr lang.

 

[ct100]

Wo bestellt ihr den den NanoPI? Die Lieferzeiten auf der Homepage sind leider sehr lang.

Amazon Marketplace. Darauf achten, dass der Versand über Amazon selbst geht und der NanoPi auf Lager ist, dann bekommt man ihn innerhalb von 1-2 Tagen.

 

[nitzpipp]

ich bin begeistert. genau das, wonach ich gesucht habe. 1 frage würde ich gern loswerden:

- warum verwendest du sd oder mmc-speicher? würde es noch sparen, direkt von der ssd zu booten, oder führt dies zu geringeren schreib/leseraten fürs nas selbst?

 

[Trambahner]

Weil man ein Betriebssystem für ein NAS oder auch einen Virtualisierungsserver nicht auf das Medium schreibt (und davon bootet), wo auch die Nutzdaten liegen.
Grund: einfachere und schnellere Wartung und Störungsbeseitigung, wenn das unabhängig voneinander abelegt wird.

 

[nitzpipp]

ok, klaro, aber wenn das system stattdessen auf einer sd-karte liegt, bin ich etwas zwiegespalten, was besser ist...ich könnte mir jetzt nur vorstellen, dass das häufigere aufwachen der ssd den idle-verbrauch etwas ruiniert?

 

[ct100]

- warum verwendest du sd oder mmc-speicher? würde es noch sparen, direkt von der ssd zu booten, oder führt dies zu geringeren schreib/leseraten fürs nas selbst?

Der SD und eMMC Speicher ist extrem sparsam im Idle, da lässt sich kaum etwas einsparen.

Auf der anderen Seite würde das Betriebssystem auf der M.2 SSD dazu führen, dass diese häufiger aus dem tiefsten Energiesparmodus aufgeweckt wird und somit mehr Energie verbraucht.

Von den Lese-/Schreibraten her gibt es keinen Unterschied. Nur die Bootgeschwindigkeit des Systems unterscheidet sich deutlich zwischen SD, eMMC und M.2 SSD. Bei 24/7 Betrieb aber nicht wirklich relevant.

 

[nitzpipp]

Der SD und eMMC Speicher ist extrem sparsam im Idle, da lässt sich kaum etwas einsparen.

Auf der anderen Seite würde das Betriebssystem auf der M.2 SSD dazu führen, dass diese häufiger aus dem tiefsten Energiesparmodus aufgeweckt wird und somit mehr Energie verbraucht.

Von den Lese-/Schreibraten her gibt es keinen Unterschied. Nur die Bootgeschwindigkeit des Systems unterscheidet sich deutlich zwischen SD, eMMC und M.2 SSD. Bei 24/7 Betrieb aber nicht wirklich relevant.

ich tippe aber mal, die sd, wenn es eine gute ist, dürfte besser liegen als der emmc, oder?

 

[ct100]

ich könnte mir jetzt nur vorstellen, dass das häufigere aufwachen der ssd den idle-verbrauch etwas ruiniert?

Also ruinieren würde ich nicht sagen, da der Linux Kernel dank Schreibcaches nicht alle paar Sekunden auf die SSD zugreifen muss.

Aber wenn die SSD aufgeweckt wird muss sie über 3s warten, bis sie wieder in den tiefsten Energiesparmodus zurückwechseln kann. Und in dieser Zeit verbraucht sie deutlich mehr Energie.

Hier mal die APST Idle Time Tabelle für die Lexar NM790 4TB:

> nvme get-feature /dev/nvme0n1 -f 0x0c -H
get-feature:0xc (Autonomous Power State Transition), Current value:0x000001
        Autonomous Power State Transition Enable (APSTE): Enabled
        Auto PST Entries        .................
        Entry[ 0]
        .................
        Idle Time Prior to Transition (ITPT): 750 ms
        Idle Transition Power State   (ITPS): 3
        .................
        Entry[ 1]
        .................
        Idle Time Prior to Transition (ITPT): 750 ms
        Idle Transition Power State   (ITPS): 3
        .................
        Entry[ 2]
        .................
        Idle Time Prior to Transition (ITPT): 750 ms
        Idle Transition Power State   (ITPS): 3
        .................
        Entry[ 3]
        .................
        Idle Time Prior to Transition (ITPT): 2450 ms
        Idle Transition Power State   (ITPS): 4
        .................
        Entry[ 4]
        .................
        Idle Time Prior to Transition (ITPT): 0 ms
        Idle Transition Power State   (ITPS): 0

ich tippe aber mal, die sd, wenn es eine gute ist, dürfte besser liegen als der emmc, oder?

Nein, die SD-Karte ist deutlich langsamer als der eMMC-Speicher. Ich habe das getestet und der Boot von eMMC war 9 Sekunden schneller (19s vs 28s).

 

[nitzpipp]

Nein, die SD-Karte ist deutlich langsamer als der eMMC-Speicher. Ich habe das getestet und der Boot von eMMC war 9 Sekunden schneller (19s vs 28s).

oh, das ist unerwartet. danke für die info!

 

[pwnbert]

Update: Sonstige Hinweise ergänzt. Mehr Details zum Mehrverbrauch bei Verwendung des 2.5G LAN-Ports. Neuer Stromverbrauchswert für das NanoPi R6C 8GB Modell mit eMMC Boot und 2.5G LAN-Port.

@JackF87 Kannst du mal einen Screenshot machen während des Schreibens auf das NAS? Sieht es so aus wie die 2. oder 3. Grafik auf diesem Bild?

Wenn du beim Schreiben nicht mal zeitweise auf 11xMB/s kommst kann das auch an deinem SMB-Client liegen.

Ist das 2.5G?
"Kann" der Client ausreichend?

Wäre neugierig, was das so schafft über SMB auf 2.5G.

 

[ct100]

Ist das 2.5G?
"Kann" der Client ausreichend?

Wäre neugierig, was das so schafft über SMB auf 2.5G.

Nein. Das ist 1G und die zwei unteren Grafiken zeigen einen Bug bei dem die Schreibrate auf das NAS in regelmäßigen Intervallen stark einbricht.

Im 1. Post dieses Threads siehst du die Transferraten von und auf das NAS über 2.5G SMB. Beim Lesen vom NAS wird die 2.5G-Verbindung fast komplett ausgereizt (270-280MB/s). Beim Schreiben auf das NAS gibt es leichte Einbrüche, die von der Größe des Linux Kernel Schreibcaches abhängen (240-280MB/s).

 

[pwnbert]

Ups das hab ich irgendwie übersehn, obwohl ich nochmal drüber geschaut hab... Sind das große Daten? Wie siehts bei Kleinmist aus?

 

[ct100]

Ups das hab ich irgendwie übersehn, obwohl ich nochmal drüber geschaut hab... Sind das große Daten? Wie siehts bei Kleinmist aus?

Ja das sind mehrere GB große Dateien.

Die Hardware ist in der Lage die 2.5G-Verbindung komplett auszureizen mit ~280MB/s. Das Problem beim Schreiben liegt an Samba.

Samba schreibt nicht direkt auf die SSD sondern füllt erst den Write Cache des Linux Kernels bis der voll ist. Dann wird der ganze Cache in einem Rutsch auf die SSD geschrieben und während dieses Schreibvorgangs sinkt die Transferrate der SMB-Verbindung etwas ab.

Bei einzelnen Dateien, die kleiner sind als die Größe des Write Caches (~20% des System RAM) ist die Übertragungsrate immer in der Nähe des Maximums.

Wenn du mit Kleinmist das Kopieren von 1000enden kleinen Dateien meinst... dabei dominiert der Overhead des SMB-Protokolls. Es ist unmöglich damit die Verbindung auszureizen.

 

[nitzpipp]

Update: Armbian 23.08.1 wurde auf dem Stable Branch veröffentlicht. Ältere Armbian Bullseye Images lassen sich per apt oder im OpenMediaVault Webinterface auf die neuste Version upgraden.

Ich habe mehrere Bugs an OpenMediaVault gemeldet und diese wurden alle mit Version 6.8.0 behoben.

Das OMVExtras InstallScript (https://github.com/OpenMediaVault-Plugin-Developers/installScript) wurde ebenfalls mit Version 2.0.0 gefixed.


Damit sollte jetzt mit Armbian 23.08.1, InstallScript 2.0.0 und OpenMediaVault 6.8.0 alles ohne weitere Anpassungen funktionieren.

ich versuche mich gerade an dem sript, leider gibts folgende meldung:

[2023-10-27 10:30:46+0200] [omvinstall] Unsupported version. Only Debian 10 (Buster) and 11 (Bullseye) are supported. Exiting...

installiert ist Armbian_23.8.2_Nanopi-r6s_bookworm_legacy_5.10.160.img.xz

mache ich was falsch? für bullseye sehe ich nur version 23.5.01, eher die dann nehmen?

 

[ct100]

ich versuche mich gerade an dem sript, leider gibts folgende meldung:

[2023-10-27 10:30:46+0200] [omvinstall] Unsupported version. Only Debian 10 (Buster) and 11 (Bullseye) are supported. Exiting...

installiert ist Armbian_23.8.2_Nanopi-r6s_bookworm_legacy_5.10.160.img.xz

mache ich was falsch? für bullseye sehe ich nur version 23.5.01, eher die dann nehmen?

Leider gibt es OpenMediaVault für Debian Bookworm noch nicht.

Wenn du ein aktuelles Armbian Bullseye Image haben willst geht das nur mit dem Buildscript von Armbian (https://github.com/armbian/build). Wenn das Buildscript sich beschwert, dass es mit Root Rechten ausgeführt wird, einfach eine Taste drücken.

Du kannst auch das ältere 23.5.01 Bullseye Image installieren und updaten. Aber da die Linuxfamily geändert wurde musst du das hier beachten:

Migration to rk35xx LINUXFAMILY

Rk3588 boards now share the same linuxfamily as rk3568 and rk3566 boards. It means rockchip-rk3588 kernel won't get update longer. Here is some steps for migration: sudo sed -i 's/LINUXFAMILY=rockchip-rk3588/LINUXFAMILY=rk35xx/g' /etc/armbian-release sudo apt update sudo apt install linux-image-l...

forum.armbian.com

 

[nitzpipp]

ok. ich bin mir garnicht sicher, ob es unbedingt openmediavault sein muss. mir reicht auch ein samba-dienst und gut. ich versuch mich noch ein wenig an dietpi, bisher war der verbrauch dort aber ca 0,5w höher. Gibt es iwo einen guide, welche 'knöpfe' ich unter debian bedienen kann, um das system auf stromsparend zu trimmen?

 

[ct100]

ok. ich bin mir garnicht sicher, ob es unbedingt openmediavault sein muss. mir reicht auch ein samba-dienst und gut. ich versuch mich noch ein wenig an dietpi, bisher war der verbrauch dort aber ca 0,5w höher. Gibt es iwo einen guide, welche 'knöpfe' ich unter debian bedienen kann, um das system auf stromsparend zu trimmen?

Sofern das Image die Hardware komplett unterstützt reicht es aus per Kernel Parameter PCIe ASPM L1 zu aktivieren.

Wenn du die 2.5G LAN-Verbindung benutzt, prüfen ob EEE aktiv ist und es ggf. mit ethtool aktivieren.

PCIe ASPM Status anzeigen: lspci -vvv | grep LnkCtl:
PCIe ASPM Policy anzeigen: cat /sys/module/pcie_aspm/parameters/policy
PCIe ASPM Temporär aktivieren: echo powersave > /sys/module/pcie_aspm/parameters/policy

EEE Status anzeigen: ethtool --show-eee (Adaptername)
EEE aktivieren: ethtool --set-eee (Adaptername) eee on

 

[Centaurius]

Zunächst vielen Dank für das Teilen der vielen interessanten Informationen – ganz toller Thread!

Ich bin genau auf der Suche nach einen (sehr) stromsparenden NAS für die Familie (zentrale Ablage von Hörbüchern, Hörspielen, Filmen, Fotos etc.), d.h., es finden hauptsächlich lesende Zugriffe auf div. Medien statt (ein klassisches Datengrab mit Zurverfügungstellung via Samba). Dafür erscheint mir diese Projekt sehr gut geeignet.

Meine Fragen:
- Gibt es derartige Platinen / Systeme auch mit mehr als einem M.2- oder ggf. SATA-Slot [1]?
- Zum System: vermutlich wurde es bereits geschrieben, aber ich nehme an, das System kann headless betrieben werden, richtig?

Danke.

[1] Edit: Wurde schon in Post #11 kurz angeschnitten, aber vielleicht hat sich in der Zwischenzeit etwas neues ergeben.

 

[ct100]

Ich bin genau auf der Suche nach einen (sehr) stromsparenden NAS für die Familie (zentrale Ablage von Hörbüchern, Hörspielen, Filmen, Fotos etc.), d.h., es finden hauptsächlich lesende Zugriffe auf div. Medien statt (ein klassisches Datengrab mit Zurverfügungstellung via Samba). Dafür erscheint mir diese Projekt sehr gut geeignet.

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.

- Gibt es derartige Platinen / Systeme auch mit mehr als einem M.2- oder ggf. SATA-Slot [1]?

Mit dem RK3588 (ohne S) SoC ist es theoretisch möglich ein SBC mit 2.5G NIC und 4x M.2 zu bauen. Gibt es aber leider bis heute nicht zu kaufen.

Vielleicht entwickelt jemand mal eine Platine mit mehreren M.2 Slots für ein RK3588 CM-Modul. Aktuell finde ich soetwas aber ebenfalls nicht.

Mit SATA ist es nicht möglich einen so niedrigen Idle Stromverbrauch zu erreichen.

- Zum System: vermutlich wurde es bereits geschrieben, aber ich nehme an, das System kann headless betrieben werden, richtig?

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.

 

[Senator Wurstbein]

Mit dem RK3588 (ohne S) SoC ist es theoretisch möglich ein SBC mit 2.5G NIC und 4x M.2 zu bauen. Gibt es aber leider bis heute nicht zu kaufen.

Darauf warte ich aktuell auch. Platten spiegeln und dann haben wir ein echtes NAS in Minigröße mit Miniverbrauch.