Thread Starter
- Mitglied seit
- 24.06.2005
- Beiträge
- 180
- Desktop System
- blindfish
- Prozessor
- Intel Core i9-9980XE
- Mainboard
- ASUS ROG Rampage VI Apex
- Kühler
- Aquacomputer cuplex kryos NEXT VARIO
- Speicher
- G.Skill Trident Z RGB 64GB
- Grafikprozessor
- EVGA GeForce RTX 2080 Ti XC @ AquaComputer kryographics NEXT
- Display
- 2x Dell U2412M, 1x LG UltraGear 27GN880-B
- SSD
- Samsung SDD 970PRO 1TB
- Opt. Laufwerk
- ASUS BW-16D1HT
- Soundkarte
- RME ADI-2 DAC FS
- Gehäuse
- Corsair Obsidian 900D
- Netzteil
- Seasonic Prime Platinum 1200W
- Keyboard
- Ducky Shine 7
- Mouse
- Logitech G502 Proteus
- Betriebssystem
- Windows 11 Pro
- Webbrowser
- Firefox
- Internet
- ▼100 MBit ▲40 MBit
Hallo zusammen,
ich befinde mich gerade in einem völlig übertriebenen Umstiegsprojekt von einem Synology DS-415+ auf ein selbstgebautes TrueNAS SCALE System, das als NAS und kleiner Hypervisor dienen soll.
Meinen Anforderungen gemäß habe habe ich folgende Hardware zusammengestellt:
Zuletzt kam die Frage des Mainboards auf. Wichtig dabei war mir eine möglichst geringe Leistungsaufnahme des Grundsystems.
Das soll jetzt nicht in eine Diskussion darüber ausarten, wie viel Sinn das bei 8 Festplatten macht, ob Spindown schädlich ist, etc etc.
Mainboards, die für diese Hardware in Frage kommen, müssen entweder auf dem W680 Chipsatz oder dem R680E Chipsatz basieren, da beide ECC Unterstützung für LGA-1700 bieten.
Folgende Boards kamen daher für mich in Frage:
Allerdings habe ich im Internet keine detaillierten Angaben zu optimierter Leistungsaufnahme im Idle oder Package-C-State Verhalten bei (Nicht-)Verwendung bestimmter Slots gefunden.
Also habe ich mir alle drei Boards kommen lassen und entsprechende Messungen durchgeführt, die ich mit euch teilen möchte. Vielleicht helfen diese Informationen ja dem einen oder anderen, der auch in Erwägung zieht, eines dieser Mainboards zu verwenden.
Gemessen wurde die Leistungsaufnahme an der Steckdose mit einem Gude Expert Power Control 1100 (EPC-1100).
Vorgehen
Zuerst wurden im BIOS sämtliche Schnittstellen und Funktionen, die ich für den Server-Betrieb nicht benötige, deaktiviert (z.b. Serielle oder Parallel-Ports, Onboard Sound, zusätzliche LAN Controller, ...).
Alle Stromsparmodi für PCIe-Slots (ASPM) sowie CPU C-States wurden explizit aktiviert (ASPM: L1 mit Submodi L1.1 und L1.2 wo möglich, CPU auf C10).
Als Betriebssystem kam Debian 12 Bookworm zum Einsatz.
Zur Messung der C-States wurde Powertop 2.15 mit Support für Raptor Lake-S verwendet.
Jedes Board wurde mit unterschiedlichen Hardware-Konfigurationen getestet, um den Einfluss von Onboard-Komponenten und (Nicht-)Verwendung von M.2, PCIe-, oder SATA-Slots auf die Leistungsaufnahme und den Package C-States zu messen.
Die Hardware-Konfiguration wurde bei abgeschaltetem System hergestellt, dann wurde gebootet. Die erste Messung wurde nach dem Booten ins OS abgenommen, sobald die Leistungsaufnahme über mindestens 20 Sekunden stabil war. Dann wurde der Package C-State mit Powertop geprüft, danach powertop --auto-tune ausgeführt und der Package C-State sowie Leistungsaufnahme erneut gemessen.
Bei Verwendung von PCIe-Plätzen wurde in der Tabelle der jeweilige höchste erzielte C-State mit niedrigster Leistungsaufnahme aufgenommen. Dabei wurde in Kauf genommen, dass HBA und 10G NIC u.U. nur mit halber Anzahl an PCIe Lanes angebunden wurden, was aber vom Durchsatz her kaum eine Rolle spielen sollte, solange am HBA nur HDDs hängen (PCIe 2.0 x4 = 2GB/s für 8 HDDs = 250MB/s pro HDD).
Besonderheiten diesbzgl. sind im jeweiligen Absatz zum Mainboard separat beschrieben.
Folgende Tabelle zeigt alle verschiedenen Konfigurationen, für die der Verbrauch gemessen wurde:
Die letzte Zeile der Tabelle stellt den für mein aktuelles Projekt "Vollausbau" an Komponenten dar.
Der HBA hat eine gemessene eigene Leistungsaufnahme von ca 6-7W (ausgewählt auf Grund dieses Artikels), der 10G NIC von ca 4-5W.
Bemerkungen zu den einzelnen Boards
Kontron K3851-R
Kontron hat die Mainboard-Sparte von Fujitsu übernommen, deren Boards für sehr sparsamen Betrieb bekannt waren.
Dieses Board setzt auf den embedded R680E Chipsatz, der wie der große W680 ebenfalls ECC unterstützt. Laut Intel ARK sind die Feature-Sets sehr ähnlich, W680 hat Optane-Support, der beim R680 fehlt.
Das Board hat zwei mechanische PCIe x16 Slots, allerdings ist nur einer mit x16 5.0 direkt an die CPU angebunden. Der zweite ist elektrisch als x4 4.0 an den Chipsatz angebunden.
Der erste Slot unterstützt Bifurcation auf x8x8 oder x8x4x4 mit entsprechendem Riser (laut BIOS, nicht getestet!).
Ebenfalls besitzt das Board nur zwei M.2 Key M Slots, ebenfalls einer an der CPU, einer am Chipsatz angebunden.
Weiterhin gibt es zwei Onboard LAN Controller, einen Intel i219LM (Gbit) sowie einen Intel i225LM (2x 2.5Gbit).
Pkg C-State Verhalten:
Es war nicht möglich, einen höheren Pkg C-State als 3 zu erreichen, auch wenn die Leistungsaufnahme damit schon nicht schlecht war.
Zwei PCIe Root Nodes der CPU/Chipsets sowie die PCIe-to-PCI Bridge PI7C9X113SL, die sich um die Anbindung des PCI Slots kümmert, haben kein ASPM aktiviert, obwohl laut Link Cababilities in lspci -vv unterstützt. Auch das Erzwingen von ASPM (siehe https://wireless.wiki.kernel.org/en/users/Documentation/ASPM) brachte keinen Unterschied bei den C-States.
Sobald der an die CPU angebundene PCIe Slot verwendet wurde (egal ob im x16 oder x8x8 Mode), kam die CPU nicht mehr über Pkg C-State 2 hinaus.
ASUS W680-ACE IPMI
Das ASUS Workstation-Board kommt dem W680 Chipsatz und bietet 4 S-ATA Header direkt Onboard, sowie einen SlimSAS Connector, der entweder PCIe 4.0 x4 oder 4x S-ATA 6Gb/s per Breakout-Kabel liefern kann.
Ich hatte die IPMI-fähige Version mit externer IPMI PCIe x1 Karte, die dann mit entsprechenden Kabeln mit Onboard USB, Power/Reset Switch sowie dem BMC Header verbunden wird.
Verbrauch des Systems im ausgeschalteten Zustand lag bei 5W, im Betrieb hat die Karte 3W Eigenverbrauch.
Pkg C-State Verhalten:
Das Board zeigt in interessantes Pkg C-State Verhalten:
Logisch erklären, warum C8 oder nur C6 bei den jeweiligen M.2 Slot-Belegungen erreicht werden, kann ich nicht. Diese Messungen sind aber geprüft.
SuperMicro X13SAE-F
Das SuperMicro X13SAE-F ist die Variante des W680 Boards mit integriertem IPMI. Im Gegensatz zum ASUS ist der ASPEED BMC Chip direkt auf dem Mainboard verlötet, zusammen mit einem dedizierten IPMI LAN- sowie VGA Port.
Dieses Board bietet 8 Onboard S-ATA Header, zwei mechanische PCIe 5.0 x16 Slots, die direkt an der CPU hängen, aber elektrisch x16/x0 oder x8/x8 angebunden sind.
Zwei der drei M.2 Slots hängen am Chipsatz, einer an der CPU.
Das Board kommt mit zwei Onboard LAN Controllern, einem 1Gbit Intel I219LM, sowie einem 2.5Gbit Intel I225LM.
Pkg C-State Verhalten:
Ähnlich wie das Kontron K3851-R konnte ich dieses Board nicht unter Pkg C3 bringen, selbst unter Deaktivierung aller Onboard-Komponenten und Booten von USB-Laufwerk.
Andererseits war dem Board dann ziemlich egal, was aktiviert oder angeschlossen wurde. Nur die Nutzung eines der an die CPU angebundenen PCIe Slots führte zu C2, alles andere getestete landete immer bei C3.
Die meisten Onboard Komponenten haben hier standardmäßig ASPM deaktiviert. Erzwingen von ASPM brachte keine Änderung des C-States.
Falls ihr Fragen habt, versuche ich diese gerne zu beantworten. Alle Boards habe ich noch ein paar Tage da, Zeit für spezielle Tests ist aber begrenzt.
Wie oben bereits geschrieben soll sich jegliche Diskussion auf diese drei Boards und ihr Leistungsaufnahme-Verhalten beziehen, bitte nicht auf Wahl der Software oder restlichen Hardware-Komponenten.
Gruß,
blindfish
ich befinde mich gerade in einem völlig übertriebenen Umstiegsprojekt von einem Synology DS-415+ auf ein selbstgebautes TrueNAS SCALE System, das als NAS und kleiner Hypervisor dienen soll.
Meinen Anforderungen gemäß habe habe ich folgende Hardware zusammengestellt:
- Intel Core i5-13600
- Noctua NH-U9S
- 2x Kingston Server Premier DIMM 16GB ECC
- 3x Samsung SSD 870 Evo 2TB, SATA
- 1x HP SSD S700 120GB, SATA (crappy Bootdrive )
- 2x Samsung SSD 980 PRO 2TB, M.2
- 4x Western Digital Ultrastar DC HC550 18TB
- 4x Western Digital Ultrastar DC HC510 10TB (noch vorhanden)
- Broadcom 9211-8i HBA (gebraucht)
- Intel X520-DA2 LAN-Adapter 10G SFP+ (gebraucht)
- Corsair RMx Series 2021 RM550x
- Inter-Tech 4U-4410
Zuletzt kam die Frage des Mainboards auf. Wichtig dabei war mir eine möglichst geringe Leistungsaufnahme des Grundsystems.
Das soll jetzt nicht in eine Diskussion darüber ausarten, wie viel Sinn das bei 8 Festplatten macht, ob Spindown schädlich ist, etc etc.
Mainboards, die für diese Hardware in Frage kommen, müssen entweder auf dem W680 Chipsatz oder dem R680E Chipsatz basieren, da beide ECC Unterstützung für LGA-1700 bieten.
Folgende Boards kamen daher für mich in Frage:
Allerdings habe ich im Internet keine detaillierten Angaben zu optimierter Leistungsaufnahme im Idle oder Package-C-State Verhalten bei (Nicht-)Verwendung bestimmter Slots gefunden.
Also habe ich mir alle drei Boards kommen lassen und entsprechende Messungen durchgeführt, die ich mit euch teilen möchte. Vielleicht helfen diese Informationen ja dem einen oder anderen, der auch in Erwägung zieht, eines dieser Mainboards zu verwenden.
Gemessen wurde die Leistungsaufnahme an der Steckdose mit einem Gude Expert Power Control 1100 (EPC-1100).
Vorgehen
Zuerst wurden im BIOS sämtliche Schnittstellen und Funktionen, die ich für den Server-Betrieb nicht benötige, deaktiviert (z.b. Serielle oder Parallel-Ports, Onboard Sound, zusätzliche LAN Controller, ...).
Alle Stromsparmodi für PCIe-Slots (ASPM) sowie CPU C-States wurden explizit aktiviert (ASPM: L1 mit Submodi L1.1 und L1.2 wo möglich, CPU auf C10).
Als Betriebssystem kam Debian 12 Bookworm zum Einsatz.
Zur Messung der C-States wurde Powertop 2.15 mit Support für Raptor Lake-S verwendet.
Jedes Board wurde mit unterschiedlichen Hardware-Konfigurationen getestet, um den Einfluss von Onboard-Komponenten und (Nicht-)Verwendung von M.2, PCIe-, oder SATA-Slots auf die Leistungsaufnahme und den Package C-States zu messen.
Die Hardware-Konfiguration wurde bei abgeschaltetem System hergestellt, dann wurde gebootet. Die erste Messung wurde nach dem Booten ins OS abgenommen, sobald die Leistungsaufnahme über mindestens 20 Sekunden stabil war. Dann wurde der Package C-State mit Powertop geprüft, danach powertop --auto-tune ausgeführt und der Package C-State sowie Leistungsaufnahme erneut gemessen.
Bei Verwendung von PCIe-Plätzen wurde in der Tabelle der jeweilige höchste erzielte C-State mit niedrigster Leistungsaufnahme aufgenommen. Dabei wurde in Kauf genommen, dass HBA und 10G NIC u.U. nur mit halber Anzahl an PCIe Lanes angebunden wurden, was aber vom Durchsatz her kaum eine Rolle spielen sollte, solange am HBA nur HDDs hängen (PCIe 2.0 x4 = 2GB/s für 8 HDDs = 250MB/s pro HDD).
Besonderheiten diesbzgl. sind im jeweiligen Absatz zum Mainboard separat beschrieben.
Folgende Tabelle zeigt alle verschiedenen Konfigurationen, für die der Verbrauch gemessen wurde:
Config | | | | Kontron K3851-R ATX | Kontron K3851-R ATX | Kontron K3851-R ATX | ASUS W680-ACE IPMI | ASUS W680-ACE IPMI | ASUS W680-ACE IPMI | Supermicro X13SAE-F | Supermicro X13SAE-F | Supermicro X13SAE-F | ||||
S-ATA Drive(s) | Onboard LAN | NVMe Slot 1 | NVMe Slot 2 | NVMe Slot 3 | Display | HBA | 10G NIC | Verbrauch | PKG C-State | powertop --auto-tune | Verbrauch | PKG C-State | powertop --auto-tune | Verbrauch | PKG C-State | powertop --auto-tune |
1 | x | x | | | | | | 13 | 3 | 13 | 19 | 2 | 19 | 19 | 3 | 17 |
1 | x | | x | | | | | 13 | 3 | 13 | 19 | 2 | 19 | 19 | 3 | 17 |
1 | x | | | x | | | | N/A | N/A | N/A | 19 | 2 | 19 | 19 | 3 | 17 |
1 | x | x | x | | | | | 13 | 3 | 13 | 19 | 2 | 19 | 19 | 3 | 17 |
1 | x | x | | x | | | | N/A | N/A | N/A | 19 | 2 | 19 | 19 | 3 | 17 |
1 | x | | x | x | | | | N/A | N/A | N/A | 19 | 2 | 19 | 19 | 3 | 17 |
| x | x | | | | | | 13 | 3 | 13 | 14 | 3 | 14 | 19 | 3 | 17 |
| x | | x | | | | | 12 | 3 | 12 | 14 | 3 | 14 | 19 | 3 | 17 |
| x | | | x | | | | N/A | N/A | N/A | 14 | 3 | 14 | 19 | 3 | 17 |
| x | x | x | | | | | 13 | 3 | 13 | 14 | 3 | 14 | 19 | 3 | 17 |
| x | x | | x | | | | N/A | N/A | N/A | 14 | 3 | 14 | 19 | 3 | 17 |
| x | | x | x | | | | N/A | N/A | N/A | 14 | 3 | 14 | 19 | 3 | 17 |
| | x | | | | | | 12 | 3 | 12 | 5 | 8 | 5 | 19 | 3 | 16 |
| | | x | | | | | 12 | 3 | 12 | 8 | 6 | 8 | 17 | 3 | 16 |
| | | | x | | | | N/A | N/A | N/A | 8 | 6 | 8 | 17 | 3 | 16 |
| | x | x | | | | | 12 | 3 | 12 | 5 | 8 | 5 | 17 | 3 | 16 |
| | x | | x | | | | N/A | N/A | N/A | 5 | 8 | 5 | 17 | 3 | 16 |
| | | x | x | | | | N/A | N/A | N/A | 9 | 6 | 8 | 17 | 3 | 16 |
1 | | x | | | | | | 13 | 3 | 13 | 19 | 2 | 19 | 19 | 3 | 17 |
1 | | | x | | | | | 12 | 3 | 12 | 19 | 2 | 19 | 19 | 3 | 17 |
1 | | | | x | | | | N/A | N/A | N/A | 19 | 2 | 19 | 19 | 3 | 17 |
1 | | x | x | | | | | 13 | 3 | 13 | 19 | 2 | 19 | 19 | 3 | 17 |
1 | | x | | x | | | | N/A | N/A | N/A | 19 | 2 | 19 | 19 | 3 | 17 |
1 | | | x | x | | | | N/A | N/A | N/A | 19 | 2 | 19 | 19 | 3 | 17 |
1 | x | x | | | x | | | 14 | 3 | 14 | 22 | 2 | 19 | 21 | 3 | 19 |
1 | x | x | | | | x | | 20 | 3 | 20 | 29 | 2 | 29 | 26 | 3 | 25 |
1 | | x | | | | | x | 18 | 3 | 18 | 23 | 2 | 23 | 23 | 3 | 22 |
1 | | x | | | | x | x | 25 | 3 | 25 | 33 | 2 | 33 | 30 | 3 | 29 |
1 | | x | x | | | x | x | 25 | 3 | 25 | 33 | 2 | 33 | 30 | 3 | 29 |
4 | | x | x | | | x | x | 26 | 3 | 25 | 34 | 2 | 33 | 31 | 3 | 29 |
Der HBA hat eine gemessene eigene Leistungsaufnahme von ca 6-7W (ausgewählt auf Grund dieses Artikels), der 10G NIC von ca 4-5W.
Bemerkungen zu den einzelnen Boards
Kontron K3851-R
Kontron hat die Mainboard-Sparte von Fujitsu übernommen, deren Boards für sehr sparsamen Betrieb bekannt waren.
Dieses Board setzt auf den embedded R680E Chipsatz, der wie der große W680 ebenfalls ECC unterstützt. Laut Intel ARK sind die Feature-Sets sehr ähnlich, W680 hat Optane-Support, der beim R680 fehlt.
Das Board hat zwei mechanische PCIe x16 Slots, allerdings ist nur einer mit x16 5.0 direkt an die CPU angebunden. Der zweite ist elektrisch als x4 4.0 an den Chipsatz angebunden.
Der erste Slot unterstützt Bifurcation auf x8x8 oder x8x4x4 mit entsprechendem Riser (laut BIOS, nicht getestet!).
Ebenfalls besitzt das Board nur zwei M.2 Key M Slots, ebenfalls einer an der CPU, einer am Chipsatz angebunden.
Weiterhin gibt es zwei Onboard LAN Controller, einen Intel i219LM (Gbit) sowie einen Intel i225LM (2x 2.5Gbit).
Pkg C-State Verhalten:
Es war nicht möglich, einen höheren Pkg C-State als 3 zu erreichen, auch wenn die Leistungsaufnahme damit schon nicht schlecht war.
Zwei PCIe Root Nodes der CPU/Chipsets sowie die PCIe-to-PCI Bridge PI7C9X113SL, die sich um die Anbindung des PCI Slots kümmert, haben kein ASPM aktiviert, obwohl laut Link Cababilities in lspci -vv unterstützt. Auch das Erzwingen von ASPM (siehe https://wireless.wiki.kernel.org/en/users/Documentation/ASPM) brachte keinen Unterschied bei den C-States.
Sobald der an die CPU angebundene PCIe Slot verwendet wurde (egal ob im x16 oder x8x8 Mode), kam die CPU nicht mehr über Pkg C-State 2 hinaus.
ASUS W680-ACE IPMI
Das ASUS Workstation-Board kommt dem W680 Chipsatz und bietet 4 S-ATA Header direkt Onboard, sowie einen SlimSAS Connector, der entweder PCIe 4.0 x4 oder 4x S-ATA 6Gb/s per Breakout-Kabel liefern kann.
Ich hatte die IPMI-fähige Version mit externer IPMI PCIe x1 Karte, die dann mit entsprechenden Kabeln mit Onboard USB, Power/Reset Switch sowie dem BMC Header verbunden wird.
Verbrauch des Systems im ausgeschalteten Zustand lag bei 5W, im Betrieb hat die Karte 3W Eigenverbrauch.
Pkg C-State Verhalten:
Das Board zeigt in interessantes Pkg C-State Verhalten:
- Ist ein Onboard LAN Controller aktiv, wird auf C3 begrenzt
- Nutzung der separaten IPMI Karte begrenzt ebenfalls auf C3
- Nutzung eines beliebigen S-ATA Ports begrenzt auf C2. Mangels eines SAS SFF-8654 Kabels konnte ich das Verhalten am SlimSAS Anschluss nicht testen
- Nutzung des HBAs oder Intel 10G NICs in einem bliebigen PCIe Slot begrenzt ebenfalls auf C2
Logisch erklären, warum C8 oder nur C6 bei den jeweiligen M.2 Slot-Belegungen erreicht werden, kann ich nicht. Diese Messungen sind aber geprüft.
SuperMicro X13SAE-F
Das SuperMicro X13SAE-F ist die Variante des W680 Boards mit integriertem IPMI. Im Gegensatz zum ASUS ist der ASPEED BMC Chip direkt auf dem Mainboard verlötet, zusammen mit einem dedizierten IPMI LAN- sowie VGA Port.
Dieses Board bietet 8 Onboard S-ATA Header, zwei mechanische PCIe 5.0 x16 Slots, die direkt an der CPU hängen, aber elektrisch x16/x0 oder x8/x8 angebunden sind.
Zwei der drei M.2 Slots hängen am Chipsatz, einer an der CPU.
Das Board kommt mit zwei Onboard LAN Controllern, einem 1Gbit Intel I219LM, sowie einem 2.5Gbit Intel I225LM.
Pkg C-State Verhalten:
Ähnlich wie das Kontron K3851-R konnte ich dieses Board nicht unter Pkg C3 bringen, selbst unter Deaktivierung aller Onboard-Komponenten und Booten von USB-Laufwerk.
Andererseits war dem Board dann ziemlich egal, was aktiviert oder angeschlossen wurde. Nur die Nutzung eines der an die CPU angebundenen PCIe Slots führte zu C2, alles andere getestete landete immer bei C3.
Die meisten Onboard Komponenten haben hier standardmäßig ASPM deaktiviert. Erzwingen von ASPM brachte keine Änderung des C-States.
Falls ihr Fragen habt, versuche ich diese gerne zu beantworten. Alle Boards habe ich noch ein paar Tage da, Zeit für spezielle Tests ist aber begrenzt.
Wie oben bereits geschrieben soll sich jegliche Diskussion auf diese drei Boards und ihr Leistungsaufnahme-Verhalten beziehen, bitte nicht auf Wahl der Software oder restlichen Hardware-Komponenten.
Gruß,
blindfish
Zuletzt bearbeitet: