50 minutes ago, W0nderW0lf said:

Im Spindown zustand verbraucht der Server 20Watt!! Wenn ich die platten aber selber nicht runter fahre, dann tun die auch nichts und drehen weiter...

Dann ist da ein Fehler vorhanden. Unbenutzte Festplatten sollten (sofern in den Settings eingestellt) selbstständig in den Spindown gehen.

Hast Du es in den Settings eingeschaltet?

Sind benutze Shares auf den Festplatten?

Sehr erfreuliche Neuigkeiten. ☺️

10 hours ago, DataCollector said:

Dann ist da ein Fehler vorhanden. Unbenutzte Festplatten sollten (sofern in den Settings eingestellt) selbstständig in den Spindown gehen.

Hast Du es in den Settings eingeschaltet?

Sind benutze Shares auf den Festplatten?

Ich habe gar nicht gerafft das man den spindown delay auch über die disk settings steuern muss. Dachte das geschieht per default automatisch.
Ich habe es auf 15 Minuten gesetzt und siehe da, die Platten (bis auf NVME) fahren runter.

Jetzt bin ich im idle bei 17,5-18,9Watt!! (Dafür habe ich aber alle Container gestoppt)

Wenn bei mir plex + 2 weitere Container laufen, bekomme ich Disk 1 und die Parities (is ja logisch wenn eine disk noch läuft) nicht down.

Ich habe nochmal alle Container gestartet und versuche mich gerade stück für stück durch zu hangeln.

Ich werde heute auch mal versuchen die WD/Sandisk zu updaten falls möglich. Ich gucke auch ob ich noch ein BIOS update finde, wobei ich das erst vor 5 monaten gemacht habe... denke also nicht das ich damit noch was verbesser.

Meine shares sind nicht mehr exportiert. Ich weiß nicht ob die bloße existenz des shares auch Auswirkungen darauf hat.

Ich muss auch gucken, dass ich Tasks innerhalb der container auf eine feste Uhrzeit und nicht auf zufällige Zeiten setze.

Ich habe mal alle relevanten Container gestartet und gucke mal welche von denen einen spindown verhindern. Dauert nur leider immer 15 minuten bis sich evtl. was tut

19 minutes ago, W0nderW0lf said:

Wenn bei mir plex + 2 weitere Container laufen, bekomme ich Disk 1 und die Parities (is ja logisch wenn eine disk noch läuft) nicht down.

Dann musst Du schauen, was das für container sind und warum die die Platten aktiv halten.

Die Parity läuft übrigens nur, wenn auch was geschrieben wird - für das reine Lesen bleibt die aus. Also was wird von den Containern geschrieben außerhalb von appdata?

Ziel sollte ja eigentlich sein, dass sich das array möglichst dauerhaft schlafen legt. Klar für bestimmte Tasks wachen dann einzelne Platten auf, aber ansonsten sollte es schlafen.

Wenn die Platten im SpinUp sind, brauchen wir hier gar nicht nach Stromsparmöglichkeiten suchen, das beginnt erst im spindown 😉

Also ich habe mal nachgesehen. Die Container laufen und 5 von 6 Platten sind runtergefahren.
Warum da jetzt der eine nicht runter fährt ist mir ein rätsel. Dabei ist da keine offensichtliche aktivität zu erkennen.

Vllt ändert sich das auch in ein paar minuten wieder, aber alles im allem bin ich doch schon sehr zufrieden mit dem vorläufigen Ergebnis.

Ich hatte eigentlich vermutet die parities bleiben oben solange eine disk "aktiv" ist.

Kann ich hier über das Menü sehen welche Container da eventuell noch einen aktiven zugriff haben?

Ich habe vorhin mal eine Folge von einer Serie angefangen, die vermutlich da drauf liegt. Keine Ahnung ob es damit zusammenhängt, aber den Stream habe ich wieder beendet.

9 minutes ago, W0nderW0lf said:

Ich habe vorhin mal eine Folge von einer Serie angefangen, die vermutlich da drauf liegt. Keine Ahnung ob es damit zusammenhängt, aber den Stream habe ich wieder beendet.

geh mal davon aus, dass das zusammenhängt 🤣

Wenn Du auf eine Datei zugreifst, die auf der Platte liegt (das lässt sich ja prüfen, wo die Folge liegt), muss diese anlaufen, das sollte klar sein.

Die Parity muss wie gesagt beim Lesen nicht anlaufen (solange alle Platten intakt sind und nichts emuliert werden muss).

Wenn du den Zugriff (die Wiedergabe der Folge) stoppst, zählen die 15min bzw. der eingestellten Wert für Spindown eben runter......

20 hours ago, MPC561 said:

Mal eine ganz einfache Frage. Deine Festplatten sind aber schon so konfiguriert das sie in den Spindown gehen?

Bitte lese in Zukunft deine Posts besser. Das hätte allen hier viel Schreibarbeit erspart wenn Du am Anfang darauf geantwortet hättest...

3 minutes ago, MPC561 said:

Bitte lese in Zukunft deine Posts besser. Das hätte allen hier viel Schreibarbeit erspart wenn Du am Anfang darauf geantwortet hättest...

Ich gebe mir wirklich mühe, aber mein ADHS macht es mir leider gottes nicht einfach. Ich kann über 4x einen Post lesen und überlese trotzdem die hälfte. Ist keine Absicht.
In meinem Kopf war das problem vorhanden: "Ich mach einen manuellen spindown, aber kann die nicht wieder starten"

Tut mir Leid wenn ich dir/euch unnötig Zeit geraubt habe, aber es war wenigstens nicht ganz umsonst.

Ich würde mich auch mit einem café für jeden revanchieren.

Just now, W0nderW0lf said:

Ich würde mich auch mit einem café für jeden revanchieren.

Oh jaaaa einen Kaffeee! Hab seit 3 Tagen Magen/Darm und kann keinen Kaffee

Aber will...

Na ja ich hab ja nicht viel getippt. Aber der arme Data...

Wenn @DataCollector einen "Spenden-Coffee-Pot" hat, würde ich auch freiwillig einzahlen. :D

Das waren wirklich lange und aufwendige Beiträge.

Muss ein grosser Pot sein.

Lass mich mal rechnen was Du sparst. Ein Watt kostet 3 Euro im Jahr ca.

Du hast grob 20W gespart = 60 Euro. Ich rechne die Laufzeit eines solchen Servers gerne mit 5 Jahren. Das wären dann 300 Euro gespart.

Dann hat sich das optimieren wirklich gelohnt. Glaubt man meist gar nicht was man da sparen kann.

Eine letzte Sache noch...
Ich habe soeben eine neue HDD eingebaut und wollte sie dem Array hinzufügen. Allerdings bekomme ich das Array nicht gestartet.

Unraid scheint auch die Laufwerksbuchstaben geändert zu haben. Ich bin mir nun nicht sicher, ob das mit meinem ursprünglichen Problem zusammenhängt wo ich das Array nicht online bekommen habe, weil ASPM nicht 100% greift, oder weil Unraid den Laufwerksbuchstaben von 2 Platten vertauscht hat. Nun ist (f) mit (h) vertauscht.

Wisst ihr woran das liegen könnte?

edit:

kurzes Update, ich habe den Server neugestartet und konnte erst danach den Array starten.

Merkwürdig finde ich es schon, dass das nicht vorher geklappt hat.

Nov 24 12:38:44 NASty unassigned.devices: Mounting partition 'sdf1' at mountpoint '/mnt/disks/WW678MCL'...
Nov 24 12:38:44 NASty unassigned.devices: Mount cmd: /sbin/mount -t 'xfs' -o rw,relatime '/dev/sdf1' '/mnt/disks/WW678MCL'
Nov 24 12:38:44 NASty kernel: XFS (sdf1): Mounting V5 Filesystem 9709f907-18d2-4f43-a188-599cf0511824
Nov 24 12:38:44 NASty kernel: XFS (sdf1): Ending clean mount
Nov 24 12:38:45 NASty unassigned.devices: Successfully mounted '/dev/sdf1' on '/mnt/disks/WW678MCL'.
Nov 24 12:38:45 NASty unassigned.devices: Device '/dev/sdf1' is not set to be shared.
Nov 24 12:38:50 NASty kernel: md: unRAID driver removed
Nov 24 12:38:50 NASty emhttpd: shcmd (604): /sbin/modprobe md-mod super=/boot/config/super.dat
Nov 24 12:38:50 NASty kernel: md: unRAID driver 2.9.35 installed
Nov 24 12:38:51 NASty kernel: mdcmd (1): import 0 sdb 64 3907018532 0 ST4000VN008-2DR166_ZDHA5NBY
Nov 24 12:38:51 NASty kernel: md: import disk0: (sdb) ST4000VN008-2DR166_ZDHA5NBY size: 3907018532 
Nov 24 12:38:51 NASty kernel: mdcmd (2): import 29 sde 64 3907018532 0 ST4000VN006-3CW104_WW669DQT
Nov 24 12:38:51 NASty kernel: md: import disk29: (sde) ST4000VN006-3CW104_WW669DQT size: 3907018532 
Nov 24 12:38:51 NASty kernel: mdcmd (3): import 1 sdc 64 3907018532 0 ST4000VN008-2DR166_ZGY969VM
Nov 24 12:38:51 NASty kernel: md: import disk1: (sdc) ST4000VN008-2DR166_ZGY969VM size: 3907018532 
Nov 24 12:38:51 NASty kernel: mdcmd (4): import 2 sdg 64 3907018532 0 ST4000VN008-2DR166_ZGY9926E
Nov 24 12:38:51 NASty kernel: md: import disk2: (sdg) ST4000VN008-2DR166_ZGY9926E size: 3907018532 
Nov 24 12:38:51 NASty kernel: mdcmd (5): import 3 sdh 64 3907018532 0 ST4000VN008-2DR166_ZGY98XD1
Nov 24 12:38:51 NASty kernel: md: import disk3: (sdh) ST4000VN008-2DR166_ZGY98XD1 size: 3907018532 
Nov 24 12:38:51 NASty kernel: mdcmd (6): import 4 sdd 64 3907018532 0 ST4000VN006-3CW104_WW669FY9
Nov 24 12:38:51 NASty kernel: md: import disk4: (sdd) ST4000VN006-3CW104_WW669FY9 size: 3907018532 
Nov 24 12:38:51 NASty kernel: mdcmd (7): import 5 sdf 64 3907018532 0 ST4000VN006-3CW104_WW678MCL
Nov 24 12:38:51 NASty kernel: md: import disk5: (sdf) ST4000VN006-3CW104_WW678MCL size: 3907018532 
Nov 24 12:38:51 NASty kernel: md: disk5 new disk
Nov 24 12:38:51 NASty kernel: mdcmd (8): import 6
Nov 24 12:38:51 NASty kernel: mdcmd (9): import 7
Nov 24 12:38:51 NASty kernel: mdcmd (10): import 8
Nov 24 12:38:51 NASty kernel: mdcmd (11): import 9
Nov 24 12:38:51 NASty kernel: mdcmd (12): import 10
Nov 24 12:38:51 NASty kernel: mdcmd (13): import 11
Nov 24 12:38:51 NASty kernel: mdcmd (14): import 12
Nov 24 12:38:51 NASty kernel: mdcmd (15): import 13
Nov 24 12:38:51 NASty kernel: mdcmd (16): import 14
Nov 24 12:38:51 NASty kernel: mdcmd (17): import 15
Nov 24 12:38:51 NASty kernel: mdcmd (18): import 16
Nov 24 12:38:51 NASty kernel: mdcmd (19): import 17
Nov 24 12:38:51 NASty kernel: mdcmd (20): import 18
Nov 24 12:38:51 NASty kernel: mdcmd (21): import 19
Nov 24 12:38:51 NASty kernel: mdcmd (22): import 20
Nov 24 12:38:51 NASty kernel: mdcmd (23): import 21
Nov 24 12:38:51 NASty kernel: mdcmd (24): import 22
Nov 24 12:38:51 NASty kernel: mdcmd (25): import 23
Nov 24 12:38:51 NASty kernel: mdcmd (26): import 24
Nov 24 12:38:51 NASty kernel: mdcmd (27): import 25
Nov 24 12:38:51 NASty kernel: mdcmd (28): import 26
Nov 24 12:38:51 NASty kernel: mdcmd (29): import 27
Nov 24 12:38:51 NASty kernel: mdcmd (30): import 28
Nov 24 12:38:51 NASty emhttpd: import 30 pool device: (nvme0n1) SanDisk_Extreme_Pro_500GB_21186C800316
Nov 24 12:38:51 NASty emhttpd: /sbin/blkid /dev/sda1 2>&1
Nov 24 12:38:51 NASty emhttpd: /dev/sda1: LABEL_FATBOOT="UNRAID" LABEL="UNRAID" UUID="ABA1-EF6C" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="b0a43bfd-01"
Nov 24 12:38:51 NASty emhttpd: import 31 flash device: (sda)
Nov 24 12:38:51 NASty emhttpd: update_pool_cfg: 30 cache 0
Nov 24 12:38:51 NASty SysDriversBuild: Submitting SysDrivers Build
Nov 24 12:38:51 NASty sysDrivers: SysDrivers Build Starting
Nov 24 12:38:59 NASty emhttpd: cmdStart: already starting
Nov 24 12:39:08 NASty sysDrivers: SysDrivers Build Complete

