Het grote zuinige server topic - deel 3

[Jerie]

Overspark schreef op zaterdag 24 januari 2026 @ 18:25:
[...]

Soms minder zuinig zelfs, al zijn de verschillen klein. Het enige doel van de T varianten is om niet boven een vrij laag wattage uit te komen, wat vooral handig is als je er heel veel in een 19" rack hebt zitten of om een andere reden niet boven een bepaald wattage wilt komen. Maar dat betekent ook dat hij langer doet over complexe taken, en dus langer z'n cores wakker moet houden. Afhankelijk van je workload kan het betekenen dat je daardoor in totaal meer stroom verbruikt. Maar als je nooit of zelden tegen de limieten aan zit maakt het niet uit.

Ook prima als je zoonlief wel root wilt geven, maar hij niet de processor mag overclocken tot de energierekening eraan gaat. Daarom gebruikte ik dit vroeger ook (al was dat AMD E-series). Het scheelt je ook warmte.

[Perzikvrucht]

Ik probeer via hdparm middels de volgende command in proxmox mijn WD Red Plus 4TB schijf in spindown te krijgen met APM:

hdparm -S 241 -B 127 /dev/sda

Alleen nu kan het eerste deel wel uitgevoerd worden (spindown) maar APM niet. Hebben jullie hier ervaring mee? Hoe dit toch voor elkaar te krijgen, eventueel op een andere manier?

[mdcobra]

Ik dacht ik ga een zuinig Proxmox server in elkaar zetten, maar ik krijg het idle verbruik maar niet onder de 24W zowel met Proxmox als Ubuntu. Update: ik denk dat het zit in de NIC, als ik het netwerk loshaal gaat ie nu naar C8, met een verbruik van 16W. Kloteding die i225v

Schone Proxmox install zonder vm's/ct's. Alle relevante BIOS settings gedaan, powertop --auto-tune. 286.4 wakeups/second.
Kernel parameters toegevoegd: "intel_idle.max_cstate=10 processor.max_cstate=10 pcie_aspm=force pcie_aspm.policy=powersupersave consoleblank=15"

In powertop kan ik zien dat de cores naar C10 gaan maar het package op C2 blijft steken wanneer de intel nic een verbinding heeft.
Hier kan ik zien dat het veel beter kan : https://gathering.tweaker...message/75823202#75823202
Heeft iemand nog ideeën 24W voor een idle server is wat matig? @andru123 ik vraag me af hoe jij die goede waarden heb gekregen.

#	Categorie	Product	Prijs	Subtotaal
1	Processors	Intel Core i5-12400 Boxed	€ 181,60	€ 181,60
1	Moederborden	Gigabyte B660I AORUS PRO DDR4	€ 0,-	€ 0,-
1	Geheugen intern	Corsair Vengeance LPX CMK64GX4M4B3600C18	€ 0,-	€ 0,-
1	Voedingen	FSP Dagger Pro 550W	€ 0,-	€ 0,-
1	Interne SSD's	Crucial P3 2TB (CT2000P3SSD8)	€ 269,83	€ 269,83
			Totaal	€ 451,43

[ Voor 8% gewijzigd door mdcobra op 26-01-2026 10:55 ]

[Wild Chocolate]

Perzikvrucht schreef op zondag 25 januari 2026 @ 10:52:
Ik probeer via hdparm middels de volgende command in proxmox mijn WD Red Plus 4TB schijf in spindown te krijgen met APM:

hdparm -S 241 -B 127 /dev/sda

Alleen nu kan het eerste deel wel uitgevoerd worden (spindown) maar APM niet. Hebben jullie hier ervaring mee? Hoe dit toch voor elkaar te krijgen, eventueel op een andere manier?

Ik heb ook een WD Red Plus (12 TB) in mijn servertje, maar ben er nog niet aan toe gekomen om hiervoor te gaan zitten.

Ik heb wel dit gevonden, in het tweede deel van de tekst:

quote: https://withblue.ink/2016...-to-build-a-home-nas.html

On Linux, the traditional way to control disk standby (and power management) is to use hdparm; however, hdparm will not work with WD Red drives, because the firmware of the disks doesn’t support that. Instead, we can use the third-party hd-idle utility to accomplish this.

Maar ik heb nog niet uitgezocht of hd-idle inmiddels wat makkelijker beschikbaar is voor ProxMox. Het artikel is 10 jaar oud, maar dit stuk lijkt verder nog wel actueel.

EDIT: hd-idle is beschikbaar via APT, ik heb het nog niet ingesteld.

[ Voor 5% gewijzigd door Wild Chocolate op 25-01-2026 17:10 ]

[mbbs1024]

Ik heb ook een op debian 13 gebaseerde NAS/HTPC gebouwd met de energiebesparende tips uit dit topic, powertop, tlp, hdparm.

Er zit naast een 500GB ssd voor het os, ook een HUH721010ALE601, 10TB harde schijf in, en het gebeurt dikwijls, als ik iets vanop die schijf nodig heb, dat het een paar seconden duurt vooraleer hij reageert.
Als ik bvb een bestand naar die disk kopieer, of gewoon op een directory klik, zie ik onmiddellijk het disk activity lampje aan gaan, de file manager is dan gedurende een paar seconden geblokkeerd, en dan pas hoor ik de schijfkoppen hun ding doen, en krijg ik in de file manager de uitvoering van de aktie te zien.

Zijn er nog mensen die daar tegenaan lopen, en wat is de oplossing daarvoor ?
Ik heb via hdparm de spindown al eens uitgeschakeld, maar dat heeft geen effect.

[mkleinman]

Ik heb mijn Proxmox 3 node cluster volledig werkend, inclusief aparte netwerken voor storage, management, en sync.
Node 1 en 2 beide D 3642B met respectievelijk 128gb en 96gb ram, beide met een I9 9900T
Node 3 is een onbekend moederbord ( moet ik opzoeken ) 128gb ram en een i5 13500 CPU.

Distributed storage: In elke node zitten 2 1.92TB SSD's van Samsung (PM863A).

In alle machines zit een dual NIC X710 10Gbe netwerkkaart, naast een losse 1gbit NIC. 30 cores, 52 threads, 352Gb ram totaal.

Totaal nu 22 VM's en containers die er op draaien.

Inclusief beide switches en alle drie de nodes up and running doet deze gehele combinatie tussen de 70 en 80W!

Zelfs tijdens het actief moven van een lokale VM naar de Ceph storage pool komt verbruik niet boven de 120W uit!

Dit had ik niet verwacht!

[GoBieN-Be]

Overspark schreef op zaterdag 24 januari 2026 @ 18:25:
[...]
Maar dat betekent ook dat hij langer doet over complexe taken, en dus langer z'n cores wakker moet houden. Afhankelijk van je workload kan het betekenen dat je daardoor in totaal meer stroom verbruikt. M

Als je uitgaat van een mooie evenredige relatie tussen performantie en verbruik. Maar dat is niet zo, het is hier in dit topic al duidelijk gebleken dat het boosten naar hogere frequentie onevenredig hoger verbruik met zich meebrengt.

[bjp]

mbbs1024 schreef op zondag 25 januari 2026 @ 16:18:
Ik heb ook een op debian 13 gebaseerde NAS/HTPC gebouwd met de energiebesparende tips uit dit topic, powertop, tlp, hdparm.

Er zit naast een 500GB ssd voor het os, ook een HUH721010ALE601, 10TB harde schijf in, en het gebeurt dikwijls, als ik iets vanop die schijf nodig heb, dat het een paar seconden duurt vooraleer hij reageert.
Als ik bvb een bestand naar die disk kopieer, of gewoon op een directory klik, zie ik onmiddellijk het disk activity lampje aan gaan, de file manager is dan gedurende een paar seconden geblokkeerd, en dan pas hoor ik de schijfkoppen hun ding doen, en krijg ik in de file manager de uitvoering van de aktie te zien.

Zijn er nog mensen die daar tegenaan lopen, en wat is de oplossing daarvoor ?
Ik heb via hdparm de spindown al eens uitgeschakeld, maar dat heeft geen effect.

theoretisch een vorm van caching zou helpen. Zeker het filesysteem gedeelte. In RAM of op SSD.

[pimlie]

@mbbs1024 Wat je beschrijft klinkt naar mijn idee toch echt als een disk die uit slaap stand moet komen. Ik zou dus nog een keer dubbelchecken dat je test met spindown uitgeschakeld correct was.

[dotcom87]

Is er eigenlijk ergens een soort van guide ivm kernel parameters om het verbruik te optimaliseren?

[mrmrmr]

dotcom87 schreef op zondag 25 januari 2026 @ 19:53:
Is er eigenlijk ergens een soort van guide ivm kernel parameters om het verbruik te optimaliseren?

https://wiki.archlinux.org/title/Hdparm

Let op dat sommige disks (o.a. bepaalde van Seagate) automatisch zelf de spindown regelen. Je kan dat zien in de meetcijfers van hardwareluxx.de in hun hard disk tests.

[dcm360]

mbbs1024 schreef op zondag 25 januari 2026 @ 16:18:
Zijn er nog mensen die daar tegenaan lopen, en wat is de oplossing daarvoor ?
Ik heb via hdparm de spindown al eens uitgeschakeld, maar dat heeft geen effect.

Al eens, is dat een tijdje geleden, of recent? Want dit is iets wat de schijf 'vergeet' bij een reboot, dus je zal het iedere boot op de gewenste waarde moeten (laten) instellen.

[Overspark]

GoBieN-Be schreef op zondag 25 januari 2026 @ 18:39:
[...]

Als je uitgaat van een mooie evenredige relatie tussen performantie en verbruik. Maar dat is niet zo, het is hier in dit topic al duidelijk gebleken dat het boosten naar hogere frequentie onevenredig hoger verbruik met zich meebrengt.

Dat is voor boosten zeker waar ja, maar we hebben het hier over een belasting die veel lager ligt. Bij boosten zit je boven de optimale kloksnelheid, maar je kunt er ook onder zitten. Mijn verhaal baseer ik op een praktijktest die ik jaren geleden heb gelezen maar helaas niet terug kan vinden. Daar vonden ze dus weldegelijk in totaal een hoger kWh verbruik bij een lager wattage van een T processor omdat hij langer op z'n maximale wattage bleef hangen.

[FireDrunk]

mkleinman schreef op zondag 25 januari 2026 @ 17:18:
Ik heb mijn Proxmox 3 node cluster volledig werkend, inclusief aparte netwerken voor storage, management, en sync.
Node 1 en 2 beide D 3642B met respectievelijk 128gb en 96gb ram, beide met een I9 9900T
Node 3 is een onbekend moederbord ( moet ik opzoeken ) 128gb ram en een i5 13500 CPU.

Distributed storage: In elke node zitten 2 1.92TB SSD's van Samsung (PM863A).

In alle machines zit een dual NIC X710 10Gbe netwerkkaart, naast een losse 1gbit NIC. 30 cores, 52 threads, 352Gb ram totaal.

Totaal nu 22 VM's en containers die er op draaien.

Inclusief beide switches en alle drie de nodes up and running doet deze gehele combinatie tussen de 70 en 80W!

Zelfs tijdens het actief moven van een lokale VM naar de Ceph storage pool komt verbruik niet boven de 120W uit!

Dit had ik niet verwacht!

Dat is een heel acceptabel verbruik! Ik zit met mijn 3 Kubernetes nodes op ~50W, maar heb iets minder performance en geheugen tot mijn beschikking

[Mars Warrior]

FireDrunk schreef op maandag 26 januari 2026 @ 10:47:
[...]
Dat is een heel acceptabel verbruik! Ik zit met mijn 3 Kubernetes nodes op ~50W, maar heb iets minder performance en geheugen tot mijn beschikking

Ik vermoed dat het ook wel uitmaakt of je oude hardware/CPU's gebruikt, of moderne die een stuk efficienter zijn en/of een aantal zaken op de E-cores kunnen laten draaien.

[FireDrunk]

Zeker, mijn cluster met Lenovo M710q's is ook alweer wat jaartjes oud. Die doosjes gebruiken 'maar' 12-17W, en geven redelijke performance. Zijn i9-9900T CPU's zijn veel sneller dan mijn i3 en i5-8500T.
Ook zijn ze een stukje efficienter.

Maar goed, tenzij hij iets host voor mensen, zal de load niet heel hoog zijn gok ik, dus per saldo blijf je het idle verbruik bijna als totaal verbruik houden.

[Mars Warrior]

FireDrunk schreef op maandag 26 januari 2026 @ 10:51:
Zeker, mijn cluster met Lenovo M710q's is ook alweer wat jaartjes oud. Die doosjes gebruiken 'maar' 12-17W, en geven redelijke performance. Zijn i9-9900T CPU's zijn veel sneller dan mijn i3 en i5-8500T.
Ook zijn ze een stukje efficienter.

Maar goed, tenzij hij iets host voor mensen, zal de load niet heel hoog zijn gok ik, dus per saldo blijf je het idle verbruik bijna als totaal verbruik houden.

Het idle verbruik dan van Kubernetes neem ik aan, wat niets te maken heeft met het daadwerkelijk idle zijn van de systemen. Die zijn gewoon continue "bezig", zeker als je het ook nog in je hoofd haalt om data te syncen die niet in een database zit...

Dat continue pollen en syncen zou ik lekker op een E-core zetten, dan ben je van heel wat pieken in verbruik af als het goed is.

[FireDrunk]

Op zich valt de load mee, maar Kubernetes is idd niet het meet idle vriendelijke stukje software.
Als kubernetes compleet gestopt is, daalt het verbruik van die nodes naar iets van 10-11W. Met Kubernetes en alle andere containers gestart is dat iets van 12-17W (verschilt een beetje per node).

Dat is best acceptabel in mijn ogen

[mkleinman]

FireDrunk schreef op maandag 26 januari 2026 @ 10:51:
Zeker, mijn cluster met Lenovo M710q's is ook alweer wat jaartjes oud. Die doosjes gebruiken 'maar' 12-17W, en geven redelijke performance. Zijn i9-9900T CPU's zijn veel sneller dan mijn i3 en i5-8500T.
Ook zijn ze een stukje efficienter.

Maar goed, tenzij hij iets host voor mensen, zal de load niet heel hoog zijn gok ik, dus per saldo blijf je het idle verbruik bijna als totaal verbruik houden.

Ik draai 22VM's en containers waaronder een Nextcloud instance, PiHole, een Oracle database waar mijn domotica op draait, Plex en nog een enkele VM die nog Windows 11 draait vanwege software die ik echt niet onder Linux ( wine ) kan draaien. En nog een reverseproxy, Grafana, DockerVM, UptimeKuma etc

En ik heb een aparte VM waar alle scripts op draaien die de diverse systemen pollen om er data uit te halen, om te inserten in mijn DB.


Maar toegegeven; de load op deze machine is niet heel hoog. Maar ondanks dat ben ik echt zwaar onder de indruk van dit lage verbruik. Ik wilde onder de 100W blijven maar dat doel heb ik ruim overtroffen.

[ Voor 9% gewijzigd door mkleinman op 26-01-2026 13:23 ]

[Jazco2nd]

Ik heb dit jaar afscheid genomen van selfhosting. Geïnitieerd door persoonlijke omstandigheden en uiteindelijk ook helemaal tevreden mee.

Onderdelen uitzoeken, daarvoor heb ik enorm veel tijd (teveel) in de voorgaande edities van dit topic besteed. En ook in andere fora. Uiteindelijk heeft dat tot een mooie server geleid. Volledig passief gekoeld met ruim voldoende uitbreidingsmogelijkheden (teveel, ik ging van 5 drives naar 3). En perfect op elkaar afgestelde onderdelen.

Alle delen afzonderlijk wegdoen lijkt me daarom doodzonde. Dit is mijn lijst:

#	Categorie	Product	Prijs	Subtotaal
1	Processors	Intel Core i3-9100 Boxed	€ 247,61	€ 247,61
1	Moederborden	Fujitsu D3644-B	€ 0,-	€ 0,-
1	Behuizingen	Streacom FC9 Fanless Zilver	€ 0,-	€ 0,-
1	Computer accessoires	Leicke ULL Power Supply 120 W	€ 39,99	€ 39,99
1	Voedingen	Mini-box picoPSU 90	€ 36,93	€ 36,93
1	Interne SSD's	Samsung 870 Evo (MZ-77E2T0B/EU) 2TB	€ 205,-	€ 205,-
1	Interne SSD's	Samsung 870 QVO 4TB	€ 433,-	€ 433,-
1	Interne SSD's	Samsung PM981a 512GB	€ 0,-	€ 0,-
1	Interne SSD's	Transcend SSD230S 4TB	€ 945,82	€ 945,82
Bekijk collectie Importeer producten			Totaal	€ 1.908,35

Zie ook: wenslijst: Homeserver te koop
Bij interesse geef maar een seintje. Ik maak graag een mede zuinige server obsessed tweaker blij (ik haalde 3.5W met alleen de M.2 SSD aangesloten).

[ Voor 61% gewijzigd door Jazco2nd op 26-01-2026 13:55 ]

[FireDrunk]

Damn, 3.5W is wel echt heul nice.

[Mars Warrior]

Mijn server is dit jaar zijn 3de levensjaar ingegaan

Sinds de vervanging van de 12700K met de 13900K zit ik nog steeds met het feit dat ik enkel ACPI_ statussen heb ipv de bekende C1 t/m C10. Ik heb nog geen oplossing kunnen vinden om de C1 t/m C10 terug te krijgen.

Verder ook last van gestaag toenemend verbruik. Van 16W met 50 containers naar 35W of meer.

Van het weekend daarm maar eens de server "down" gebracht en de BIOS nagelopen. Daar geen gekke dingen anders dan dat de Kontron R2.16 versie slechst 8 E-cores aangeeft van de 16 die de 13900K er heeft. R2.16 ondersteund de 12x, 13x en 14x CPU's, dus daar zou het niet aan moeten liggen.

Afijn: ik heb alles 2x op "Optimized Defaults" gezet en de server een 10 minuten van de stroom afgehad.

Feitelijk dus niks veranderd. Ik heb ook nog steeds de Intel Idle driver actief waarbij zichtbaar is dat deze max tot C10 kan komen.

En toen zag ik deze grafiek waarin ik Package Power Package weergeef. Daar zie je het paarse deel al een tijdje gestaag toenemen, en plotseling zwaar afnemen en behoorlijk horizontaal verdergaan... WTF

Ik heb geen Zigbee/Wifi verbruiksmeter op de server zitten, enkel een gewone meter, en die is spontaan van 35-45W naar 15-25W gegaan. Ik ben zomaar 20W kwijtgeraakt



Beetje inzoomen op de laatste 30 dagen geeft hetzelfde beeld: een plotselinge daling, en ook veel minder pieken en blokken van hoger verbruik. De 6W package power is rond de 16-23W uit het stopcontact.



En die van de laatste 7 dagen laat hetzelfde beeld zien. Package power is gedaald van soms boven de 15W naar weer onder de 4W...



Heel raar allemaal. Geen idee waardoor dit nu is gekomen. Ik draai nog steeds dezelfde containers en gebruik nog steeds Ubuntu 22.04 LTS. En dus nog steeds zie ik ACPI states in powertop.

Maar het verbruik is wel flink gedaald. Lijkt er dan toch op dat die reset van de BIOS en het wat langer van de stroom afhalen flink wat heeft gedaan met het overall verbruik van de server.

[mrmrmr]

@Mars Warrior Heb je powertop gecompileerd vanaf de broncode op github? Dat kan het cosmetische ACPI C state probleem in powertop verhelpen.

https://github.com/fenrus75/powertop

Ik heb hem laatst nog gecompileerd. Als je wil kan ik die via een bestanddeelsite delen.

[Mars Warrior]

mrmrmr schreef op maandag 26 januari 2026 @ 16:30:
@Mars Warrior Heb je powertop gecompileerd vanaf de broncode op github? Dat kan het cosmetische ACPI C state probleem in powertop verhelpen.

https://github.com/fenrus75/powertop

Ik heb hem laatst nog gecompileerd. Als je wil kan ik die via een bestanddeelsite delen.

Ik gebruik nog 2.14 die bij Ubuntu wordt geleverd. Een test met een losse binary met versie 2.15 zou wel mooi zijn, dan kan ik zien of dat het probleem is op dit ogenblik.

[FireDrunk]

Je kan hem in Docker draaien, handig als je niet wil compilen.

[Jerie]

Mars Warrior schreef op maandag 26 januari 2026 @ 17:13:
[...]

Ik gebruik nog 2.14 die bij Ubuntu wordt geleverd. Een test met een losse binary met versie 2.15 zou wel mooi zijn, dan kan ik zien of dat het probleem is op dit ogenblik.

Ubuntu? Die levert 2.15:

code:

$  powertop --version
PowerTOP version 2.15
$ lsb_release -ir
[...]
Distributor ID: Ubuntu
Release:        24.04

De vorige LTS versie (22.04) inderdaad niet:

PowerTOP v2.15 Latest
on Sep 29, 2022

maar die vorige Ubuntu LTS wordt wel ongeveer irrelevant, gezien over enkele maanden 26.04 LTS uit gaat komen.

Ook Trixie (Debian 13, waar Proxmox 9.x op gebaseerd is) zit op 2.15. Proxmox 8.x is gebaseerd op Bookworm (Debian 12), die zit op 2.14.

In Docker draaien lijkt me eenvoudig. Voorbeeld Dockerfile: https://github.com/benjs/...cker/blob/main/Dockerfile en even bullseye vervangen met trixie.

[Mars Warrior]

Jerie schreef op dinsdag 27 januari 2026 @ 16:44:
[...]
Ubuntu? Die levert 2.15:

code:

$  powertop --version
PowerTOP version 2.15
$ lsb_release -ir
[...]
Distributor ID: Ubuntu
Release:        24.04

De vorige LTS versie (22.04) inderdaad niet:
[...]
maar die vorige Ubuntu LTS wordt wel ongeveer irrelevant, gezien over enkele maanden 26.04 LTS uit gaat komen.

Ik loop nog wat achter, en doe sowieso geen .0 releases. Ook Ubuntu gaat volgens mij pas melden dat er een nieuwe distro is (dist-upgrade) bij de .1 release.

Ik ben altijd wat huiverig om zomaar een dist-upgrade te doen. Is ooit misgegaan namelijk waarbij incompatible libraries werden verwijderd, die vervolgens bij een automatische migratie tijdens de upgrade weer nodig waren. Een kip-ei probleem dus met alle gevolgen van dien.

Ook Trixie (Debian 13, waar Proxmox 9.x op gebaseerd is) zit op 2.15. Proxmox 8.x is gebaseerd op Bookworm (Debian 12), die zit op 2.14.

In Docker draaien lijkt me eenvoudig. Voorbeeld Dockerfile: https://github.com/benjs/...cker/blob/main/Dockerfile en even bullseye vervangen met trixie.

Ga ik proberen. Ff een dockerfile gebruiken is geen probleem voor mij.

[Mars Warrior]

Hmm. Docker container gebouwd. Voor zowel Trixie als Ubuntu 24.04.

Container geeft inderdaad Powertop 2.15.

Ik zie nu wel Pkg waardes, maar allemaal op 0%.



Lijkt erop dat het met de iGPU te maken heeft, of althans dat denk ik dan. Die blijft namelijk in status D0 hangen en gaat niet naar D3.

Bash:

cat /sys/kernel/debug/dri/128/i915_runtime_pm_status
  Runtime power status: enabled
  GPU idle: yes 
  IRQs disabled: no Usage count: 0 
  PCI device power state: D0 [0]

Maar daar houdt mijn kennis even op qua Linux en hoe ik dit zou moeten/kunnen fixen...

[shadylog]

Mars Warrior schreef op dinsdag 27 januari 2026 @ 17:39:
Hmm. Docker container gebouwd. Voor zowel Trixie als Ubuntu 24.04.

Container geeft inderdaad Powertop 2.15.

Ik zie nu wel Pkg waardes, maar allemaal op 0%.

[Afbeelding]

Lijkt erop dat het met de iGPU te maken heeft, of althans dat denk ik dan. Die blijft namelijk in status D0 hangen en gaat niet naar D3.

Bash:

cat /sys/kernel/debug/dri/128/i915_runtime_pm_status
  Runtime power status: enabled
  GPU idle: yes 
  IRQs disabled: no Usage count: 0 
  PCI device power state: D0 [0]

Maar daar houdt mijn kennis even op qua Linux en hoe ik dit zou moeten/kunnen fixen...

Ik merkte dat met powertop 0% betekent dat ze dus 0% in een C-state zitten dus druk.
Als je alle containers uitzet zou je toch daar wat percentages moeten gaan zien.

[ Voor 4% gewijzigd door shadylog op 27-01-2026 17:46 ]

[Mars Warrior]

shadylog schreef op dinsdag 27 januari 2026 @ 17:46:
[...]
Ik merkte dat met powertop 0% betekent dat ze dus 0% in een C-state zitten dus druk.
Als je alle containers uitzet zou je toch daar wat percentages moeten gaan zien.

Je ziet dat de CPU's enzo wel dieper komen. Wat ik nu begrijp is dat als de iGPU niet in slaap gaat, je dus overal 0% ziet staan. Alleen dat weet ik niet zeker.

Hele probleem is dus ontstaan na vervanging 12700K met 13900K, en dus (vziw) een andere iGPU.

[ Voor 9% gewijzigd door Mars Warrior op 27-01-2026 17:48 ]

[Jerie]

Mars Warrior schreef op dinsdag 27 januari 2026 @ 17:47:
[...]

Je ziet dat de CPU's enzo wel dieper komen. Wat ik nu begrijp is dat als de iGPU niet in slaap gaat, je dus overal 0% ziet staan. Alleen dat weet ik niet zeker.

Hele probleem is dus ontstaan na vervanging 12700K met 13900K, en dus (vziw) een andere iGPU.

Gebruik je de i915 driver of de xe driver? Want enkel de Meteor Lake en Lunar Lake ondersteunen de xe driver niet.

[shadylog]

Mars Warrior schreef op dinsdag 27 januari 2026 @ 17:47:
[...]

Je ziet dat de CPU's enzo wel dieper komen. Wat ik nu begrijp is dat als de iGPU niet in slaap gaat, je dus overal 0% ziet staan. Alleen dat weet ik niet zeker.

Hele probleem is dus ontstaan na vervanging 12700K met 13900K, en dus (vziw) een andere iGPU.

Bij mij nu met alles draaiend (frigate enz) ook GPU actief:

code:

Pkg(HW)  |            Core(HW) |            CPU(OS) 0   CPU(OS) 1
                    |                     | C0 active   1.3%        0.1%
                    |                     | POLL        0.0%    0.0 ms  0.0%    0.0 ms
                    |                     | C1_ACPI     5.7%    0.2 ms  0.2%    0.2 ms
C2 (pc2)    0.2%    |                     | C2_ACPI    27.3%    0.5 ms  0.3%    0.5 ms
C3 (pc3)    0.2%    | C3 (cc3)    0.0%    | C3_ACPI    63.6%    4.8 ms 99.4%   36.0 ms
C6 (pc6)    0.0%    | C6 (cc6)    1.3%    |
C7 (pc7)    0.0%    | C7 (cc7)   59.1%    |
C8 (pc8)    0.0%    |                     |
C9 (pc9)    0.0%    |                     |
C10 (pc10)  0.0%    |                     |

                    |            Core(HW) |            CPU(OS) 2   CPU(OS) 3
                    |                     | C0 active   0.0%        0.0%
                    |                     | POLL        0.0%    0.0 ms  0.0%    0.0 ms
                    |                     | C1_ACPI     0.0%    0.0 ms  0.0%    0.0 ms
                    |                     | C2_ACPI     0.0%    0.0 ms  0.0%    0.0 ms
                    | C3 (cc3)    0.0%    | C3_ACPI   100.0%   39.0 ms100.1%   63.4 ms
                    | C6 (cc6)    0.0%    |
                    | C7 (cc7)   97.3%    |
                    |                     |
                    |                     |
                    |                     |

                    |            Core(HW) |            CPU(OS) 4   CPU(OS) 5
                    |                     | C0 active   0.3%        0.0%
                    |                     | POLL        0.0%    0.0 ms  0.0%    0.0 ms
                    |                     | C1_ACPI     0.3%    0.4 ms  0.0%    0.0 ms
                    |                     | C2_ACPI     1.5%    0.9 ms  0.0%    0.0 ms
                    | C3 (cc3)    0.0%    | C3_ACPI    97.5%    5.9 ms100.1%   92.3 ms
                    | C6 (cc6)    1.4%    |
                    | C7 (cc7)   91.2%    |
                    |                     |
                    |                     |
                    |                     |

                    |            Core(HW) |            CPU(OS) 6   CPU(OS) 7
                    |                     | C0 active   0.1%        0.0%
                    |                     | POLL        0.0%    0.0 ms  0.0%    0.0 ms
                    |                     | C1_ACPI     0.1%    0.1 ms  0.0%    0.2 ms
                    |                     | C2_ACPI     1.6%    0.6 ms  0.1%    0.5 ms
                    | C3 (cc3)    0.0%    | C3_ACPI    98.1%   20.7 ms100.0%   84.6 ms
                    | C6 (cc6)    1.4%    |
                    | C7 (cc7)   95.5%    |
                    |                     |
                    |                     |

GPU in powertop:

code:

|             GPU     |
                    |                     |
                    | Powered On 31.3%    |
                    | RC6        68.7%    |
                    | RC6p        0.0%    |
                    | RC6pp       0.0%    |
                    |                     |

[Mars Warrior]

Jerie schreef op dinsdag 27 januari 2026 @ 17:51:
[...]
Gebruik je de i915 driver of de xe driver? Want enkel de Meteor Lake en Lunar Lake ondersteunen de xe driver niet.

Geen idee eigenlijk. Neem aan de i915 driver:

Bash:

cat /sys/kernel/debug/dri/*/name
i915 dev=0000:00:02.0 unique=0000:00:02.0
i915 dev=0000:00:02.0 unique=0000:00:02.0
i915 dev=0000:00:02.0 unique=0000:00:02.0

Bash:

basename $(readlink /sys/class/drm/card1/device/driver)
i915

[mbbs1024]

pimlie schreef op zondag 25 januari 2026 @ 19:25:
@mbbs1024 Wat je beschrijft klinkt naar mijn idee toch echt als een disk die uit slaap stand moet komen. Ik zou dus nog een keer dubbelchecken dat je test met spindown uitgeschakeld correct was.

Ik heb verschillende malen het hdparm commando uitgevoerd, maar de disk lijkt er niet echt op te reageren, en vertoont dit gedrag al na een paar seconden inactiviteit,
Gewoon even een commando tikken in de terminal, of in file manager even naar de juiste directory kijken, is al genoeg om die blokkering te hebben.

[Mars Warrior]

Nog even terugkomend op het verbruik van mijn server.

Sinds die BIOS reset is het verbruik blijvend lager, maar ook de impact van de CPU belasting is vele malen kleiner. Voorheen schoot het aantal Watts uit het stopcontact dus flink omhoog van bijv 2 naar 6% CPU belasting, maar nu niet of nauwelijks meer: het schommelt tussen de 16 en 20W.

Dus ook het uitzetten/pauzeren van bijv Crashplan (traag pakket neemt vaak 100% van een E-core, dus ca 3% CPU extra) geeft geen schokkend verschil: het minimale verbruik schommelt dan rond de 16-17W: zo ongeveer dus het verschil dat een enkele E-core neemt bij volle belasting.

Het lijkt er dus op dat (mogelijk) doordat de iGPU niet in slaap gaat, dat ik met een behoorlijke minimaal aantal Watts uit het stopcontact zit.
.

Bash:

lspci -k | grep -EA3 'VGA|3D|Display'
00:02.0 VGA compatible controller: Intel Corporation Device a780 (rev 04)
        DeviceName: Onboard - Video
        Subsystem: Intel Corporation Device 2212
        Kernel driver in use: i915

.

Op internet kan ik geen oplossing vinden, en ChatGPT vind dat ik de iGPU maar helemaal in de BIOS moet uitzetten, maar dat gaat natuurlijk niet gebeuren...

Verder krijg ik deze getallen. Power control op "auto", usage op "0", dus niet gebruikt, maar status op "unsupported". Gaat lekker zo...

Bash:

cat /sys/devices/i915/power/control
cat /sys/devices/i915/power/runtime_status
cat /sys/devices/i915/power/runtime_usage
auto
unsupported
0

[ Voor 23% gewijzigd door Mars Warrior op 28-01-2026 12:41 ]

[Perzikvrucht]

Inmiddles heb ik een Elitedesk G4 800 draaiden met een i5 8500, 16GB RAM, 2x NVME SSD's en 1x een 3,5" WD Red Plus 4TB HDD (EFZX). Ook ik wil natuurlijk een zo zuinig mogelijke server. Ik heb powertop --auto-tune gedraaid. Dit zijn nu de c-states:



Ik draai:
- Home assistent OS (VM)
- Docker (VM) met arr stack
- Paperless (LXC)
- NextcloudPi (LXC)
- Immich (LXC)

Het vebruik nu in idle is 18W, gemeten met een Ikea Inspelning,

Waar ik tegenaan loop:
- Ik krijg hdparm niet volledig werkend: hdparm -S 241 -B 127 /dev/sda. Het eerste deel wel uitgevoerd worden (spindown) maar APM niet. Ook heb ik hdidle geprobeerd na een tip hier (https://withblue.ink/2016...-to-build-a-home-nas.html) maar ik heb niet het idee dat het wat met het verbruik heeft gedaan. Andere tips?
- Zijn deze c-states een beetje passend bij een zuinige server? Kan ik meer bereiken?

[Mars Warrior]

Nog een poging om het waarom te achterhalen.

Blijkbaar heeft de iGPU een framebuffer in gebruik op de resolutie van mijn monitor (3840x1600), ondanks dat er geen Displlay Port kabel ergens in zit.

Wat ik begrijp van het internet is dat de iGPU dan "actief" is, en dus niet naar suspend/sleep kan gaan.

Tot zover mijn Linux kennis, want ik kan nergens een oplossing vinden

Bash:

sudo lshw -C display
  *-display
       description: VGA compatible controller
       product: Intel Corporation
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       logical name: /dev/fb0
       version: 04
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=i915 latency=0 mode=3840x1600 resolution=3840,1600 visual=truecolor xres=3840 yres=1600
       resources: iomemory:600-5ff iomemory:400-3ff irq:143 memory:6000000000-6000ffffff memory:4000000000-400fffffff ioport:3000(size=64) memory:c0000-dffff memory:4010000000-4016ffffff memory:4020000000-40ffffffff

Op andere plekken kom ik namelijk dit tegen, die dus wel in slaap kan gaan:

Bash:

$ lspci -k | grep -EA3 'VGA|3D|Display'
01:00.0 VGA compatible controller: Intel Corporation DG2 [Arc A380] (rev 05)
        Subsystem: ASRock Incorporation DG2 [Arc A380]
        Kernel driver in use: i915
        Kernel modules: i915, xe

$ sudo lshw -C display
  *-display                 
       description: VGA compatible controller
       product: DG2 [Arc A380]
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       version: 05
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: iomemory:38380-3837f irq:42 memory:fb000000-fbffffff memory:383800000000-38380fffffff memory:c0000-dffff

[FireDrunk]

Mars Warrior schreef op woensdag 28 januari 2026 @ 15:58:
Nog een poging om het waarom te achterhalen.

Blijkbaar heeft de iGPU een framebuffer in gebruik op de resolutie van mijn monitor (3840x1600), ondanks dat er geen Displlay Port kabel ergens in zit.

Wat ik begrijp van het internet is dat de iGPU dan "actief" is, en dus niet naar suspend/sleep kan gaan.

Tot zover mijn Linux kennis, want ik kan nergens een oplossing vinden

Bash:

sudo lshw -C display
  *-display
       description: VGA compatible controller
       product: Intel Corporation
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       logical name: /dev/fb0
       version: 04
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=i915 latency=0 mode=3840x1600 resolution=3840,1600 visual=truecolor xres=3840 yres=1600
       resources: iomemory:600-5ff iomemory:400-3ff irq:143 memory:6000000000-6000ffffff memory:4000000000-400fffffff ioport:3000(size=64) memory:c0000-dffff memory:4010000000-4016ffffff memory:4020000000-40ffffffff

Op andere plekken kom ik namelijk dit tegen, die dus wel in slaap kan gaan:

Bash:

$ lspci -k | grep -EA3 'VGA|3D|Display'
01:00.0 VGA compatible controller: Intel Corporation DG2 [Arc A380] (rev 05)
        Subsystem: ASRock Incorporation DG2 [Arc A380]
        Kernel driver in use: i915
        Kernel modules: i915, xe

$ sudo lshw -C display
  *-display                 
       description: VGA compatible controller
       product: DG2 [Arc A380]
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       version: 05
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: iomemory:38380-3837f irq:42 memory:fb000000-fbffffff memory:383800000000-38380fffffff memory:c0000-dffff

Ik gebruik consoleblank=60 als extra boot argument, mogelijk helpt dat voor de sleep state van je iGPU?

[Mars Warrior]

FireDrunk schreef op woensdag 28 januari 2026 @ 16:04:
[...]
Ik gebruik consoleblank=60 als extra boot argument, mogelijk helpt dat voor de sleep state van je iGPU?

Kan ik eens proberen. Nog nooit nodig gehad namelijk. Scherm (ik gebruik Ubuntu 22.04 LTS desktop) ging blijkbaar al automatisch uit altijd...

Ik zie nu in ieder geval dat consoleblank op 0 staat, dus...

Helaas alleen readonly, dus niet runtime te wijzigen

[ Voor 14% gewijzigd door Mars Warrior op 28-01-2026 16:24 ]

[Mich]

@Mars Warrior Ik kwam ooit dit commando nog tegen. Die meet gedurende 60 seconden hoeveel tijd je GPU in C6 state actief is:

code:

perf stat -a -x, -r 1 -e "power/energy-pkg/" -e "power/energy-cores/" -e "power/energy-gpu/" -e "i915/actual-frequency/" -e "i915/rc6-residency/" -e "i915/rcs0-busy/" -e "i915/bcs0-busy/" -e "i915/vcs0-busy/" sleep 60

Bij mij is dit de uitkomst:

code:

143.92,Joules,power/energy-pkg/,59997926158,100.00,,
67.93,Joules,power/energy-cores/,59997929252,100.00,,
0.00,Joules,power/energy-gpu/,59997930252,100.00,,
0,M,i915/actual-frequency/,59997937591,100.00,,
59997941186,ns,i915/rc6-residency/,59997938820,100.00,,
0,ns,i915/rcs0-busy/,59997939841,100.00,,
0,ns,i915/bcs0-busy/,59997942298,100.00,,
0,ns,i915/vcs0-busy/,59997943329,100.00,,

Mijn iGPU zit ook in D0 terwijl hij totaal niet actief is (59997941186 nanoseconds is 59,99 sec)

ps. Waarom heb je niet gelijk je bios ge-update naar de laatse versie?


edit: Het lijkt erop dat mijn i915 ook ook in D3 kan:

code:

PU idle: yes
IRQs disabled: yes
Usage count: 0
PCI device power state: D3hot [3]

code:

GPU idle: yes
IRQs disabled: no
Usage count: 0
PCI device power state: D0 [0]

zieo ok het verschil met de IRQs

[ Voor 15% gewijzigd door Mich op 29-01-2026 09:59 ]

[shadylog]

Mars Warrior schreef op woensdag 28 januari 2026 @ 16:12:
[...]

Kan ik eens proberen. Nog nooit nodig gehad namelijk. Scherm (ik gebruik Ubuntu 22.04 LTS desktop) ging blijkbaar al automatisch uit altijd...

Ik zie nu in ieder geval dat consoleblank op 0 staat, dus...

Helaas alleen readonly, dus niet runtime te wijzigen

Als je van CPU wisselt kan je mobo je settings veranderen (CMOS reset).

Inderdaad als je framebuffer actief is en op 4k is er iets in je boot-proces die graphics heeft gestart. Heb je een login-manager oid ?

Het kan geen kwaad om in grub GuC te forceren gezien je een oude ubuntu hebt

code:

i915.enable_guc=2

Wat zegt:

code:

grep "^connected" /sys/class/drm/card0-*/status

[Mars Warrior]

Ik kom per saldo als ik alles stop ca 5W hoger uit in idle dan eerder met de 12700K. Volgens mij volledig te wijten aan de iGPU die niet in sleep komt.

Mich schreef op donderdag 29 januari 2026 @ 08:48:
@Mars Warrior Ik kwam ooit dit commando nog tegen. Die meet gedurende 60 seconden hoeveel tijd je GPU in C6 state actief is:

code:

perf stat -a -x, -r 1 -e "power/energy-pkg/" -e "power/energy-cores/" -e "power/energy-gpu/" -e "i915/actual-frequency/" -e "i915/rc6-residency/" -e "i915/rcs0-busy/" -e "i915/bcs0-busy/" -e "i915/vcs0-busy/" sleep 60

Bij mij is dit de uitkomst:

code:

143.92,Joules,power/energy-pkg/,59997926158,100.00,,
67.93,Joules,power/energy-cores/,59997929252,100.00,,
0.00,Joules,power/energy-gpu/,59997930252,100.00,,
0,M,i915/actual-frequency/,59997937591,100.00,,
59997941186,ns,i915/rc6-residency/,59997938820,100.00,,
0,ns,i915/rcs0-busy/,59997939841,100.00,,
0,ns,i915/bcs0-busy/,59997942298,100.00,,
0,ns,i915/vcs0-busy/,59997943329,100.00,,

Mijn iGPU zit ook in D0 terwijl hij totaal niet actief is (59997941186 nanoseconds is 59,99 sec)

Commando geeft bij mij enkel foutmeldingen. Blijkbaar bestaan al die mappen/velden bij mij niet.

Bash:

cat /sys/devices/i915/power/runtime_status
unsupported
zoef@domiducus:~$ perf stat -a -x, -r 1 -e "power/energy-pkg/" -e "power/energy-cores/" -e "power/energy-gpu/" -e "i915/actual-frequency/" -e "i915/rc6-residency/" -e "i915/rcs0-busy/" -e "i915/bcs0-busy/" -e "i915/vcs0-busy/" sleep 60
event syntax error: 'power/energy-gpu/'
                           \___ Bad event or PMU

Unable to find PMU or event on a PMU of 'power'

Initial error:
event syntax error: 'power/energy-gpu/'
                           \___ unknown term 'energy-gpu' for pmu 'power'

ps. Waarom heb je niet gelijk je bios ge-update naar de laatse versie?

Ik zag nog ff het nut niet om dat te proberen omdat R2.16 alles van 12 t/m 14gen moet ondersteunen.

edit: Het lijkt erop dat mijn i915 ook ook in D3 kan:

code:

PU idle: yes
IRQs disabled: yes
Usage count: 0
PCI device power state: D3hot [3]

code:

GPU idle: yes
IRQs disabled: no
Usage count: 0
PCI device power state: D0 [0]

zieo ok het verschil met de IRQs

Bij mij geeft dit dus het laatste:

Bash:

sudo cat /sys/kernel/debug/dri/128/i915_runtime_pm_status
Runtime power status: enabled
GPU idle: yes
IRQs disabled: no
Usage count: 0
PCI device power state: D0 [0]

Maar ook de volgende commando's laten zien dat er iets misgaat met power en/of drivers:
runtime_enabled staat dus op disabled, en runtime_status op unsupported. Dus geen wonder dat power saving van geen kant werkt...

Bash:

ls /sys/devices/i915/power/runtime*
/sys/devices/i915/power/runtime_active_kids
/sys/devices/i915/power/runtime_active_time
/sys/devices/i915/power/runtime_enabled
/sys/devices/i915/power/runtime_status
/sys/devices/i915/power/runtime_suspended_time
/sys/devices/i915/power/runtime_usage

cat /sys/devices/i915/power/runtime*
0
0
disabled
unsupported
0
0

shadylog schreef op donderdag 29 januari 2026 @ 09:24:
[...]
Het kan geen kwaad om in grub GuC te forceren gezien je een oude ubuntu hebt

code:

i915.enable_guc=2

Alles lijkt nu op "auto" te staan:

Bash:

sudo cat /sys/module/i915/parameters/enable_guc
-1

Wat zegt:

code:

grep "^connected" /sys/class/drm/card0-*/status

Ik heb geen card0, maar enkel card1 en dat geeft de volgende output:

Bash:

ls /sys/class/drm/card1-**/status
/sys/class/drm/card1-DP-1/status  /sys/class/drm/card1-HDMI-A-1/status
/sys/class/drm/card1-DP-2/status  /sys/class/drm/card1-HDMI-A-2/status
/sys/class/drm/card1-DP-3/status  /sys/class/drm/card1-HDMI-A-3/status
/sys/class/drm/card1-DP-4/status  /sys/class/drm/card1-HDMI-A-4/status
/sys/class/drm/card1-DP-5/status

cat /sys/class/drm/card1-**/status
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected

Ik zie wel dit. Betekent die - erachter dat er geen support is voor sleep states?:

Bash:

sudo lspci -vv -s 00:02.0

        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

[spoor12b]

FireDrunk schreef op dinsdag 27 januari 2026 @ 15:26:
Je kan hem in Docker draaien, handig als je niet wil compilen.

@FireDrunk Een tijdje geleden heb ik dat ook geprobeerd maar ik heb vast iets niet goed gedaan. Graag zou ik willen weten wat het juiste commando is (OMV/Debian 13).

[shadylog]

Mars Warrior schreef op donderdag 29 januari 2026 @ 10:48:
Ik kom per saldo als ik alles stop ca 5W hoger uit in idle dan eerder met de 12700K. Volgens mij volledig te wijten aan de iGPU die niet in sleep komt.


[...]

Commando geeft bij mij enkel foutmeldingen. Blijkbaar bestaan al die mappen/velden bij mij niet.

Bash:

cat /sys/devices/i915/power/runtime_status
unsupported
zoef@domiducus:~$ perf stat -a -x, -r 1 -e "power/energy-pkg/" -e "power/energy-cores/" -e "power/energy-gpu/" -e "i915/actual-frequency/" -e "i915/rc6-residency/" -e "i915/rcs0-busy/" -e "i915/bcs0-busy/" -e "i915/vcs0-busy/" sleep 60
event syntax error: 'power/energy-gpu/'
                           \___ Bad event or PMU

Unable to find PMU or event on a PMU of 'power'

Initial error:
event syntax error: 'power/energy-gpu/'
                           \___ unknown term 'energy-gpu' for pmu 'power'

[...]

Ik zag nog ff het nut niet om dat te proberen omdat R2.16 alles van 12 t/m 14gen moet ondersteunen.

[...]

Bij mij geeft dit dus het laatste:

Bash:

sudo cat /sys/kernel/debug/dri/128/i915_runtime_pm_status
Runtime power status: enabled
GPU idle: yes
IRQs disabled: no
Usage count: 0
PCI device power state: D0 [0]

Maar ook de volgende commando's laten zien dat er iets misgaat met power en/of drivers:
runtime_enabled staat dus op disabled, en runtime_status op unsupported. Dus geen wonder dat power saving van geen kant werkt...

Bash:

ls /sys/devices/i915/power/runtime*
/sys/devices/i915/power/runtime_active_kids
/sys/devices/i915/power/runtime_active_time
/sys/devices/i915/power/runtime_enabled
/sys/devices/i915/power/runtime_status
/sys/devices/i915/power/runtime_suspended_time
/sys/devices/i915/power/runtime_usage

cat /sys/devices/i915/power/runtime*
0
0
disabled
unsupported
0
0

[...]

Alles lijkt nu op "auto" te staan:

Bash:

sudo cat /sys/module/i915/parameters/enable_guc
-1

[...]

Ik heb geen card0, maar enkel card1 en dat geeft de volgende output:

Bash:

ls /sys/class/drm/card1-**/status
/sys/class/drm/card1-DP-1/status  /sys/class/drm/card1-HDMI-A-1/status
/sys/class/drm/card1-DP-2/status  /sys/class/drm/card1-HDMI-A-2/status
/sys/class/drm/card1-DP-3/status  /sys/class/drm/card1-HDMI-A-3/status
/sys/class/drm/card1-DP-4/status  /sys/class/drm/card1-HDMI-A-4/status
/sys/class/drm/card1-DP-5/status

cat /sys/class/drm/card1-**/status
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected

Ik zie wel dit. Betekent die - erachter dat er geen support is voor sleep states?:

Bash:

sudo lspci -vv -s 00:02.0

        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

Zet guc op 2 zou kunnen dat dit alles voor je oplost.

[shadylog]

Mars Warrior schreef op donderdag 29 januari 2026 @ 10:48:
Ik kom per saldo als ik alles stop ca 5W hoger uit in idle dan eerder met de 12700K. Volgens mij volledig te wijten aan de iGPU die niet in sleep komt.


[...]

Commando geeft bij mij enkel foutmeldingen. Blijkbaar bestaan al die mappen/velden bij mij niet.

Bash:

cat /sys/devices/i915/power/runtime_status
unsupported
zoef@domiducus:~$ perf stat -a -x, -r 1 -e "power/energy-pkg/" -e "power/energy-cores/" -e "power/energy-gpu/" -e "i915/actual-frequency/" -e "i915/rc6-residency/" -e "i915/rcs0-busy/" -e "i915/bcs0-busy/" -e "i915/vcs0-busy/" sleep 60
event syntax error: 'power/energy-gpu/'
                           \___ Bad event or PMU

Unable to find PMU or event on a PMU of 'power'

Initial error:
event syntax error: 'power/energy-gpu/'
                           \___ unknown term 'energy-gpu' for pmu 'power'

[...]

Ik zag nog ff het nut niet om dat te proberen omdat R2.16 alles van 12 t/m 14gen moet ondersteunen.

[...]

Bij mij geeft dit dus het laatste:

Bash:

sudo cat /sys/kernel/debug/dri/128/i915_runtime_pm_status
Runtime power status: enabled
GPU idle: yes
IRQs disabled: no
Usage count: 0
PCI device power state: D0 [0]

Maar ook de volgende commando's laten zien dat er iets misgaat met power en/of drivers:
runtime_enabled staat dus op disabled, en runtime_status op unsupported. Dus geen wonder dat power saving van geen kant werkt...

Bash:

ls /sys/devices/i915/power/runtime*
/sys/devices/i915/power/runtime_active_kids
/sys/devices/i915/power/runtime_active_time
/sys/devices/i915/power/runtime_enabled
/sys/devices/i915/power/runtime_status
/sys/devices/i915/power/runtime_suspended_time
/sys/devices/i915/power/runtime_usage

cat /sys/devices/i915/power/runtime*
0
0
disabled
unsupported
0
0

[...]

Alles lijkt nu op "auto" te staan:

Bash:

sudo cat /sys/module/i915/parameters/enable_guc
-1

[...]

Ik heb geen card0, maar enkel card1 en dat geeft de volgende output:

Bash:

ls /sys/class/drm/card1-**/status
/sys/class/drm/card1-DP-1/status  /sys/class/drm/card1-HDMI-A-1/status
/sys/class/drm/card1-DP-2/status  /sys/class/drm/card1-HDMI-A-2/status
/sys/class/drm/card1-DP-3/status  /sys/class/drm/card1-HDMI-A-3/status
/sys/class/drm/card1-DP-4/status  /sys/class/drm/card1-HDMI-A-4/status
/sys/class/drm/card1-DP-5/status

cat /sys/class/drm/card1-**/status
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected
disconnected

Ik zie wel dit. Betekent die - erachter dat er geen support is voor sleep states?:

Bash:

sudo lspci -vv -s 00:02.0

        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

Maaruh je vga staat nu toch op D3?

Nog even getest hier met frigate.. Frigate uit staat die op D3 bij mij en frigate aan krijg ik bij mij:

code:

Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

[Raynman]

Mars Warrior schreef op donderdag 29 januari 2026 @ 10:48:
Commando geeft bij mij enkel foutmeldingen. Blijkbaar bestaan al die mappen/velden bij mij niet.

In tegenstelling tot andere commando's gebruik je daar geen sudo? Lijkt wel te moeten: https://wiki.archlinux.or...nable_performance_support

[Mars Warrior]

shadylog schreef op donderdag 29 januari 2026 @ 12:24:
[...]
Maaruh je vga staat nu toch op D3?

Volgens mij zijn het capabilities. Dus JA het kan, maar als het niet door de driver gebruikt wordt, dan heb je nog geen resultaat. En aangezien veel dingen op "unsupported" staan, lijkt het daar ergens te zitten. Maar wie weet doet GUC iets...

shadylog schreef op donderdag 29 januari 2026 @ 12:20:
[...]
[...]
Zet guc op 2 zou kunnen dat dit alles voor je oplost.

Ga ik proberen!

Raynman schreef op donderdag 29 januari 2026 @ 12:32:
[...]

In tegenstelling tot andere commando's gebruik je daar geen sudo? Lijkt wel te moeten: https://wiki.archlinux.or...nable_performance_support

Kijk ik nog ff na. Soms wel, soms niet...

[FireDrunk]

spoor12b schreef op donderdag 29 januari 2026 @ 12:06:
[...]

@FireDrunk Een tijdje geleden heb ik dat ook geprobeerd maar ik heb vast iets niet goed gedaan. Graag zou ik willen weten wat het juiste commando is (OMV/Debian 13).

FireDrunk in "Het grote zuinige server topic - deel 3"

[Mars Warrior]

Update. GUC=2 en consoleblank=10 maken niks uit in het verbruik.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_guc=2 consoleblank=10"

De volgende parameters staan ook nog steeds hetzelfde...

Bash:

cat /sys/devices/i915/power/runtime_enabled
cat /sys/devices/i915/power/runtime_status
disabled
unsupported

[GoBieN-Be]

Ook niet vergeten update-grub te doen na aanpassen veronderstel ik?

[Mars Warrior]

GoBieN-Be schreef op donderdag 29 januari 2026 @ 19:06:
Ook niet vergeten update-grub te doen na aanpassen veronderstel ik?

Dat ben ik inderdaad niet vergeten 😇

Het lost het feit dat er een frame buffer draait niet op. Dus iGPU blijft actief.

Kan nog testen om de iGPU te disablen in de BIOS of Grub. Als dat werkt weet ik in ieder geval dat het kan. Alleen dan zal de desktop het niet meer doen.

[Jerie]

Mars Warrior schreef op donderdag 29 januari 2026 @ 17:39:
Update. GUC=2 en consoleblank=10 maken niks uit in het verbruik.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_guc=2 consoleblank=10"

De volgende parameters staan ook nog steeds hetzelfde...

Bash:

cat /sys/devices/i915/power/runtime_enabled
cat /sys/devices/i915/power/runtime_status
disabled
unsupported

Je kernel boot argumenten staan in /proc/cmdline

Heeft je server IPMI? Gebruik je op enige manier GPU passthrough? Remote UI (X/WL/RDP)?

[Mars Warrior]

Jerie schreef op donderdag 29 januari 2026 @ 19:40:
[...]
Je kernel boot argumenten staan in /proc/cmdline

Heeft je server IPMI? Gebruik je op enige manier GPU passthrough? Remote UI (X/WL/RDP)?

De command line ken ik.

En nee. Gewoon Kontron K3844 bord. Dus geen IPMI en ik gebruik ook geen remote UI.

Met de 12700K nooit een probleem gehad. Dus ik weet ook ff niet waar ik het dan moet Zoeken.

[Jerie]

Met lsof kun je uitvinden welke PID de driver (of bijvoorbeeld framebuffer) momenteel zou gebruiken.

