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.