Edited November 24, 2025Nov 24 by W0nderW0lf

3 hours ago, W0nderW0lf said:

Ich habe soeben eine neue HDD eingebaut und wollte sie dem Array hinzufügen. Allerdings bekomme ich das Array nicht gestartet.

Unraid scheint auch die Laufwerksbuchstaben geändert zu haben.

Die "Laufwerksbuchstaben" sind bei unraid vollkommen egal (solange es nicht um den USb Boot Stick geht).

Unraid erkennt die Datenträger anfang der Bezeichnung +Seriennummer wieder.

Solange diese unverändert sind, kann unraid das Array udn die Pools wieder zusmamentellen, als wäre nichts gewesen.

3 hours ago, W0nderW0lf said:

Ich bin mir nun nicht sicher, ob das mit meinem ursprünglichen Problem zusammenhängt wo ich das Array nicht online bekommen habe, weil ASPM nicht 100% greift, oder weil Unraid den Laufwerksbuchstaben von 2 Platten vertauscht hat. Nun ist (f) mit (h) vertauscht.

Wie gesagt, die "Buchstaben" sind egal.

3 hours ago, W0nderW0lf said:

edit:
kurzes Update, ich habe den Server neugestartet und konnte erst danach den Array starten.

Merkwürdig finde ich es schon, dass das nicht vorher geklappt hat.

Verstehe ich es so, Du hast vorher im Betrieb Hardware zugesteckt?

Das KANN gut gehen muss aber nicht. Bei Hardwareumbau besser ausschalten.

Auch erkennt nicht jede Hardware (Firmware) selbstständig wenn sich da etwas verändert hat.

28 minutes ago, DataCollector said:

Die "Laufwerksbuchstaben" sind bei unraid vollkommen egal (solange es nicht um den USb Boot Stick geht).

Unraid erkennt die Datenträger anfang der Bezeichnung +Seriennummer wieder.

Solange diese unverändert sind, kann unraid das Array udn die Pools wieder zusmamentellen, als wäre nichts gewesen.

Wie gesagt, die "Buchstaben" sind egal.

gut zu wissen!

28 minutes ago, DataCollector said:

Verstehe ich es so, Du hast vorher im Betrieb Hardware zugesteckt?

Das KANN gut gehen muss aber nicht. Bei Hardwareumbau besser ausschalten.

Auch erkennt nicht jede Hardware (Firmware) selbstständig wenn sich da etwas verändert hat.

Nein, der Server war ausgeschalten.
War neu hochgefahren. Hab vorher noch Audio Controller im Bios deaktiviert.

Im Prinzip war es ein normaler start. Array war hochgefahren. Neue Festplatte im unassigned devices formatiert (hätte ich glaub ich überspringen können und einfach an das array anhängen können.. jetzt braucht der 5h um einen disk clean durch laufen zu lassen) .. Jedenfalls nachdem ich händisch den Array gestoppt habe, um die Disk ans Array zu hängen, ist nichts passiert. Der Start Button hat nichts getan. Die Seite immer nur neu geladen und im Log immer die gleiche Meldung geworfen " emhttpd: cmdStart: already starting"
De facto hat das erst nach einem Systemneustart geklappt...

Was aber vermutlich auch zum Problem beigetragen hat. Ich hatte vorher nochmal mit powertop geguckt, ob mein "go" file für Powertop die neuen Regeln angewandt hat. Ich bin mir nicht sicher ob die tatsächlich greifen.

Einstellungen in meinem "go" file:

....
# -------------------------------------------------
# powertop tweaks
# -------------------------------------------------
# Enable SATA link power management
echo med_power_with_dipm | tee /sys/class/scsi_host/host0/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host1/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host2/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host3/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host4/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host5/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host6/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host7/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host8/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host9/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host10/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host11/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host12/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host13/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host14/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host15/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host16/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host17/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host18/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host19/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host20/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host21/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host22/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host23/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host24/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host25/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host26/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host27/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host28/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host29/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host30/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host31/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host32/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host33/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host34/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host35/link_power_management_policy
echo med_power_with_dipm | tee /sys/class/scsi_host/host36/link_power_management_policy
....

Wenn das System hochfährt, sehe ich folgende Meldungen:

Im Powertop sehe ich dann aber wieder:

Ich vermute wenn ich mit powertop --auto-tune drüber gehe, bekomme ich das array nicht mehr online nach einem stop..

Ist jetzt meine Vermutung.

13 hours ago, W0nderW0lf said:

Ich vermute wenn ich mit powertop --auto-tune drüber gehe, bekomme ich das array nicht mehr online nach einem stop..

Ist jetzt meine Vermutung.

manche hardware mag einfach auch nicht zu sparsam laufen ... wie bereits erwähnt wurde ...

On 11/23/2025 at 1:35 PM, DataCollector said:

Eines ist aber wichtig! Sparsam ist gut, aber jede Änderung kann die Stabilität und ggf. auch Funktion einzelner Funktionen beeinflussen.

Von alles läuft super, über langsamere Funktion (Lan), bis zu totalem Absturz ist alles möglich.

taste dich ran, wenn dann etwas nicht mehr will, Schritt retour.

Kurz meine Tips:

Die App AutoTweak erlaubt (zumindest bei mir) nahezu alles auf ASPM enabled und in tiefste Modi zu schicken.

Aber Warnung - alles in den tiefsten Stromspar Modi führt allermeist zu instabilität.

Ansonsten, die meisten Tips gabs ja schon. Minimal System, C States Bios. wenig Docker usw usw .

Ich bekomme mit nem i12300 und 5 SSD Platten, einigen Docker - 9-15W idle stabil laufend hin.

Viel Erfolg!

Hallo nochmal an alle,

ich bin leider nach wie vor am "fighten" mit meinem Server. Irgendwie kann ich mich nicht dazu überwinden dieses MB aufzugeben. Ich hatte mich mal in einem anderen Forum mal schlau gemacht und jemanden gefunden der ein fast identisches setup hat. Der Kollege von dort hat keine probleme mit 2 verbauten SSD's auf nicht unraid systemen (windows/debian) und ohne ASM1166 über c3 hinaus zu kommen. An meinen BIOS Einstellungen gab es ebenfalls nichts zu beanstanden. Er hatte lediglich eine etwas ältere BIOS version im Einsatz. Siehe hier

Jedenfalls ist mir irgendwann aufgefallen, dass meine 500GB Sandisk nicht mehr die fitteste ist und schon einiges aufm buckel hat. Das und der magere Speicherplatz gaben mir Grund zu einem Upgrade bzw. austausch. Ich hatte diese platte mal bei meinem Umzug nach vorne (M2A_CPU) verfrachtet und dabei viel mir auf, dass die NVME dort probleme bereitet:

[   64.114914] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
[   64.114928] nvme nvme0: Does your device have a faulty power saving mode enabled?
[   64.114932] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug
[   64.127651] nvme0n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct 0x3 / sc 0x71) 
[   64.127669] I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[   64.134823] nvme 0000:02:00.0: enabling device (0000 -> 0002)
[   64.135080] nvme nvme0: Disabling device after reset failure: -19
[   64.143987] Buffer I/O error on dev nvme0n1, logical block 0, async page read
[   64.152742] Buffer I/O error on dev nvme0n1p1, logical block 0, async page read
[   64.249889] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.

Mit den hier angebotenen cmdline befehlen bekam ich die Platte auch online. "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off"

Wenn ich in M2A_CPU zwei Samsung NVME (980 oder 990 Pro) installiere, erhalte ich folgende Meldungen:

[    3.224540] nvme 0000:02:00.0: platform quirk: setting simple suspend  ## Das macht der nur im M2A_CPU port

Außerdem haben beide Samsung's unterschiedliche latencies die eventuell auch ein problem darstellen.

Sowohl in M2A_CPU als auch M2B_SP (der hintere port) erhalte folgende D3 entry Meldung

[    3.239673] nvme nvme1: D3 entry latency set to 8 seconds ## 980 NVME
[    3.239673] nvme nvme1: D3 entry latency set to 10 seconds ## 990 Pro

Und da frage ich mich, warum zur Hölle braucht d ie Pro 2 sekunden länger als die nicht pro?

Jedenfalls lassen sich diese Werte nicht über cmdline Befehle umgehen... Ich habe mich da dumm und dämlich gesucht...

Diese Samsung NVME's sind doch eigentlich recht gängig und ich habe auch öfter gelesen das die empfohlen wurden, aber warum haben nicht mehr Leute das problem mit denen?

Mit einer Samsung komme ich nicht über C2 hinaus und die halb marode Sandisk schafft das ohne probleme...

Selbst wenn ich alle container stoppe, verbraucht die 990 Pro jetzt konstant 9w mehr egal ob vorne oder hinten verbaut. Da war die 1TB 980 noch 4 watt sparsamer, aber trotzdem immer bei 0,01w.

Habt ihr das gleiche problem mit Samsung platten?

5 hours ago, W0nderW0lf said:

Jedenfalls ist mir irgendwann aufgefallen, dass meine 500GB Sandisk nicht mehr die fitteste ist

Je nachem von wann die ist, wurde sie im Zeitraum erstellt als SD zu WD gehörte. Einieg WD NVMe SSD haben Probleme mit Energiesparmassnahmen gehabt. Ich meine WD NVMe SSD unter unraid.

5 hours ago, W0nderW0lf said:

Diese Samsung NVME's sind doch eigentlich recht gängig und ich habe auch öfter gelesen das die empfohlen wurden, aber warum haben nicht mehr Leute das problem mit denen?

Ich sehe, dass einige Leute die 990 Pro einsetzen.

Aber empfohlen wurde sehr oft generell Samsung und das stammt auch oft aus der Zeit der Samsung 970 Evo Plus Modelle und der danach gefolgten Evos.

5 hours ago, W0nderW0lf said:

Selbst wenn ich alle container stoppe, verbraucht die 990 Pro jetzt konstant 9w mehr egal ob vorne oder hinten verbaut. Da war die 1TB 980 noch 4 watt sparsamer, aber trotzdem immer bei 0,01w.

Habt ihr das gleiche problem mit Samsung platten?

Ich nutze keine Samsung 990 Pro unter unraid. Meine (noch wenigen eingesetzten) Samsung 970 Evo Plus 2TB haben keine Probleme gezeigt. Da mir aber 2TB zu klein waren habe cihd ann angefangen auf 4TB zu setzen und da Samsung zu der Zeit keine (preislich attraktiven) 4TB im Angebot hatte, bin ich zu AData, Lexar und Patriot geschwnkt.

Mein meiden der Samsung 990 Pro hängt bei mir primär mit einem Problembericht zsuammen (dass die Samsung ausgestiegen ist/sich abmeldete) und dem Preis.

Es wurde aber nach dem Problem später mitgeteilt, daß ein Firmwareupdate vorhanden sei, welches dieses Problem beheben würde.

Hast Du mal nach der altuellsten Firmware geschaut?

Vielleicht bessert Die das von Dir beobachtete Verhalten.

24 minutes ago, DataCollector said:

Mein meiden der Samsung 990 Pro hängt bei mir primär mit einem Problembericht zsuammen (dass die Samsung ausgestiegen ist/sich abmeldete) und dem Preis.

Es wurde aber nach dem Problem später mitgeteilt, daß ein Firmwareupdate vorhanden sei, welches dieses Problem beheben würde.

Hast Du mal nach der altuellsten Firmware geschaut?

Vielleicht bessert Die das von Dir beobachtete Verhalten.

Jup, ist mir bei meinen recherchen auch aufgefallen. Da gab es mal einen Bericht bei Heise, dass ein bestimmtes Pro modell fehler aufwies. Jedenfalls habe ich die neueste Firmware aus Dezember 2025 über einen guide hier im forum flashen können. Beide modelle die ich betreibe haben die neueste.

Hast du mit deiner Samsung im dmesg auch die Meldung wegen der D3 latency und kannst trotzdem rein wechseln?

32 minutes ago, DataCollector said:

Je nachem von wann die ist, wurde sie im Zeitraum erstellt als SD zu WD gehörte. Einieg WD NVMe SSD haben Probleme mit Energiesparmassnahmen gehabt. Ich meine WD NVMe SSD unter unraid.

Diese Probleme hat die aber nur im vorderen Port. Hinten im M2B_SP Port hat die weder die Meldung gehabt, noch probleme mit den c-states. Das schwächste glied erwies sich hier als das zuverlässigste was das angeht.

2 hours ago, W0nderW0lf said:

Hast du mit deiner Samsung im dmesg auch die Meldung wegen der D3 latency und kannst trotzdem rein wechseln?

Das habe ich nicht getestet.

Bezüglich testen...

Ne Ahnung ob ich mit einem live USB (anderes OS als Unraid) die ASPM bzw. c-state Fähigkeit testen kann?
Dachte an sowas wie mint oder windoof mit energiespar settings. Schon mal Erfahrung damit gesammelt?

Würde gerne ausschließen das es an unraid liegt.

Edited January 25Jan 25 by W0nderW0lf

33 minutes ago, W0nderW0lf said:

Bezüglich testen...

Ne Ahnung ob ich mit einem live USB (anderes OS als Unraid) die ASPM bzw. c-state Fähigkeit testen kann?
Dachte an sowas wie mint oder windoof mit energiespar settings. Schon mal Erfahrung damit gesammelt?

Würde gerne ausschließen das es an unraid liegt.

Klar, kannst ein beliebiges live Linux nehmen, musst dann dort nur noch an powertop kommen

Also ich hab gestern mal zum test linux mint auf einem Stick betrieben und bin ein bischen schlauer, habe aber noch keine Lösung.

Über Powertop konnte ich alle tunables auf good setzen.

Habe dann manuell alle platten runter gefahren. Nur die NVME lies sich nach wie vor nicht beeinflussen.

Erstaunlich fand ich das das mint im idle C2 (94%) erreicht hat und 20Wverbraucht, wohingegen Unraid nur auf C2 (54%) kommt und 26W verbraucht.

Da frage ich mich widerum, warum verbraucht unraid so viel fürs fast nix tun? Ich habe keine permanent laufenden cronjobs und das gleiche Ergebnis liefert unraid wenn ich alle container beende. vm ist generell nie an.

Ich habe mal ein Ticket bei gigabyte eröffnet und möchte von denen erfahren warum das BIOS / Mainboard nicht mit der SSD harmoniert.

Z.B. gab es im proxmox forum das gegenteilige problem, dass die user nicht von D3cold (spar modus) in D0 (high usage) wechseln konnten. Somit würde die SSD tiefere sleep-states supporten.

Zusammengefasst:

ASPM Native und power management platform sind beide enabled.

c-states bis 10 sind aktiv.

ERP (on/off) bringt keine Änderung..

(Turbo Energy efficient / turbo mode / turbo max 3.0 (on-off)) macht auch keine Änderung.

ASPM ist supported und funktioniert für alle geräte die sich abschalten lassen.

[    1.327682] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]

Autotweak settings:

07:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller S4LV008[Pascal] (prog-if 02 [NVM Express])
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
		Capabilities: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
		Settings: ASPM L1 Enabled; RCB 64 bytes, LnkDisable- CommClk+
		Status: Speed 8GT/s (downgraded), Width x4
		ASPM Capabilities: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
		ASPM Settings: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+

Klar zu erkennen ist hier D0 (high usage mode) und PME-Enable(-) was so viel heißt wie "power management events disabled". Das APST wiederum, was die virtuellen power states anbelangt, kommt ohne probleme weiterhin bis in power state 4 (sparsamste stufe mit 0,005w) was sich aber nicht mit der anzeige in der WebUI mit 0,01w deckt.