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).
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).
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.
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.
Beide Energiesparmodi (ASPM L1 und EEE) zu deaktivieren führt zu einem ähnlichen Ergebnis.
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.