[shadylog]

Mars Warrior schreef op donderdag 29 januari 2026 @ 17:39:
Update. GUC=2 en consoleblank=10 maken niks uit in het verbruik.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_guc=2 consoleblank=10"

De volgende parameters staan ook nog steeds hetzelfde...

Bash:

cat /sys/devices/i915/power/runtime_enabled
cat /sys/devices/i915/power/runtime_status
disabled
unsupported

Jammer! Dat commando geeft bij mij hetzelfde output op mijn 14600K en ik zie gewoon C10 voorbijkomen wanneer ik alles uitzet. Ik vond je vorige lspci commando wel verdacht want daar stond echt "Status: D3"

[Mars Warrior]

shadylog schreef op donderdag 29 januari 2026 @ 22:36:
[...]
Jammer! Dat commando geeft bij mij hetzelfde output op mijn 14600K en ik zie gewoon C10 voorbijkomen wanneer ik alles uitzet. Ik vond je vorige lspci commando wel verdacht want daar stond echt "Status: D3"

Yep. Ik weet het ook niet precies. Vind de verschillende outputs maar verwarrend.

Kan best zijn dat het probleem bij Ubuntu 22.04 ligt en dat een dist upgrade wonderen doet.

Kan gewoon in de GUI zo’n upgrade doen. Net als in Windows gaat er i.h.a. weinig mis, toch 😳

[Jerie]

Mars Warrior schreef op donderdag 29 januari 2026 @ 23:04:
[...]

Yep. Ik weet het ook niet precies. Vind de verschillende outputs maar verwarrend.

Kan best zijn dat het probleem bij Ubuntu 22.04 ligt en dat een dist upgrade wonderen doet.

Kan gewoon in de GUI zo’n upgrade doen. Net als in Windows gaat er i.h.a. weinig mis, toch 😳

Heb je lsof al geprobeerd? Wat voor kernel versie draai je?

Je framebuffer devices staan in /dev/fb* en in sysfs kun je vinden op /sys/class/graphics.

[Mars Warrior]

Jerie schreef op donderdag 29 januari 2026 @ 23:12:
[...]
Heb je lsof al geprobeerd? Wat voor kernel versie draai je?

Je framebuffer devices staan in /dev/fb* en in sysfs kun je vinden op /sys/class/graphics.

Ga ik morgen doen. De Ubuntu HWE kernel is 6.8.

[Mars Warrior]

Jerie schreef op donderdag 29 januari 2026 @ 23:12:
[...]
Heb je lsof al geprobeerd? Wat voor kernel versie draai je?

Je framebuffer devices staan in /dev/fb* en in sysfs kun je vinden op /sys/class/graphics.

Uit lsof blijkt natuurlijk dat de framebuffer door userspace (GDM3) wordt gebruikt. Na stoppen van GDM3 is lsof leeg

Bash:

lsof /sys/class/graphics
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
      Output information may be incomplete.

Maar dit lost het probleem alsnog niet op. Verbruik blijft identiek...

Powertop 2.15 vanuit Docker blijft ook alle states op 0 houden.
Controle via turbostat geeft zelfde beeld:

Bash:

sudo turbostat --Summary --show Pkg%pc2,Pkg%pc3,Pkg%pc6,Pkg%pc8,Pkg%pc10 --interval 5

Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc8
0.00    0.00    0.00    0.00
0.00    0.00    0.00    0.00
0.00    0.00    0.00    0.00
0.00    0.00    0.00    0.00

Vanuit de summary van turbostat zie ik dat de C-states blijkbaar ongeldig zijn. Dus ik krijg toch steeds meer het idee dat het probleem met de 13900K ergens in de BIOS zit...

Bash:

cpu0: MSR_CONFIG_TDP_NOMINAL: 0x0000001e (base_ratio=30)
cpu0: MSR_CONFIG_TDP_LEVEL_1: 0x00000000 ()
cpu0: MSR_CONFIG_TDP_LEVEL_2: 0x00000000 ()
cpu0: MSR_CONFIG_TDP_CONTROL: 0x80000000 ( lock=1)
cpu0: MSR_TURBO_ACTIVATION_RATIO: 0x00000000 (MAX_NON_TURBO_RATIO=0 lock=0)
cpu0: cpufreq driver: intel_pstate
cpu0: cpufreq governor: powersave
cpufreq intel_pstate no_turbo: 0
cpu0: MSR_MISC_PWR_MGMT: 0x000030c2 (ENable-EIST_Coordination ENable-EPB DISable-OOB)
cpu0: MSR_PM_ENABLE: 0x00000001 (HWP)
cpu0: MSR_HWP_CAPABILITIES: 0x01122746 (high 70 guar 39 eff 18 low 1)
cpu0: MSR_HWP_REQUEST: 0xff000b0b (min 11 max 11 des 0 epp 0xff window 0x0 pkg 0x0)
cpu0: MSR_HWP_REQUEST_PKG: 0x8000ff01 (min 1 max 255 des 0 epp 0x80 window 0x0)
cpu0: MSR_HWP_INTERRUPT: 0x00000005 (EN_Guaranteed_Perf_Change, Dis_Excursion_Min)
cpu0: MSR_HWP_STATUS: 0x00000000 (No-Guaranteed_Perf_Change, No-Excursion_Min)
cpu0: EPB: 6 (balanced)
cpu0: MSR_IA32_POWER_CTL: 0x00e4005f (C1E auto-promotion: ENabled)
cpu0: MSR_PKG_CST_CONFIG_CONTROL: 0x74008008 (UNdemote-C1, demote-C1, locked, pkg-cstate-limit=8 (unlimited))
/dev/cpu_dma_latency: 2000000000 usec (default)
current_driver: intel_idle
current_governor: menu
current_governor_ro: menu
cpu0: POLL: CPUIDLE CORE POLL IDLE
cpu0: C1ACPI: ACPI FFH MWAIT 0x0
cpu0: C2ACPI: ACPI FFH MWAIT 0x21
cpu0: C3ACPI: ACPI FFH MWAIT 0x60
cpu0: MSR_PKGC3_IRTL: 0x00000000 (NOTvalid, 0 ns)
cpu0: MSR_PKGC6_IRTL: 0x00000000 (NOTvalid, 0 ns)
cpu0: MSR_PKGC8_IRTL: 0x00000000 (NOTvalid, 0 ns)
cpu0: MSR_PKGC10_IRTL: 0x00000000 (NOTvalid, 0 ns)

Zoals je ziet nog steeds die irritante ACPI settings, en ongeldige Idle Redidency Target Latency, en die komt vziw uit de BIOS... Alleen als die geldig zijn, kan Linux er iets mee doen.

En in de BIOS release notes van R2.19 (ik zit op R2.16) staat nog steeds dit issue als "open":
"Number of CPU Efficient Cores is not shown correctly if CPU with > 8 E-Cores is plugged into the board. "

Dat zie ik ook met de 13900K, maar lijkt dus een weergave probleem te zijn. Ik kan verder niets vinden over package states...

[ Voor 5% gewijzigd door Mars Warrior op 30-01-2026 09:09 ]

[bjp]

support officieel de BIOS die CPU?

[Mars Warrior]

bjp schreef op vrijdag 30 januari 2026 @ 09:09:
support officieel de BIOS die CPU?

Ja. Dat is al vanaf de eerste R2.x BIOS versies. En ik zit dus op R2.16

[ Voor 3% gewijzigd door Mars Warrior op 30-01-2026 09:12 ]

[pimlie]

@Mars Warrior Kan je niet upgraden naar een meer recentere kernel? Ontwikkelingen gaan snel en kernel v6.8 uit 2024 is alweer bijna 2 jaar oud.

[spoor12b]

FireDrunk schreef op donderdag 29 januari 2026 @ 14:51:
[...]

FireDrunk in "Het grote zuinige server topic - deel 3"

@FireDrunk Dank, is gelukt. Voor wie dit ook wil proberen en, net als ik, niet echt goed bekend is met docker. Het eerste code block moet in een file komen te staan met de naam Dockerfile

[Jerie]

Dit is Ubuntu LTS 22.04 native? Gebruik je ZFS?