mgutt

Damit meine ich den ganz normalen DDR5 RAM. Unter "non-ecc" wirst du nichts finden, weil jeder DDR5 RAM einen Pseudo ECC Chip verbaut hat ("On-Die ECC"). Das hat man wohl gemacht, um die Produktion zu erleichtern, da leicht fehlerhafte Module dann im Betrieb korrigiert werden. Eigentlich eine Sauerei, aber nachvollziehen kann es der User nicht. Ich vermute gerade beim RAM Overclocking hilft die ständige Korrektur. Tatsächlich sind echte ECC Module sehr selten: https://geizhals.de/?cat=ramddr3&xf=15903_DDR5~15903_keinSO~15903_mitECC~15903_ohneLR~15903_ohneREG&sort=r&hloc=at&hloc=de&v=e Wie man sieht heißen die "ECC On-Die ECC". Wobei letzteres halt eine unsinnige Erwähnung einer Selbstverständlichkeit darstellt.

Ignoriere das Alter. Linux liebt alte Hardware und schlussendlich ist dein Ziel ja ein stromsparendes Setup. Ob es jetzt allerdings mit dem Board klappt, kann ich dir auch nicht sagen.

Nein. Das ist Reg ECC: https://www.kingston.com/de/memory/search?partid=KSM48R40BD4TMM-64HMR Also Server RAM. Workstation ECC RAM ist Non-Reg ECC. Und Consumer Non-ECC geht aktuell bis max 48GB.

RJ45 sind ca 6W und SFP ca 3W. Ich würde wenn eine Intel Karte nehmen oder vielleicht sogar gar nicht 10G, sondern 2.5G. Das ist auch schon sexy, dafür deutlich sparsamer. Auch auf Seiten des Switches. Wenn du die zweite Buchse nicht verwendest, ist das glaube ich nicht wirklich relevant. Ich denke wenn es eine Single Karte mit X4 gibt, dann wäre das evtl sparsamer als eine X8 Karte, weil halt weniger Lanes aktiv sind. Andersherum könne man die X8 Karte auch in einen X1 Slot packen (wenn dieser offen ist). Oder Pins abkleben ginge auch. Habe ich aber alles nicht gemessen. Ich kann dann aktuell leider keine Empfehlung aussprechen. Ich suche selbst auch. Gibt es nicht für Consumer Plattformen. Größter DDR5 ist aktuell 48GB, gehen aber auch nur nach BIOS Update. Bei Kontron müsste man fragen. Denk dran, dass Kontron kein W680 Board hat, also kein ECC RAM.

Übrigens hat man eigentlich erst durch die Treiber die richtigen Standby Zustände. Daher wäre es eigentlich komisch, wenn es ohne Treiber sparsamer wäre. Aber wer weiß. Ich habe das bisher selbst nie probiert. Aber bei Grafikkarten ist das zb so.

Tatsächlich sind die Geräte noch da, erhalten aber keine Treiber. Wenn du zb das im Terminal eingibst, dann gibt er alle Netzwerk Adapter inkl Treiber aus: lshw -class network Beispiel: product: Ethernet Controller 10G X550T ... logical name: eth0 ... driver=ixgbe driverversion=5.19.17-Unraid wenn ich richtig liege, dann werden die gar nicht auf die Art ausgegeben, weil die dann auch kein "ethX" erhalten haben sollten.

Brauchst du IPMI? Es gibt ja noch die Variante ohne: https://www.supermicro.com/en/products/motherboard/x13sae

Baller einfach alles weg. Wenn der Server nicht mehr hochfahren sollte, kannst du die syslinux/syslinux.cfg auf dem Stick auch über einen PC ändern. Du musst nur halt eine LAN-Buchse übrig lassen, damit du noch drauf kommst. Ansonsten könntest du auch mal versuchen Ubuntu zu booten. Manchmal scheint Ubuntu da besser mit umgehen zu können. Wenn das der Fall ist, dann kannst du gerne hier den Bug Report pushen:

Wird dadurch denn ASPM aktiv? Wie gesagt ist die Frage was da ASPM verhindert. Versuch vielleicht auch mal mehr Geräte zu deaktivieren. Zb der RTL8211E Ethernet Controller. Realtek fällt mir immer wieder mal negativ auf, wenn es um C-States geht.

Hier spricht jemand von über 20W: https://www.hardwareluxx.de/community/threads/dell-poweredge-t20.1031138/post-25197556 Aber das Netzteil klingt nicht sonderlich effizient. Vielleicht noch Potential nach unten?! Option 1 ist halt sehr teuer und garantiert dir auch keinen niedrigen Verbrauch. Ich denke aber vom Prinzip sollten alle Supermicro so bei 15 bis 20W liegen. Alleine wegen IPMI.

Du benutzt nicht die offizielle Nextcloud Version, also wirst du auch keinen Support hier erhalten, da Linuxserver zwar die unRAID Container Templates anbietet, aber keine Support Threads hier pflegt. Mit ein Grund warum ich niemandem diese Version empfehle. Also wenn kannst du nur hier fragen: https://github.com/linuxserver/docker-nextcloud/issues Von den Logs her scheint dein Problem daraus zu resultieren, dass die Datenbank nicht erreichbar ist.

Mit dem BIOS wird das denke ich nichts zu tun haben. Zumindest wenn die Aussage stimmt, dass ASPM und die C-States gehen. Wenn du die Zeit investieren willst, könntest du die Installation von Treibern mit vfio-pci.ids= oder modprobe.blacklist= verhindern. Hier ein Beispiel: https://gist.github.com/mallendeo/afceedfdc9c5c8f260e18a6bde89a868?permalink_comment_id=3551651 Also zb den 10G Controller dadurch blacklisten und schauen was passiert. Und das dann eben mit allen Onboard Controllern, die das Board hat.

Exakt. Sie sagen es geht und zeigen wie man es abschaltet. Allerdings haben sie bestätigt, dass die C-States nur in der UEFI Shell getestet wurden. Diese Shell erlaubt nur wenige Kommandos und kommt noch vor dem Boot Loader des Betriebssystems (wie zb Grub). Dementsprechend laufen zu dem Zeitpunkt auch noch keine Hardware Treiber. Also wäre das quasi die Bestätigung, dass irgendein Treiber von irgendeinem Gerät ASPM deaktiviert. Also jetzt alle PCIe Geräte per syslinux blacklisten? ^^

Ok. Then maybe this is a new behavior of the recent unRAID version.

There is already something listening on port 443. Did you enable SSL for unRAID and does unRAID use 443? Disable SSL and change unRAIDs ports to 5000 and 5001.

Brauchst du die denn beide? Also könnte man nicht was als Docker umsetzen und dabei die iGPU der CPU nutzen?

All my container templates have a RAM limit set to avoid server crashes if a container goes wild.

Beide bekannt für Stauwärme. Daher ist das R5 auch meine Empfehlung. Davon abgesehen ist das 804 mit 41 Litern auch nicht wirklich klein.

Oder in ein Script, was per User Scripts Plugin beim Array Start ausgeführt wird.

Ich habe wieder etwas wichtiges über HA gelernt: Erstelle niemals einen Custom-Sensor, der mehrere Entitäten enthält ohne zeitbasierten Trigger. Warum? Weil ein Sensor, wenn man keinen zeitbasierten Trigger hinterlegt, sich immer dann aktualisiert, wenn die Entität sich aktualisiert: https://www.home-assistant.io/integrations/template/#trigger-based-template-binary-sensors-buttons-numbers-selects-and-sensors Addiert man wie im folgenden Beispiel drei Entitäten, um eine Summe in einem neuen Sensor zu erhalten, wird dieser also nicht nur 1x alle 60 Sekunden aktualisiert, sondern jedes mal, wenn eine der drei Entitäten aktualisiert wird: - sensor: - name: Wärmepumpe Verbrauch unique_id: shelly3wp_power unit_of_measurement: 'W' state: '{{ (states("sensor.shelly3wp_channel_a_power") | float(0) + states("sensor.shelly3wp_channel_b_power") | float(0) + states("sensor.shelly3wp_channel_c_power") | float(0)) | round(2) }}' device_class: power state_class: measurement Was ist nun das Problem daran? Ein Auszug aus meiner HA-Datenbank zeigt es: Während ich also zuvor den Verbrauch der Wärmepumpe durch Addition aller drei Phasen mehrmals pro Minute erfasst hatte, passiert das nun durch den Time Trigger nur noch 1x pro Minute. Was das an Datenbank-Platz spart, muss ich denke ich nicht erklären. Dieser Custom-Sensor sieht nun jedenfalls so aus: - trigger: - platform: time_pattern minutes: "/1" sensor: - name: Wärmepumpe Verbrauch unique_id: shelly3wp_power unit_of_measurement: 'W' state: '{{ (states("sensor.shelly3wp_channel_a_power") | float(0) + states("sensor.shelly3wp_channel_b_power") | float(0) + states("sensor.shelly3wp_channel_c_power") | float(0)) | round(2) }}' device_class: power state_class: measurement HA ist immer für eine Überraschung gut.

Woher wusstest du eigentlich, dass du die zwei Widerstände ersetzen musst? Weil hier wird ja eigentlich gar nichts erklärt, außer dass es theoretisch irgendwie gehen soll: https://github.com/badger707/m920q-pcie-bifurcation Wird das irgendwo genauer erklärt? Weil hier spricht er ja nur davon, dass er nicht ohne Spezial BIOS weiterkommen würde: https://forums.servethehome.com/index.php?threads/lenovo-thinkcentre-thinkstation-tiny-project-tinyminimicro-reference-thread.34925/post-373232

Warum hast du den geholt?! Der hat nur 1x NVMe und 1x SATA und 1x Wifi. Ich würde wenigstens den M920q holen, weil der hat noch einen PCIe Slot. Oder eben noch besser den M910x oder M920x. Ich habe zwischenzeitlich die Unterschiede im ersten Beitrag ergänzt: Jetzt hast du jedenfalls das Problem, dass du eine NVMe mit einer SATA SSD kombinieren willst. Das macht hinten und vorne keinen Sinn, weil die SATA SSD die NVMe ausbremst. Wenn müsstest du dir jetzt schon einen Wifi M.2 Adapter besorgen und dann eine NVMe unten verbauen und eine adaptiert im Wifi Slot. Dann hättest du ein RAID1 aus zwei NVMe, wobei auch das wegen dem Wifi Slot gedrosselt wäre. Aber ich denke 1 GB/s ist vertretbar. An NVMe würde ich ausschließlich Samsung kaufen.

Scheinbar hast du die Karte nicht an VFIO gebunden. Sagt dir dass nichts? Dann arbeite doch mal durch ein paar Tutorials / YouTube Videos zu dem Thema.

Die Antwort ist einfach: Wegwerfen. Von Marvell Treibern hört man im Linux Universum immer wieder von Problemen, weshalb Limetech auch grundsätzlich davon abrät. Aktuell die beste Option ist eine Karte mit ASM1166. Optimal sogar, wenn man das Firmware Update installiert (geht leider nur unter Windows), dann unterstützt die Karte auch AHCI DIPM, ist also sehr stromsparend.

Ich finde leider den Beitrag nicht mehr, aber jemand hatte auch einen 4xxxG oder 5xxxG getestet und meinte dann, dass es keine Besserung gab. Weiß zufällig noch jemand wer das war?