Linux en zuinigheid

[mux]

En dan heb je je fans nog aanstaan, nog iets van USB devices? Headless/scherm uit?

Let overigens op, mijn bios-spanningswaarden zaten letterlijk op het randje. Ik heb iets van drie dagen continu zitten stresstesten om te verifiëren dat ze goed waren. Er was meer dan 2% afwijking tussen mijn multimeter- en de BIOS-waarden, dus het kan heel goed zijn dat jij nu in werkelijkheid een paar stapjes anders zit dan ik. Deze undervolts moet je absoluut uitvoerig testen op stabiliteit, anders word je zeker met een server dik genaaid met een instabiel systeem.

Enneh, da's een erg goede seasonic voeding voor zover ik erover heb gelezen. 85% op 13W belasting zou hij net niet moeten kunnen halen, maar boven de 80% zit hij dan zeker al.

[deadinspace]

richardt schreef op woensdag 23 maart 2011 @ 22:02:
* Custom 2.6.38 kernel (tickless, zonder modules of alleen i915.ko als module)

Waarom? Voor het stroomverbruik, of om een andere reden? In het eerste geval: maakt het daadwerkelijk wat uit?

[B2]

mux schreef op woensdag 23 maart 2011 @ 22:50:
Let overigens op, mijn bios-spanningswaarden zaten letterlijk op het randje. Ik heb iets van drie dagen continu zitten stresstesten om te verifiëren dat ze goed waren. Er was meer dan 2% afwijking tussen mijn multimeter- en de BIOS-waarden, dus het kan heel goed zijn dat jij nu in werkelijkheid een paar stapjes anders zit dan ik. Deze undervolts moet je absoluut uitvoerig testen op stabiliteit, anders word je zeker met een server dik genaaid met een instabiel systeem.

Jouw spanningswaardes lopen bij mij echt heel stabiel. Ik heb alles 1:1 overgenomen, behalve het geheugen. (Omdat ik 'gewoon' Kingston ValueRam heb)
Server draait nu ongeveer een maand of 4/5 rock stable.

[mux]

Ik heb er tegenwoordig ook Kingston in hangen ipv OCZ enneh... dat Kingston geheugen loopt zelfs op een lagere spanning al stabiel

Laat je niet misleiden door de 'gouden' heatspreader; dat OCZ Gold LV geheugen is troep.

[richardt]

mux schreef op woensdag 23 maart 2011 @ 22:50:
En dan heb je je fans nog aanstaan, nog iets van USB devices? Headless/scherm uit?

Ja, ik heb 1 CPU fan, maar die draait al (denk ik) op een duty cycle van 12.5%. Enige USB device is een toetsenbord dat zelfs via een PS2-USB converter is aangesloten. Headless: Ja.
Voor alles hierboven geldt: ik kan het eigenlijk niet meten, en al helemaal niet op AC verbruik. Uitschakelen van de CPU fan bijvoorbeeld levert een winst op van een 10-20 mA, en dat is nou net de resolutie van mijn multimeter.

deadinspace schreef op woensdag 23 maart 2011 @ 22:55:
[...]
Waarom? Voor het stroomverbruik, of om een andere reden? In het eerste geval: maakt het daadwerkelijk wat uit?

Waarom een custom kernel? Omdat ik geen overbodige troep op mijn SSD wil. 60 GB is al niet zoveel, en met 2 VM's (windows 7+ debian 6.0) zit hij zo vol. Dan hoef ik geen kernel modules te hebben voor hardware die ik toch niet heb. Ook geen varieteit aan frequency governors, filesystems, codepages etc.etc.

Waarom tickless? Ik denk dat een tickless kernel een van de vereisten is voor een zuinig systeem. De CPU blijft langer idle door het 'uitstellen' van interrupts. Daarnaast is tickless met name voor een KVM-host een uitkomst. Door zinloze interrupts (die je met een low-res timer krijgt) moet de CPU vaker (als in: veel te vaak) schakelen tussen host en virtual machine. Deze 'vmexits' zijn niet goedkoop en zorgen voor meer belasting op de CPU.

Waarom zonder modules? Goede vraag. Deze kernel is zoals gezegd voor een KVM host waar ik hopelijk niet vaak bij hoef. Hardware verandert niet en er zijn ook geen hotpluggable devices. Dan zie ik niet zo veel voordeel van kernel waarin alle modules direct worden geladen...

Waarom alleen i915.ko als module? Omdat ik wilde weten of het verschil dat vanaalten heeft gemeten ook bij mijn systeem meetbaar is. Blijkbaar niet in die mate (2 Watt max)

[richardt]

mux schreef op woensdag 23 maart 2011 @ 22:50:
Enneh, da's een erg goede seasonic voeding voor zover ik erover heb gelezen. 85% op 13W belasting zou hij net niet moeten kunnen halen, maar boven de 80% zit hij dan zeker al.

Dat zou je misschien wel denken, maar verklaart niet helemaal waarom er nagenoeg geen verschil zit met een noname adapter. Deze laatste is wel wat lager gedimensioneerd (12V/4.16A), en heeft het misschien daardoor wat makkelijker met kleine belastingen.

Wel merk dat hij moeite heeft om langs de grub bootloader te komen. Dat is bij mij een van de momenten dat nog veel vermogen wordt gevraagd. En ondanks dat hij 4.16A zou moeten kunnen verwerken, knalt hij er met 3.5A toch regelmatig uit, als eenmaal de CPU in idle is dan gaat het wel goed (totdat de CPU volledig wordt belast). Ik denk dat daar ook een verschil zit met de kwaliteitsvoedingen.

[mux]

richardt schreef op donderdag 24 maart 2011 @ 09:03:
Uitschakelen van de CPU fan bijvoorbeeld levert een winst op van een 10-20 mA, en dat is nou net de resolutie van mijn multimeter.

Dat lijkt niet te kloppen. Geen enkele van mijn fans - zelfs mijn Scythe Slip Stream @ 600rpm, laagst mogelijke stand - verbruikt minder dan 0.45W DC. Het verbruik van een fan moet toch zeker wel 50mA zijn.

[deadinspace]

Zo, da's een uitgebreid antwoord

richardt schreef op donderdag 24 maart 2011 @ 09:03:
Waarom een custom kernel? Omdat ik geen overbodige troep op mijn SSD wil. 60 GB is al niet zoveel, en met 2 VM's (windows 7+ debian 6.0) zit hij zo vol. Dan hoef ik geen kernel modules te hebben voor hardware die ik toch niet heb. Ook geen varieteit aan frequency governors, filesystems, codepages etc.etc.

Hmmja. Ik kan me er iets bij voorstellen, maar ik stoor me al snel aan het gebrek aan flexibiliteit. Wil je een keer een andere governor oid, of plug je wat hardware in of wil je een cp-1252 vfat filesystem mounten, ondersteunt je kernel het weer niet. En ach, voor die ±70MB die het je bespaart...

Dit was overigens het voornaamste waar ik op doelde: waarom een custom kernel.

Waarom tickless? Ik denk dat een tickless kernel een van de vereisten is voor een zuinig systeem.

Dat zal ongetwijfeld een beetje helpen, maar daar heb je geen custom kernel voor nodig, aangezien Debians standaard kernels tickless zijn:

% grep NO_HZ /boot/config-2.6.32-5-686
CONFIG_NO_HZ=y

Waarom zonder modules? Goede vraag.

Als je dan toch een custom kernel doet kan ik me wel voorstellen om in ieder geval bepaalde dingen built-in te maken, met name support voor het foot fs (en diens storage) zodat je geen initrd nodig hebt.

[richardt]

Hmm, initrd heb ik al in jaaaaren niet meer gebruikt (dus ja, goed argument!).En ik zeg ook niet dat ik geen modules kan laden, dat is een ander verhaal. Als ik vfat nodig heb (op een KVM host zie ik dat niet zo snel gebeuren), dan kan ik die gewoon gaan compileren en inladen. Duurt half uurtje langer, maar dat heb ik er wel voor over dan.

Verder heeft nog steeds wel zin om een custom kernel te maken, zie jouw bovenstaand voorbeeld:

% grep NO_HZ /boot/config-2.6.38
CONFIG_RCU_FAST_NO_HZ=y
CONFIG_NO_HZ=y

Zoals je ziet is RCU_FAST_NO_HZ er bij gekomen. Wat het doet?

quote: ./linux-2.6.38/init/Kconfig:360

This option causes RCU to attempt to accelerate grace periods in order to allow the final CPU to enter dynticks-idle state more quickly. On the other hand, this option increases the overhead of the dynticks-idle checking, particularly on systems with large numbers of CPUs.

Say Y if energy efficiency is critically important, particularly if you have relatively few CPUs.

Nu ben ik geen expert, maar het lijkt me dat je deze bijvoorbeeld wel wil hebben. Standaard staat deze uit, dus het is de vraag of een nieuwe kernel uit debian unstable deze optie aan zet.

En ik draai eigenlijk altijd wel de laatste kernel op een debian stable machine. Misschien niet helemaal veilig, maar heeft zeker voordelen vwb energy efficiency, vrijwel alle verbeteringen zitten in de kernel en niet in user space.

[ Voor 8% gewijzigd door richardt op 24-03-2011 11:01 ]

[mux]

richardt schreef op donderdag 24 maart 2011 @ 09:17:
[...]

Dat zou je misschien wel denken, maar verklaart niet helemaal waarom er nagenoeg geen verschil zit met een noname adapter. Deze laatste is wel wat lager gedimensioneerd (12V/4.16A), en heeft het misschien daardoor wat makkelijker met kleine belastingen.

Wel merk dat hij moeite heeft om langs de grub bootloader te komen. Dat is bij mij een van de momenten dat nog veel vermogen wordt gevraagd. En ondanks dat hij 4.16A zou moeten kunnen verwerken, knalt hij er met 3.5A toch regelmatig uit, als eenmaal de CPU in idle is dan gaat het wel goed (totdat de CPU volledig wordt belast). Ik denk dat daar ook een verschil zit met de kwaliteitsvoedingen.

Meh, liever een stabiel en zuinig systeem dan alleen een zuinig systeem... Je multimeter kan waarschijnlijk hele korte piekstromen niet meten, daar zal het probleem zitten.

[richardt]

Mee eens. Ik heb overigens nog geen lange stresstest gedaan, dus zou best kunnen dat de gekozen spanningen wat optimistisch zijn.

Wel inmiddels nog wat er af kunnen schaven, met mooie ronde getallen voor de hoofdrekenaars:

Bovenstaand systeem (H55M-E33, I3-530, 2GB, OCZ 60GB), levert in Idle de volgende waarden:

DC: 1.00A (ja!) bij 12.04 Volt = 12.04 Watt
AC: ~14 a 15 Watt (dus 80% rendement, als ik die Cresta moet geloven)

Wat ten opzichte van de vorige meting is veranderd:
* CONFIG_RCU_FAST_NO_HZ levert inderdaad nog wat extra besparing
* PicoPSU 120Watt geeft 50mA verbetering, terwijl ik had verwacht dat ook grote Pico's ongunstiger zijn bij deze lage belasting.
* Voor startup zowel monitor als keyboard fysiek afgekoppeld. Bij mij is dit gunstiger dan als ik ze afkoppel na idle (maar het is allemaal marginaal)
* Zonder CPU fan kom ik nog op 30mA minder, maar ik zal eens meten aan de fan zelf ipv op de 12V adapter

Zal binnenkort nog wat foto's maken, voordat iemand "pics, or it didn't happen" gaat zeggen.

[mux]

Je zit nu heel dichtbij de beste getallen die je zou moeten kunnen halen. Als linux DIPM zou ondersteunen (hey, heb je een intel SSD voorhanden? kun je het testen met jouw linux-skillz) kun je met de SSD er nog een halve watt afkrijgen, net als met je fan. Als je op dat punt bent uitgekomen zit je op nagenoeg dezelfde waarden die ik met Windows 7 kreeg zonder hardwaremods (ruwweg 11W DC)!*

Dat is groot nieuws. Linux is dus op de kop af (of misschien wel helemaal, of misschien beter?) even zuinig als Windows 7 te krijgen. Dat is wel een goedgelezen blogje waard.

Heb je nog meer tweaks in het vooruitzicht? Verwacht je ergens nog resultaat mee te boeken?

* sommige hardwaremods heb ik al toegepast vóórdat ik de laatste softwaretweaks heb gedaan, dus ik heb een beetje zitten terugrekenen.

[richardt]

mux schreef op donderdag 24 maart 2011 @ 21:26:
Heb je nog meer tweaks in het vooruitzicht? Verwacht je ergens nog resultaat mee te boeken?

Hmm, nog niet over nagedacht. We even het volgende gedaan:
Regelbare voeding (30V/3A) aangesloten op PicoPSU , ingesteld op 12V.Afgezien van een benodigde quickstart, loopt het systeem stabiel.

Quizvraag: Welke invloed heeft het langzaam terugdraaien van de spanning op het verbruik, de PicoPSU en het gedrag van het systeem? En wat als je de stroom limiteert?

Hopende antwoord te vinden op de vraag: is er een optimale adapter te vinden voor een zo laag mogelijk verbruik?

[richardt]

Ok, ik heb niet te veel tijd meer besteed aan bovenstaand experiment. Het maakt allemaal niet zo heel veel uit voor het verbruik als je de spanning terugregelt. Bij het verlagen van de spanning, neemt de stroomopname toe en blijft het verbruik nagenoeg constant. De PicoPSU kan er prima tegen, en het verbaast me dat ook het hele systeem daar mee om kan gaan. Ik ben in stapjes van 0.5 teruggegaan, van 12 Volt tot 9 Volt. Pas bij 9.5 Volt begint het wat kuren te vertonen (met name beeldscherm en netwerk). Uiteraard geen stresstest uitgevoerd.

Terug naar de oorspronkelijke vraag uit de beginpost: is linux daadwerkelijk onzuiniger dan windows? Alhoewel (ook) ik in de veronderstelling was dat de linux drivers niet altijd de beste ondersteuning bieden voor energie besparing, lijkt het toch een nek-aan-nek race te worden. Inmiddels is mijn systeem on par met dat van mux (natuurlijk voordat hij met hardware mods is begonnen). Zoveel heb ik niet meer aangepast sinds vorige keer, maar alleen wat kabels ingekort, molex splitters eruit, en wat andere zinloze zaken. Wel even wat metingen uitgevoerd;

1. systeem idle, geen monitor, geen netwerk, geen keyboard, cpu fan staat aan op 12.5%.
Verbruik DC = 0.89A bij 12.05 Volt = 10.72 Watt (AC = 14 Watt). Zie de foto hieronder.

2. systeem idle, lcd op vga poort, Gigabit netwerk, geen keyboard.
Verbruik DC = 0.91A bij ~12.05 Volt (niet gemeten) = 10.96 Watt (bizar weinig verschil!), fimpje gemaakt, binnenkort op Youtube...

3. systeem idle, geen monitor, geen netwerk, geen keyboard, cpu fan uit
Verbruik DC = 0.86A bij 12.08 Volt = 10.38 Watt
Het koellichaam kan dit vermogen natuurlijk niet aan (enig idee wat de K/W waarde is?), maar misschien kan het linux OS zelf wat temperaturen monitoren en de fan af en toe zelf aan en uit zetten. Niet getest: weet iemand zo of de sensors op dit bord ondersteund worden per 2.6.38

Anyway, aanschouw onderstaande pic van test #1 (yes, it did happen...)
De Cresta meter is onduidelijk, maar er staat 14Watt. De spanning heb ik met een andere meter op 12.05V gemeten. Opmerkelijk is dat ik niet eens de betere Seasonic adapter heb gebruik, maar een el-cheapo blokje van een Iiyama LCD monitor....

[mux]

Geen netwerkverbinding vs. gigabit maakt zo weinig verschil - tenminste in mijn opstelling - omdat de netwerkkaart wanneer hij niet aangesloten is hetzelfde verbruikt als wanneer hij op 100Mbps is aangesloten.

Echter, dat je nauwelijks verschil ziet met het uitzetten/afschakelen van je scherm duidt op niet-volledig ondersteunde power management in de driver. Er hoort zo'n 1W verschil tussen te zitten (AC, dus DC iets van 0.7-0.8W). In de datasheet kun je dat ook terugvinden.

Met een iets betere adapter en intel SSD zou je dus waarschijnlijk op hetzelfde verbruik als de hardwareluxx-duitsers zitten (12.5W AC). En gefelicitaart, want je doet het al een tijdje beter dan hun onder linux, want daar was hun best geboekte resultaat iets meer dan 15W.

[raven22]

richardt schreef op vrijdag 25 maart 2011 @ 20:49:
Ok, ik heb niet te veel tijd meer besteed aan bovenstaand experiment. Het maakt allemaal niet zo heel veel uit voor het verbruik als je de spanning terugregelt. Bij het verlagen van de spanning, neemt de stroomopname toe en blijft het verbruik nagenoeg constant. De PicoPSU kan er prima tegen, en het verbaast me dat ook het hele systeem daar mee om kan gaan. Ik ben in stapjes van 0.5 teruggegaan, van 12 Volt tot 9 Volt. Pas bij 9.5 Volt begint het wat kuren te vertonen (met name beeldscherm en netwerk). Uiteraard geen stresstest uitgevoerd.

Terug naar de oorspronkelijke vraag uit de beginpost: is linux daadwerkelijk onzuiniger dan windows? Alhoewel (ook) ik in de veronderstelling was dat de linux drivers niet altijd de beste ondersteuning bieden voor energie besparing, lijkt het toch een nek-aan-nek race te worden. Inmiddels is mijn systeem on par met dat van mux (natuurlijk voordat hij met hardware mods is begonnen). Zoveel heb ik niet meer aangepast sinds vorige keer, maar alleen wat kabels ingekort, molex splitters eruit, en wat andere zinloze zaken. Wel even wat metingen uitgevoerd;

1. systeem idle, geen monitor, geen netwerk, geen keyboard, cpu fan staat aan op 12.5%.
Verbruik DC = 0.89A bij 12.05 Volt = 10.72 Watt (AC = 14 Watt). Zie de foto hieronder.

2. systeem idle, lcd op vga poort, Gigabit netwerk, geen keyboard.
Verbruik DC = 0.91A bij ~12.05 Volt (niet gemeten) = 10.96 Watt (bizar weinig verschil!), fimpje gemaakt, binnenkort op Youtube...

3. systeem idle, geen monitor, geen netwerk, geen keyboard, cpu fan uit
Verbruik DC = 0.86A bij 12.08 Volt = 10.38 Watt
Het koellichaam kan dit vermogen natuurlijk niet aan (enig idee wat de K/W waarde is?), maar misschien kan het linux OS zelf wat temperaturen monitoren en de fan af en toe zelf aan en uit zetten. Niet getest: weet iemand zo of de sensors op dit bord ondersteund worden per 2.6.38

Anyway, aanschouw onderstaande pic van test #1 (yes, it did happen...)
De Cresta meter is onduidelijk, maar er staat 14Watt. De spanning heb ik met een andere meter op 12.05V gemeten. Opmerkelijk is dat ik niet eens de betere Seasonic adapter heb gebruik, maar een el-cheapo blokje van een Iiyama LCD monitor....
[afbeelding]

zou je ook eens een idle meting kunnen doen met een esxi en een paar vm's installatie? ik ben erg benieuwd of het draaien van esxi de cpu veel belast of niet.

[H!GHGuY]

richardt schreef op vrijdag 25 maart 2011 @ 20:49:
Het koellichaam kan dit vermogen natuurlijk niet aan (enig idee wat de K/W waarde is?), maar misschien kan het linux OS zelf wat temperaturen monitoren en de fan af en toe zelf aan en uit zetten. Niet getest: weet iemand zo of de sensors op dit bord ondersteund worden per 2.6.38

Welke fan/temp monitor zit er op je bord?
Gebruik eventueel de laatste versie van lm-sensors om de detectie uit te voeren. Die kan meestal wel zeggen welke kernel module je nodig hebt.

[richardt]

zou je ook eens een idle meting kunnen doen met een esxi en een paar vm's
installatie? ik ben erg benieuwd of het draaien van esxi de cpu veel
belast of niet.

Ehm, nee. Alhoewel de uitkomst interessant kan zijn, is het doel van dit draadje om de zuinigheid van linux system te onderzoeken. Daarnaast weet ik niet zo veel van esxi, dus zijn mijn meetgegevens toch al niet zo
betrouwbaar. Misschien kan dadona hier nog iets over zeggen, ik herinner me gelezen te hebben dat esxi een paar watt extra toevoegt in idle. Zou me niets verbazen, de linux kernel die ik gebruik is van 15 maart, en ik denk niet dat esxi zo recent is.

H!GHGuY schreef op zaterdag 26 maart 2011 @ 10:28:
Welke fan/temp monitor zit er op je bord?
Gebruik eventueel de laatste versie van lm-sensors om de detectie uit te voeren. Die kan meestal wel zeggen welke kernel module je nodig hebt.

Volgens mij (lees: google) zit er een Fintek F71889ED op. Die wordt
ondersteund in de F71882FG driver. Dus:

code:

CONFIG_SENSORS_F71882FG=y

En ja hoor, daarmee werkt lm-sensors prima. Alhoewel, ik krijg het
toerental wel omhoog, maar niet onder de 12.5% (=930rpm):

% cat /sys/class/hwmon/hwmon2/device/pwm1                         
0

mux schreef op vrijdag 25 maart 2011 @ 21:54:
Geen netwerkverbinding vs. gigabit maakt zo weinig verschil - tenminste in
mijn opstelling - omdat de netwerkkaart wanneer hij niet aangesloten is
hetzelfde verbruikt als wanneer hij op 100Mbps is aangesloten.

Dat zou kunnen, maar ik heb ook gelezen dat er verschil kan zijn tussen 100Mbps en 1000Mbps. Ik heb met ethtool de netwerkkaart op alle modes gezet, maar zie eigenlijk geen verschil.

Echter, dat je nauwelijks verschil ziet met het uitzetten/afschakelen van je
scherm duidt op niet-volledig ondersteunde power management in de driver. Er
hoort zo'n 1W verschil tussen te zitten (AC, dus DC iets van 0.7-0.8W). In
de datasheet kun je dat ook terugvinden.

Dat zou ook kunnen, maar er zit wel degelijk verschil tussen een startup met monitor en een startup zonder monitor. Alleen niet zo groot, en ook niet veel als je later de monitor uit zet. Maar misschien is er onder linux niet zo'n groot verschil, en zit er juist betere power management in de driver als de monitor aan staat. Ik weet het niet, en ik denk niet dat ik daar snel achter kom.

Met een iets betere adapter en intel SSD zou je dus waarschijnlijk op
hetzelfde verbruik als de hardwareluxx-duitsers zitten (12.5W AC). En
gefelicitaart, want je doet het al een tijdje beter dan hun onder linux,
want daar was hun best geboekte resultaat iets meer dan 15W.

Dank daarvoor, maar is wel zo dat een intel SSD ook minder verbruikt? Heb je daar gegevens over?

Anyway, terug naar wat metingen. Omdat ik de fan niet volledig uit kan schakelen in het OS, heb ik maar de 12V lijn van de CPU fan, aan de 5V gehangen. Dan draait het inderdaad minder hard (12V=930rpm, 5V=740rpm), en daalt het verbruikt naar 12.05 Volt bij 0.80A = 9.64 Watt (DC). Dit is zonder monitor, zonder keyboard, maar met Gigabit netwerk. De Cresta meter(s) geven 13 a 14 Watt aan. Ik heb 3 adapters getest, maar de ADPC12416BB (TPV electronics) geeft de beste resultaten.

nu constant op 12.06V bij 0.78A = 9.40 Watt (DC), Cresta op 13W (AC)

[jeroen__online]

richardt schreef op zondag 27 maart 2011 @ 22:12:
[...]

Dank daarvoor, maar is wel zo dat een intel SSD ook minder verbruikt? Heb je daar gegevens over?
[...]

Ik heb zelf destijds ook gekozen voor een (zuinige) SSD, en wel de 40GB Intel X25-V, volgens de specs-sheet doet die maar 0.15 Watt in active mode en 0.075W in idle mode In m'n desktop heb ik echter een Kingston 64GB SNV425S2, deze is een stuk minder zuinig met ~6W active en ~1W idle.

[Dadona]

richardt schreef op zondag 27 maart 2011 @ 22:12:
[...]

nu constant op 12.06V bij 0.78A = 9.40 Watt (DC), Cresta op 13W (AC)

En dat was het moment dat mux het topic uit de bookmarks heeft gehaald en ontkent jou te kennen Je kunt ook nog wel iets pakken door gigabit terug te zetten naar 100 mbit. (Gewoon om het er even extra in te drukken )

[mux]

richardt schreef op zondag 27 maart 2011 @ 22:12:
[...]
Dank daarvoor, maar is wel zo dat een intel SSD ook minder verbruikt? Heb je daar gegevens over?

Why, yes sir. Volgens mij zelfs ergens in dit topic. Mijn X25-V verbruikt 75mW idle. Mijn Vertex 2 verbruikt 0.6W idle (eigen metingen, heb ik zeker een week in m'n vrije tijd aan besteed om te onderzoeken waarom en hoe SSDs meer/minder verbruiken onder welke omstandigheden).

Anyway, terug naar wat metingen. Omdat ik de fan niet volledig uit kan schakelen in het OS, heb ik maar de 12V lijn van de CPU fan, aan de 5V gehangen. Dan draait het inderdaad minder hard (12V=930rpm, 5V=740rpm), en daalt het verbruikt naar 12.05 Volt bij 0.80A = 9.64 Watt (DC). Dit is zonder monitor, zonder keyboard, maar met Gigabit netwerk. De Cresta meter(s) geven 13 a 14 Watt aan. Ik heb 3 adapters getest, maar de ADPC12416BB (TPV electronics) geeft de beste resultaten.

nu constant op 12.06V bij 0.78A = 9.40 Watt (DC), Cresta op 13W (AC)

Netjes. (ik ontken dat je me verslagen hebt en heb nu helemaal geen huurmoordenaar ingeschakeld om je te elimineren)

[ Voor 4% gewijzigd door mux op 27-03-2011 23:57 ]

[richardt]

Naaah, alle credits gaan nog steeds naar mux (et.al.) voor dit topic en voor de bijzonder informatieve blogposts. Zonder die informatie had ik nooit specifiek die combinatie E33+i3-530 aangeschaft.

Hoe dan ook, misschien mag de topic start wat worden aangepast ("en invalideert Linux eigenlijk als OS voor zuinige builds..."). Als je wil mag je mijn systeem gegevens wel overnemen. @mux: toch ben ik benieuwd wat mijn OS bij jou zou kunnen, jij hebt per slot van rekening de hardware een stuk zuiniger gekregen. Misschien handig om het op een bootable USB te zetten (kun ik gelijk zien of het verschil maakt als de SSD er volledig tussenuit verdwijnt). Een stickje van 256 MB (ja!) is misschien wel voldoende....

[mux]

Wat mij betreft een uitstekend idee. DM/mail me maar.

[H!GHGuY]

richardt schreef op zondag 27 maart 2011 @ 22:12:
Volgens mij (lees: google) zit er een Fintek F71889ED op. Die wordt
ondersteund in de F71882FG driver. Dus:

code:

CONFIG_SENSORS_F71882FG=y

En ja hoor, daarmee werkt lm-sensors prima. Alhoewel, ik krijg het
toerental wel omhoog, maar niet onder de 12.5% (=930rpm):

% cat /sys/class/hwmon/hwmon2/device/pwm1                         
0

Lees eerst deze even:
http://git.kernel.org/?p=...2a5f;hb=refs/heads/master

Kun je me even zeggen in welke mode hij draait en welke procedure je toepast om de speed te verlagen?

Misschien kun je met deze regel weg te halen al wel iets doen:
http://git.kernel.org/?p=...b=refs/heads/master#l1292

[richardt]

Interessante documentatie, dank voor de link! Er staat in dat de fans zowel gestuurd kunnen worden met DC, of PWM duty cycles. Daarnaast kan de driver zowel een waarde in Duty Cycle percentage, als een spannings percentage (0-12V), als een vast toerental aan. Het onderscheid tussen regeling met spanning of met PWM hangt af van externe hardware en bios instellingen. De opgelegde keuze wordt inderdaad bij het laden van de driver gerapporteerd:

code:

[    1.162060] f71882fg: Found f71889fg chip at 0xa00, revision 21
[    1.162187] f71882fg f71882fg.2560: Fan: 1 is in duty-cycle mode
[    1.162189] f71882fg f71882fg.2560: Fan: 2 is in duty-cycle mode
[    1.162190] f71882fg f71882fg.2560: Fan: 3 is in duty-cycle mode

Het sturen van de fans heb ik zowel met fancontrol als handmatig geprobeerd. Beide schrijven ze in /sys/devices/platform/f71882fg.2560/pwm1 (of /sys/class/hwmon/hwmon2/device/pwm1, zelfde). Het rare is echter dat het nogal niet-lineair schijnt te zijn:

pwm	rpm
0	740
50	740
100	750
125	758
150	798
175	880
200	957
225	1029
255	1094

Ik zet de fans dus met echo nnn > /sys/devices/platform/f71882fg.2560/pwm1
De mode (uit pwm1_enable) staat bij mij op 1=Manual mode

Regel code uitcommentarieren nog niet geprobeerd. Waarom zou dat moeten werken?

[deepbass909]

Dat het niet echt lineair is klopt, zeker als je een 3-pins fan gebruikt. De 4-pins hebben een ingebouwde PWM-controller, die een stuk meer lineair moet zijn.
Met fancontrol kan je trouwens precies instellen hoe de fan moet reageren, dus onder welke temp hij volledig uit mag, wat zijn start-waarde moet zijn, minimum waarde om nog te blijven draaien, etc. De start-waarde ligt bijv. hoger dan de minimum waarde waarop hij nog blijft draaien en dat is belangrijk om goed te in stellen. Bij aanslaan van de fan zal hij dan eerst de startwaarde pakken, en vervolgens terugzakken tot de minimum waarde.

[richardt]

Dit is een 4-pins fan. Maar met de noot dat de gele draad aan de 5 volt ligt, dat kan ik even niet op afstand veranderen. Misschien veroorzaakt dat het niet-lineaire gedrag. Fancontrol is wel aardig, maar is niet meer dan een userspace proces dat de temperatuur omzet naar een pwm waarde (inderdaad met een juiste startup). Als je echter niet met sysfs het toerental kunt aanpassen, dan zal fancontrol dat ook niet kunnen.

Inmiddels heb ik dontact met de developer voor de f71882fg driver, hoop dat daar nog wat interessants uit komt.

Vorige keer vergeten te vermelden, dan er nog wat powertop tunables niet helemaal correct staan. Tijdens runtime heb ik niet veel gemerkt van het aanpassen van de die tunables, maar omdat ik het niet netjes vond om ze zo te laten staan, heb ik ze maar even op hun juiste plek gezet, zodat ze ook na een reboot weer automatisch goed staan:

/etc/sysctl.conf:

code:

vm.dirty_writeback_centisecs = 1500
vm.laptop_mode = 5

/etc/sysfs.conf (wel even apt-get install sysfsutils, als je die nog niet had)

code:

devices/system/cpu/sched_smt_power_savings = 1
devices/system/cpu/sched_mc_power_savings = 1

module/snd_hda_intel/parameters/power_save_controller = Y
module/snd_hda_intel/parameters/power_save = 1

class/scsi_host/host0/link_power_management_policy = min_power
class/graphics/fbcon/cursor_blink = 0

bus/pci/devices/0000:00:00.0/power/control = auto
bus/pci/devices/0000:00:02.0/power/control = auto
bus/pci/devices/0000:00:16.0/power/control = auto
bus/pci/devices/0000:00:1a.0/power/control = auto
bus/pci/devices/0000:00:1b.0/power/control = auto
bus/pci/devices/0000:00:1c.0/power/control = auto
bus/pci/devices/0000:00:1d.0/power/control = auto
bus/pci/devices/0000:00:1e.0/power/control = auto
bus/pci/devices/0000:00:1f.0/power/control = auto
bus/pci/devices/0000:00:1f.2/power/control = auto
bus/pci/devices/0000:00:1f.3/power/control = auto
bus/pci/devices/0000:01:00.0/power/control = auto

@vanaalten: als je dit leest, check even je script dat deze waardes zet, er zitten wat foutjes in.

En vwalla, alles staat bij een restart helemaal goed.Sterker nog, het scheelt toch nog iets in het verbuik
Helaas is de spanning wat toegenomen, maar de stroomafname weer wat minder: 12.12V bij 0.74A = 8.97Watt (DC). Helaas blijft het AC verbruik hangen op 13 Watt, dus nog maar 70% rendement. Inmiddels 4 adapters geprobeerd, maar biedt geen uitkomst.

Eerst maar eens een USB stick maken.

[ Voor 71% gewijzigd door richardt op 28-03-2011 21:40 ]

[raven22]

Mijn systeem is binnen: DH67C met i3-2100 en 8gb ram.
Nu moet ik een OS kiezen, een voorwaarde is dat ik via VM's (ik heb ervaring met virtualbox) kan werken. Welk OS is het zuinigst en welke instellingen kies ik dan?
Ubuntu server draait prima op het systeem, maar heeft het ook energie besparende mogelijkheden? Bij Debian kun je voor 'laptop' kiezen bij de instellingen tijdens installeren en dan worden zaken als cpufreq mee geinstalleerd. Is dit nodig? Hoe zit het met de i915.ko optie?
Esxi installeert niet op het systeem en ook debian heeft problemen met de nic van de chipset (Intel 82579V).
Ik kan ook voor windows 7 en virtualbox kiezen, heb ik alle drivers en energiebesparing bij de hand. Maar dan draai ik onnodig een gui.
Hebben jullie suggesties?

[CAPSLOCK2000]

Ubuntu is Debian met een mooi jasje. Er is niet veel dat Debian kan wat Ubuntu niet kan.
Als je bekend met Ubuntu zou ik gewoon dat gebruiken.

Overigens zijn de tips uit dit topic behoorlijk geavanceerd, er is geen enkele distributie die out-of-the-box zo ver gaat.

[vanaalten]

CAPSLOCK2000 schreef op dinsdag 19 april 2011 @ 14:05:
Overigens zijn de tips uit dit topic behoorlijk geavanceerd, er is geen enkele distributie die out-of-the-box zo ver gaat.

...maar verreweg de meeste besparing krijg je door de GPU in de processor zuinig te laten werken, ofwel:
in de bios de video-output uit te zetten (maar vrij lastig om 'm zonder beeld weer aan te krijgen...);
of je laat een volledige grafische desktop starten, dan zal je videodriver ook wel geladen worden;
of, als je minimaal wil werken maar met linux shell: modprobe de videodriver (i915, als ik het goed heb) en je wint flink.

[raven22]

vanaalten schreef op dinsdag 19 april 2011 @ 22:53:
[...]

...maar verreweg de meeste besparing krijg je door de GPU in de processor zuinig te laten werken, ofwel:
in de bios de video-output uit te zetten (maar vrij lastig om 'm zonder beeld weer aan te krijgen...);
of je laat een volledige grafische desktop starten, dan zal je videodriver ook wel geladen worden;
of, als je minimaal wil werken maar met linux shell: modprobe de videodriver (i915, als ik het goed heb) en je wint flink.

- als ik de gpu uitzet in de bios, kan ik dan via de jumper op het moederbord de bios resetten zodat het weer werkt?
- als ik de gpu uitzet in de bios, kan ik dan de server (met win 7) bereiken via rdp of bv teamviewer?
- als ik geen monitor aansluit, gaat de gpu dan zelf in 'slaap'?

[Mafketel]

vanaalten schreef op dinsdag 19 april 2011 @ 22:53:
...maar verreweg de meeste besparing krijg je door de GPU in de processor zuinig te laten werken, ofwel:
in de bios de video-output uit te zetten (maar vrij lastig om 'm zonder beeld weer aan te krijgen...); ...

hmm hier wordt vaker naar gerefereerd. In mijn ervaring geeft een bios het stokje niet door geeft als er geen video uitvoer mogelijk is, en communiceert dit over het algemeen luidkeels met geluidsignalen en soms ook zelfs met lichtsignalen. Is dit specifiek iets wat dat intel moederbord wel toestaat?
Of begrijp ik de quote verkeerd?

[vanaalten]

raven22 schreef op woensdag 20 april 2011 @ 08:05:
- als ik de gpu uitzet in de bios, kan ik dan via de jumper op het moederbord de bios resetten zodat het weer werkt?

Niet getest, maar ben er vrijwel zeker van dat dat wel werkt.

- als ik de gpu uitzet in de bios, kan ik dan de server (met win 7) bereiken via rdp of bv teamviewer?

Ook niet getest, maar vrijwel zeker van dat dat wel werkt. Ik kon in elk geval m'n linux-machine prima via SSH bereiken, da's toch behoorlijk vergelijkbaar.

- als ik geen monitor aansluit, gaat de gpu dan zelf in 'slaap'?

Nou, gezien je vorige opmerking: blijkbaar installeer je windows 7, kleine moeite om dan ook de videodriver te installeren - en dat geeft al een vergelijkbare besparing (GPU heeft dan ineens 'door' dat hij niets hoeft te doen, zonder driver staat 'ie nog actief te wezen. Dan nog in de BIOS uitzetten is niet meer zoveel winst.

Mafketel schreef op woensdag 20 april 2011 @ 09:16:
[...]
hmm hier wordt vaker naar gerefereerd. In mijn ervaring geeft een bios het stokje niet door geeft als er geen video uitvoer mogelijk is, en communiceert dit over het algemeen luidkeels met geluidsignalen en soms ook zelfs met lichtsignalen. Is dit specifiek iets wat dat intel moederbord wel toestaat?
Of begrijp ik de quote verkeerd?

Hmmm, nu begrijp ik jou weer niet...
Mijn ervaring met dit bord is dat je prima zonder monitor kan opstarten, maar dat de GPU onder Linux *niet* in low-power mode gaat. Installeer (modprobe) je de videodriver, dan wel en dat scheelt aanzienlijk.
Je kan in de BIOS van de CH67CF de GPU uitzetten - het start met of zonder monitor dan prima op, maar zonder beeld en met flinke stroombesparing. Geen geluid- of lichtsignalen dat er geen monitor is.

[Dadona]

Een Duitser die voor mux en mij een held begint te worden, che new, heeft het voor elkaar om zijn OS minder te laten verbruiken dan Windows 7. Hij heeft daarbij Ubuntu 10.04 en 11.04 geprobeerd, maar dat kan op zijn AM3 moederbord sideport geheugen niet benutten, waar een deel van de bezuinigingen zit (met zijn moederbord scheelt dat 4W).
Anyway, er rolt het volgende uit:

Dit verschil kan nog groter uitpakken als het met een PicoPSU getest zou worden. (Dat vergeef ik hem, hij heeft zat gedaan en voor de conclusie maakt het niets uit, de onderlinge posities blijven hetzelfde.)

Meer informatie:
Voor de test
Voor wat commando's

[Pantagruel]

Dadona schreef op maandag 13 juni 2011 @ 09:51:
Een Duitser die voor mux en mij een held begint te worden, che new, heeft het voor elkaar om zijn OS minder te laten verbruiken dan Windows 7. Hij heeft daarbij Ubuntu 10.04 en 11.04 geprobeerd, maar dat kan op zijn AM3 moederbord sideport geheugen niet benutten, waar een deel van de bezuinigingen zit (met zijn moederbord scheelt dat 4W).
Anyway, er rolt het volgende uit:
[afbeelding]
Dit verschil kan nog groter uitpakken als het met een PicoPSU getest zou worden. (Dat vergeef ik hem, hij heeft zat gedaan en voor de conclusie maakt het niets uit, de onderlinge posities blijven hetzelfde.)

Meer informatie:
Voor de test
Voor wat commando's

Sapperdeflap, als je ziet wat voor een idle gebruik hij uit een Athlon II X4 640 weet te wringen (rest van de onderdelen: MSI 890GXM-G65 ,2 x 2GB DDR3 1333, picoPSU-80-WI32, Morex 80W) kun je niets anders dan een zeer diepe buiging maken . Als t dan echt nodig is, heeft de X4 voldoende rauwe kracht om zich er doorheen te worstelen.

[Dadona]

Die X4 kost je 0,8W in idle ten opzichte van een zuinige C3 Athlon. Maar goed, nu is het wachten op testjes vanuit het Intel kamp

[Mafketel]

vanaalten schreef op woensdag 20 april 2011 @ 12:50:
[...]
Hmmm, nu begrijp ik jou weer niet...
Mijn ervaring met dit bord is dat je prima zonder monitor kan opstarten, maar dat de GPU onder Linux *niet* in low-power mode gaat. Installeer (modprobe) je de videodriver, dan wel en dat scheelt aanzienlijk.
Je kan in de BIOS van de CH67CF de GPU uitzetten - het start met of zonder monitor dan prima op, maar zonder beeld en met flinke stroombesparing. Geen geluid- of lichtsignalen dat er geen monitor is.

Even verlaat.
Pc opstarten zonder monitor is niet wat ik bedoel ..... dat kan.
Het ging mij er even om dat je zou kunnen opstarten zonder gpu, en dat zie ik soms wel geïmpliceerd maar ik heb niet het idee dat het daadwerkelijk ook zo is, maar als je post goed begrijp kan dit bordje dat dus wel en dat verbaasd mij.

Volgende vraag hier aan gerelateerd. Kun je de gpu later aanspreken door bijv pci-e doorkoppeling naar een virtueel os?

[H!GHGuY]

Mafketel schreef op dinsdag 14 juni 2011 @ 18:47:
[...]
Volgende vraag hier aan gerelateerd. Kun je de gpu later aanspreken door bijv pci-e doorkoppeling naar een virtueel os?

Goeie vraag. Daarvoor heb je als ik het me niet vergis I/O virtualisatie voor nodig. Hoewel het best kan dat de config space/BARs integraal in de VM gemapped worden.

even zoeken...
parallels kan het op http://download.parallels...ion_Users_Guide/28162.htm maar dan met gebruik van Intel VT-d (I/O virtualisatie)
Dus ik zat er nog zo ver niet naast.

[Mafketel]

Ik weet dat er mee geadverteerd wordt. Maar omdat er zoveel marketing en verkoop praat is vertrouw ik het allemaal niet zo erg meer al moet ik zeggen dat de link die geeft voor Parallels erg overtuigend is

Ik heb hier een een behoorlijke tijd geleden wat info over gezocht kvm kon het toen eigenlijk nog net niet en wat ik net lees gpu nog steeds niet.

xen is wat dat betreft verder en kon de passthrough sinds 2008 maar op dat moment nog geen gpu....
sinds 2009 lijkt het mogelijk zie http://xen.1045712.n5.nab...35-chipset-td2598400.html

Wat ik al zei ik heb er lang geleden naar gekeken ....

Mooi dat pci-e 2.0 met sr-iov en beter mr-iov er ook aandacht aan besteed.

En wat de link is naar zuinig
Een pc is zuiniger dan 2 of 3 etc etc.
Met de huidige snelle multicore machines zou je dus een host zonder gpu met 1 of meerder gpu's die gebruikt worden door 1 of meerdere guests met volledige snelle gui dankzij dedicated gpu.
Nu is dat al zonder meer mogelijk onder linux met meerdere Xorg sessies.
En eventueel onder windows ook na installatie van bijv de microsoft classroom sharing(geen idee hoe dat heet ik weet dat ze een dergelijk product hebben) of thinsoft betwin vs. Maar met deze oplossing zou je makkelijker meerdere ossen naast elkaar kunnen draaien(freebsd voor server bijv. en windows voor dat cad programma)

Of in een thuis situatie. Een host server zonder gpu waarbij als dat ding als werkstation moet fungeren de gpu door een guest kan worden gebruikt.

Nu zal je misschien zeggen dat kan nu al, maar heb je wel eens gewerkt met een virtuele machine .... om iets te testen is het ok.
Maar om dagelijks aan te werken is het erg vervelend door de virtuele gpu, vind ik persoonlijk dan.

[Verwijderd]

[b][message=35393840,noline]
PS:
Ext4 heeft een bug waardoor je harddisk regelmatig uit standby wordt gehaald.. met ext3 zit je wel safe.

Weet je ook waardoor dit komt toevallig? (Heb je zo mogelijk een bron a.u.b.? Bedankt!)

Ik probeer momenteel een Ubuntu 10.10 setup te optimaliseren m.b.t. gebruik van een WD groene schijf (louter opslag, geen OS-schijf) en zou graag willen voorkomen dat het OS (of mijn AFP-share <> MacOS) polled naar deze WD Green Caviars.
Op de schijven zelf zal ik een timer aan moeten passen m.b.t. de load/unload cycli van de kop, maar aan de OS-kant moet er ook e.e.a. gewijzigd worden om het "met rust laten van de hdd" te bewerkstelligen.

Ik heb al e.e.a. gelezen over Powertop, pm-utils en laptop-mode-tools en de instellingen+scripts die deze tooling met zich meebrengt. Met name het flushen vd buffer (wat dat ook in moge houden ) vanuit de kernel en de relatime mount optie in fstab klinken interessant.

Ik had dacht gelezen dat ext.4 juist een delay interval had, v.w.b. disk I/O -> wat op zich gunstig zou zijn, om een geparkeerde kop vd hdd of een complete spindown-situatie zo lang mogelijk in takt te houden.

http://en.wikipedia.org/wiki/Ext4 en dan onder "journalling checksumming" dacht ik.

Verder: interessant topic! Het viel mij al op met Ubuntu 8.10 (tijdje geleden alweer) dat Ubuntu meer Watt aan de stekker verbruikte dan WinXP. Het scheelde grofweg 10-11 Watt meer verbruik op Linux, terwijl ik had verwacht dat WinXP juist meer zou verbruiken.
Ik ga het ook nastreven, om mijn huidige 10.10 install zo energy-efficient mogelijk te krijgen, dus blijf dit topic zeker volgen!

[Opperpanter2]

Ik heb het hele topic gelezen, maar ben enigszins het overzicht kwijt.

Wat zijn nou de recommended aanpassingen om te doen?

Ik heb draaien

Intel DH55TC
Pentium G6950
1x4GB KVR 1333 (@1066)
80GB Laptop HDD
PicoPSU 90W + 80W Adapter.

In idle trekt hij 22/23W.

Ik draai Debian Squeeze AMD64 Standard edition (Dus geen X). Dus nog met kernel 2.6.32.5.

De module i915 wordt standaard al geladen (samen met andere modules als video en kms).

Ik zit qua verbruik al redelijk in de buurt van wat de mensen op hardwareluxx halen met dit bordje:

http://www.hardwareluxx.d...raid-0-5-test-711325.html

Ik neem aan dat de IGP dus al in de zuinige modus draait?

Monitor aan/uit zetten of loskoppelen heeft geen effect op idle verbruik.

Wat ik nog niet heb gedaan heb:

for i in /sys/bus/pci/devices/*/power/control; do echo auto > $i; done
for i in /sys/bus/usb/devices/*/power/autosuspend; do echo 1 > $i; done
echo 1 > /sys/module/snd_hda_intel/parameters/power_save
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy
echo 10 > /sys/module/snd_hda_intel/parameters/power_save
echo 5 > /proc/sys/vm/laptop_mode
echo 1 > /sys/devices/system/cpu/sched_smt_power_savings
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy

Als ik powertop draai, komt hij met 2 suggesties:

- Writeback delay verhogen. Als ik dat doe verdwijnt de melding, dus dat is ok.

- USB device is 100% in use

Deze is een beetje vaag. Ik gebruikte eerst een USB keyboard, maar heb dat toen vervangen door een PS/2 keyboard.
Melding blijft (geen usb devices aangesloten).
Vervolgens USB compleet uitgezet in BIOS.
Medling blijft. Het valt ook op dat de usb modules gewoon geladen blijven (volgens lsmod).
Vervolgens usbmodules unloaded met modprobe.
Melding verdwijnt

Maar idle verbruik wijzigt niet. Althans, als ik de audio module ook unload draait hij op 21/22watt.
Ongeveer 1 watt lager, maar dat kan ook zijn omdat de pc opgewarmd is. Het is in ieder geval marginaal.

Hoe komt het dat Debian toch de usb en audio modules blijft inladen, terwijl deze uitstaan in het BIOS?

Welke andere stappen raden jullie nog aan?

Wat me wel opvalt is dat sensors nog wat rare output geeft. Zo'n beetje alleen de CPU0 en CPU1 temps lijken te kloppen. De fanspeed is 0, terwijl hij toch draait.

w83627dhg-isa-0a10
Adapter: ISA adapter
Vcore:       +0.95 V  (min =  +0.00 V, max =  +1.74 V)
in1:         +0.74 V  (min =  +0.35 V, max =  +1.54 V)
AVCC:        +3.38 V  (min =  +2.98 V, max =  +3.63 V)
VCC:         +3.38 V  (min =  +2.98 V, max =  +3.63 V)
in4:         +1.28 V  (min =  +1.21 V, max =  +1.09 V)   ALARM
in5:         +0.77 V  (min =  +1.74 V, max =  +0.15 V)   ALARM
in6:         +1.06 V  (min =  +1.31 V, max =  +0.93 V)   ALARM
3VSB:        +3.36 V  (min =  +2.98 V, max =  +3.63 V)
Vbat:        +3.34 V  (min =  +2.70 V, max =  +3.30 V)   ALARM
fan1:          0 RPM  (min = 42187 RPM, div = 32)  ALARM
fan2:          0 RPM  (min = 42187 RPM, div = 32)  ALARM
fan3:          0 RPM  (min = 42187 RPM, div = 32)  ALARM
fan5:          0 RPM  (min = 10546 RPM, div = 128)  ALARM
temp1:       +30.0°C  (high =  -2.0°C, hyst = +56.0°C)  sensor = diode
temp2:       +34.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = diode
temp3:      +127.0°C  (high = +80.0°C, hyst = +75.0°C)  ALARM  sensor = thermistor
cpu0_vid:   +2.050 V

[H!GHGuY]

Die temps en speeds kloppen hoor.
Op temp3 zit geen sensor aangesloten en de fans hebben waarschijnlijk maar een 2pins connector zonder de RPM-teller.

Voor die drivers: dit hangt af van hoe de BIOS het disablen doet. Misschien moet je even een lspci dump maken.

[Opperpanter2]

H!GHGuY schreef op vrijdag 17 juni 2011 @ 21:43:
Die temps en speeds kloppen hoor.
Op temp3 zit geen sensor aangesloten en de fans hebben waarschijnlijk maar een 2pins connector zonder de RPM-teller.

Voor die drivers: dit hangt af van hoe de BIOS het disablen doet. Misschien moet je even een lspci dump maken.

Bedankt voor je antwoord.
Welke speeds zijn goed volgens jou? Alle fans staan op 0 RPM en een minimum speed van meer dan 40000RPM?
Ik heb een fan (CPU) en die heeft 4pins connector (Scythe Shuriken Rev.B)

Ik dacht eerst dat temp3 misschien de Southbridge was? Die voelt namelijk reteheet aan.

Dit moederbord gebruikt volgens de detect een w83627ehf, maar verder is de config voor DH55TC nog niet goed?

lspci output:

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
00:16.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset PT IDER Controller (rev 06)
00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series Chipset KT Controller (rev 06)
00:19.0 Ethernet controller: Intel Corporation 82578DC Gigabit Network Connection (rev 06)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 06)
00:1f.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA IDE Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)

en met kernel module info

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
        Subsystem: Intel Corporation Device 0036
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
00:16.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset PT IDER Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series Chipset KT Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: serial
00:19.0 Ethernet controller: Intel Corporation 82578DC Gigabit Network Connection (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: e1000e
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: ehci_hcd
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
        Subsystem: Intel Corporation Device 0036
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
00:1f.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA IDE Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: ata_piix
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: i801_smbus

[H!GHGuY]

Opperpanter2 schreef op vrijdag 17 juni 2011 @ 22:05:
[...]

Bedankt voor je antwoord.
Welke speeds zijn goed volgens jou? Alle fans staan op 0 RPM en een minimum speed van meer dan 40000RPM?

0 betekent gewoon dat er geen RPM draad is aangesloten. Tenzij je dat in hardware fixt, is 0 een prima waarde. Misschien moet je de kernel doc (http://git.kernel.org/?p=...e5f8af189f2438517;hb=HEAD) even doorlezen mocht je alsnog willen tweaken. Ik zou er echter enorm voorzichtig mee zijn.

Ik heb een fan (CPU) en die heeft 4pins connector (Scythe Shuriken Rev.B)

Is die wel goed aangesloten? Is de CPU fan aansluiting wel naar die w83627 geroute? Misschien even kijken wat je BIOS aangeeft.

Ik dacht eerst dat temp3 misschien de Southbridge was? Die voelt namelijk reteheet aan.

temperatuur waarden gaan van -128 tot +127. Afhankelijk van het verwachtte type temperatuur diode (P of N) krijg je bij niet aansluiten een van deze waarden.

Dit moederbord gebruikt volgens de detect een w83627ehf, maar verder is de config voor DH55TC nog niet goed? Er is geen config. Linux zoekt gewoon alle hardware zonder te weten welk mobo welke hardware bevat. (Engelse term is hier 'to probe').

lspci output:

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
00:16.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset PT IDER Controller (rev 06)
00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series Chipset KT Controller (rev 06)
00:19.0 Ethernet controller: Intel Corporation 82578DC Gigabit Network Connection (rev 06)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 06)
00:1f.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA IDE Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)

en met kernel module info

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
        Subsystem: Intel Corporation Device 0036
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
00:16.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset PT IDER Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series Chipset KT Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: serial
00:19.0 Ethernet controller: Intel Corporation 82578DC Gigabit Network Connection (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: e1000e
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: ehci_hcd
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
        Subsystem: Intel Corporation Device 0036
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
00:1f.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA IDE Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: ata_piix
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
        Subsystem: Intel Corporation Device 0036
        Kernel driver in use: i801_smbus

Je USB en audio controller worden beide nog over de PCIe bus getoond en dus zal Linux er nog een driver voor laden. Mocht de BIOS bij uitschakelen ervan ervoor zorgen dat ze niet over PCIe getoond worden dan zou linux ook geen driver laden.
Was er ook geen mogelijkheid om modprobe aan te geven bepaalde drivers niet te laden?

[Opperpanter2]

H!GHGuY schreef op zaterdag 18 juni 2011 @ 09:36:
[...]

0 betekent gewoon dat er geen RPM draad is aangesloten. Tenzij je dat in hardware fixt, is 0 een prima waarde. Misschien moet je de kernel doc (http://git.kernel.org/?p=...e5f8af189f2438517;hb=HEAD) even doorlezen mocht je alsnog willen tweaken. Ik zou er echter enorm voorzichtig mee zijn.

[...]

Is die wel goed aangesloten? Is de CPU fan aansluiting wel naar die w83627 geroute? Misschien even kijken wat je BIOS aangeeft.

Blijkbaar hebben Intel bordjes last van gebrekkige ondersteuning in Linux.
Om de fanspeed te kunnen zien (en wijzigen), moet je via Intel QST gaan en heb je de heci kernel driver nodig.
http://lists.lm-sensors.o.../2009-October/026830.html

EDIT: Er schijnt weer licht aan het einde van de tunnel te zijn. Intel heeft nieuwe drivers geopensourced: http://software.intel.com...-amt-open-source-drivers/

[ Voor 9% gewijzigd door Opperpanter2 op 19-06-2011 02:00 ]

[schoene]

Ik heb volgende server samengesteld:

#	Product	Prijs	Subtotaal
2	Western Digital Caviar GreenPower WD20EARS, 2TB	€ 60,90	€ 121,80
1	Western Digital Caviar Green WD5000AADS, 500GB	€ 29,20	€ 29,20
1	Cooler Master Elite 343	€ 31,14	€ 31,14
1	Intel Core i3 2100	€ 92,80	€ 92,80
1	be quiet! Pure Power L7 300W	€ 34,50	€ 34,50
1	Kingston ValueRAM KVR1333D3N9K2/4G	€ 31,02	€ 31,02
1	MSI H67MA-E35 (B3)	€ 71,22	€ 71,22
Bekijk collectie Importeer producten		Totaal	€ 411,68

Om mn verbruik te meten, heb ik een meter kunnen lenen die echter helemaal niet correct meet: de Brennenstuhl pm230 (om een indicatie van de kwaliteit te geven: http://nl.hardware.info/n...meters-terug-nav-hwi-test ).

Oorspronkelijk had ik op mijn server ubuntu 11.04 (amd64) geinstalleerd, met de kernel 2.38 opnieuw gecompileerd zodat ik de instellingen van vanaalten ( vanaalten in "Linux en zuinigheid" ) kon gebruiken. Ik kon echter niet alle commando's uitvoeren. bvb

echo 1 > /sys/devices/system/cpu/sched_smt_power_savings

gaf een foutmelding (file does not exist), zelf als ik dit als root uitvoerde. Het verbruik op de teller was rond de 36W

Omdat ik in dit topic regelmatig las dat Debian werd gebruikt, heb ik ook Debian squeeze geinstalleerd (netinstall-amd64 met enkel samba een ssh server als extra packages geselecteerd tijdens de installatie), en heb kernel 2.38.8 gecompileerd, en nu kon ik wel alle commando's uitvoeren. Als ik echter mn verbruik bekijk (ik heb ook modprobe i915 uitgevoerd) heb ik nu een verbruik van 57W met regelmatig pieken naar 70W.

Dus hoewel die meter niet betrouwbaar is, lijkt mij dit toch een sterke indicatie dat debian out of the box een stuk minder zuinig is, en dat had ik eigenlijk niet verwacht. Wat zou de oorzaak kunnen zijn, en wat kan ik er aan doen? Als ik powertop run, dan krijg ik volgende 2 tips:

* echo min_power > /sys/class/scsi_host/host0/link_power_management_policy

* Suggestion: Enable the CONFIG_INOTIFY kernel configuration option.
This option allows programs to wait for changes in files and directories
instead of having to poll for these changes

Het eerste commando verandert niets aan het verbruik, de 2e optie heb ik nog niet geprobeerd, maar als ik de .config van mijn custombuild kernel bekijk, is geen CONFIG_INOTIFY te vinden, maar wel CONFIG_INOTIFY_USR, en deze is geactiveerd.

Het enige wat ik me nog kan bedenken (ik heb eigenlijk weinig tot geen ervaring in de configuratie van linux, de laatste 2 dagen heb ik alleszins al veel geleerd), is tijdens de debian installatie ook 'laptop' de selecteren, maar ik weet niet wat deze package omvat.


een typische output van powertop (kworker, eth0 en ahci zijn altijd de top 3, maar niet altijd in dezelfde volgorde):

code:

     PowerTOP version 1.13      (C) 2007 Intel Corporation

Cn                Avg residency       P-states (frequencies)
C0 (cpu running)        ( 0.0%)
polling           0.0ms ( 0.0%)
C1 mwait          0.2ms ( 0.0%)
C2 mwait          0.3ms ( 0.0%)
C3 mwait        289.0ms (100.0%)

Wakeups-from-idle per second :  5.2     interval: 30.0s
no ACPI power usage estimate available

Top causes for wakeups:
  65.2% (  8.4)   [eth0] <interrupt>
  15.6% (  2.0)   kworker/0:1
  10.4% (  1.3)   [ahci] <interrupt>
   1.6% (  0.2)   init
   1.6% (  0.2)   [kernel core] __mod_timer (laptop_mode_timer_fn)
   1.3% (  0.2)   [kernel core] __mod_timer (dev_watchdog)

Suggestion: Enable the CONFIG_INOTIFY kernel configuration option.
This option allows programs to wait for changes in files and directories
instead of having to poll for these changes

[H!GHGuY]

schoene schreef op zondag 19 juni 2011 @ 17:04:

een typische output van powertop (kworker, eth0 en ahci zijn altijd de top 3, maar niet altijd in dezelfde volgorde):

code:

     PowerTOP version 1.13      (C) 2007 Intel Corporation

Cn                Avg residency       P-states (frequencies)
C0 (cpu running)        ( 0.0%)
polling           0.0ms ( 0.0%)
C1 mwait          0.2ms ( 0.0%)
C2 mwait          0.3ms ( 0.0%)
C3 mwait        289.0ms (100.0%)

Wakeups-from-idle per second :  5.2     interval: 30.0s
no ACPI power usage estimate available

Top causes for wakeups:
  65.2% (  8.4)   [eth0] <interrupt>
  15.6% (  2.0)   kworker/0:1
  10.4% (  1.3)   [ahci] <interrupt>
   1.6% (  0.2)   init
   1.6% (  0.2)   [kernel core] __mod_timer (laptop_mode_timer_fn)
   1.3% (  0.2)   [kernel core] __mod_timer (dev_watchdog)

Suggestion: Enable the CONFIG_INOTIFY kernel configuration option.
This option allows programs to wait for changes in files and directories
instead of having to poll for these changes

Je hebt gewoon redelijk wat netwerk verkeer op je segment. 65% zijn interrupts van je netwerk kaart, dus moet je even kijken welke netwerkverbindingen er open staan die nogal wat verkeer heen en weer duwen.
'netstat -anp' zal wel helpen.

[citruspers]

Ik heb ergens gelezen dat het handmatig terugschakelen van gigabit naar 100mbit/100baseT ook heel erg kan schelen, misschien ook iets om te proberen?

[schoene]

H!GHGuY schreef op zondag 19 juni 2011 @ 22:10:
Je hebt gewoon redelijk wat netwerk verkeer op je segment. 65% zijn interrupts van je netwerk kaart, dus moet je even kijken welke netwerkverbindingen er open staan die nogal wat verkeer heen en weer duwen.
'netstat -anp' zal wel helpen.

Misschien, maar ook als ik mijn server reboot, en er geen enkele pc connecteert (behalve 1 ssh verbinding) blijft dit verbruik even hoog. Dit is de output van netstat -anp:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:40875 0.0.0.0:* LISTEN 801/rpc.statd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 788/portmap
tcp 0 0 0.0.0.0:38513 0.0.0.0:* LISTEN 1038/rpc.mountd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1348/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1359/exim4
tcp 0 0 0.0.0.0:36321 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:901 0.0.0.0:* LISTEN 1123/inetd
tcp 0 0 127.0.0.1:111 127.0.0.1:671 ESTABLISHED 788/portmap
tcp 0 0 192.168.1.201:22 192.168.1.202:51262 ESTABLISHED 1383/0
tcp 0 0 127.0.0.1:671 127.0.0.1:111 ESTABLISHED -
tcp6 0 0 :::139 :::* LISTEN 1065/smbd
tcp6 0 0 :::22 :::* LISTEN 1348/sshd
tcp6 0 0 ::1:25 :::* LISTEN 1359/exim4
tcp6 0 0 :::445 :::* LISTEN 1065/smbd
udp 0 0 0.0.0.0:2049 0.0.0.0:* -
udp 0 0 0.0.0.0:111 0.0.0.0:* 788/portmap
udp 0 0 192.168.1.255:137 0.0.0.0:* 995/nmbd
udp 0 0 192.168.1.201:137 0.0.0.0:* 995/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 995/nmbd
udp 0 0 192.168.1.255:138 0.0.0.0:* 995/nmbd
udp 0 0 192.168.1.201:138 0.0.0.0:* 995/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 995/nmbd
udp 0 0 0.0.0.0:33156 0.0.0.0:* 801/rpc.statd
udp 0 0 0.0.0.0:39686 0.0.0.0:* -
udp 0 0 0.0.0.0:977 0.0.0.0:* 801/rpc.statd
udp 0 0 0.0.0.0:38411 0.0.0.0:* 1038/rpc.mountd
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 6353 1341/winbindd /tmp/.winbindd/pipe
unix 2 [ ACC ] STREAM LISTENING 3724 973/acpid /var/run/acpid.socket
unix 2 [ ACC ] STREAM LISTENING 6354 1341/winbindd /var/run/samba/winbindd_privileged/pipe
unix 4 [ ] DGRAM 6189 949/rsyslogd /dev/log
unix 2 [ ACC ] STREAM LISTENING 6266 1056/dbus-daemon /var/run/dbus/system_bus_socket
unix 2 [ ] DGRAM 2019 339/udevd @/org/kernel/udev/udevd
unix 2 [ ] DGRAM 6403 1383/0
unix 3 [ ] STREAM CONNECTED 6356 1341/winbindd
unix 3 [ ] STREAM CONNECTED 6355 1347/winbindd
unix 3 [ ] STREAM CONNECTED 2353 1056/dbus-daemon
unix 3 [ ] STREAM CONNECTED 2352 1056/dbus-daemon
unix 2 [ ] DGRAM 6193 973/acpid
unix 3 [ ] DGRAM 2024 339/udevd
unix 3 [ ] DGRAM 2023 339/udevd

eth0 staat trouwens niet altijd bovenaan merk ik nu op, dikwijls is het ook iets in deze trend:

Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 0.0%)
polling 0.0ms ( 0.0%)
C1 mwait 0.1ms ( 0.0%)
C2 mwait 0.3ms ( 0.0%)
C3 mwait 409.5ms (100.0%)

Wakeups-from-idle per second : 2.7 interval: 30.0s
no ACPI power usage estimate available

Top causes for wakeups:
73.2% ( 2.0) kworker/0:0
7.3% ( 0.2) init
6.1% ( 0.2) [kernel core] __mod_timer (dev_watchdog)
4.9% ( 0.1) [eth0] <interrupt>
3.7% ( 0.1) nmbd
2.4% ( 0.1) kworker/0:1
1.2% ( 0.0) [kernel core] __mod_timer (fib6_gc_timer_cb)
1.2% ( 0.0) [kernel core] __mod_timer (neigh_timer_handler)

Het is voornamelijk die kworker die bovenaan blijft, en blijkbaar ben ik niet de enige die daar wat problemen mee heeft. zie bvb http://ubuntuforums.org/showthread.php?t=1630347

[Mafketel]

Misschien dat je even minder naar de procenten moet kijken en meer naar hoeveel wakeups er zijn gemiddeld per seconde in dat 30s interval.

Dat zijn er maar 2,7 wakeups per seconde totaal bij het ene overzichtje en minder dan 10 bij die andere. Lijkt mij niet zoveel.

Ook zit je pc voor 100% volgens powertop in de c3 state, wat als ik het goed begrijp de bedoeling is als ie niets moet doen .....als een pc niets hoort te doen moet ie uit staan

Hierdoor heb ik het idee dat je hogere verbruik niet aan de idle van je cpu ligt maar aan een ander onderdeel.


Ik zit net wat te lezen in de man pagina van power.conf welsiwaar voor solaris maar dit wordt toch ook gebruikt in linux.....

Het zinnetje wat mijn aandacht trok:

Device Power Management entries are only effective if there
is no user process controlling the device directly. For
example, X Windows systems directly control frame buffers.
The entries in the power.conf file are effective only when X
Windows is not running.

Oftewel als je geen x draait is dat de manier om je monitor gedeelte in andere standen te zetten.

En er zit ook nog een andere optie daarin, je kunt namelijk aangeven tot welke load je pc als idle wordt beschouwd, standaard 0,04.

[ Voor 38% gewijzigd door Mafketel op 20-06-2011 09:34 . Reden: extra info over /etc/power.conf ]

[Opperpanter2]

Ik heb zojuist mijn Debian Squeeze install geupgrade naar Wheezy.

Het gevolg is dat powertop er mooier uitziet, maar ook dat de idle interrupts veel hoger zijn.

Zo tegen de 30 per seconde aan. Met Squeeze lag dit op 5-7 per seconde.

???

                Usage       Events/s    Category       Description
            100.0%                      Device         Audio codec hwC0D0: Realtek
             57.7 µs/s      7.9        Timer          tick_sched_timer
             24.1 µs/s      5.0        kWork          fb_flashcursor
             16.1 µs/s      3.0        Timer          hrtimer_wakeup
            192.2 µs/s      1.0        Process        powertop
            108.9 µs/s      1.0        Process        sshd: root@pts/0
             33.7 µs/s      1.0        Interrupt      [3] net_rx(softirq)
             20.5 µs/s      1.0        Process        /usr/sbin/apache2 -k start
             10.7 µs/s      1.0        Process        [ksoftirqd/1]
              7.1 µs/s      1.0        kWork          flush_to_ldisc
             41.3 µs/s      0.0        Process        [kworker/1:1]
             38.9 µs/s      0.0        Interrupt      [9] RCU(softirq)
             31.9 µs/s      0.0        Interrupt      [1] timer(softirq)
             23.3 µs/s      0.0        Timer          cursor_timer_handler
             17.7 µs/s      0.0        Interrupt      [7] sched(softirq)
             16.2 µs/s      0.0        Timer          delayed_work_timer_fn
              8.2 µs/s      0.0        kWork          vmstat_update

[ Voor 73% gewijzigd door Opperpanter2 op 20-06-2011 19:48 ]

[mux]

Ik snap niet helemaal waar dit over gaat. Zijn dit het totaal aantal interrupts per seconde die het OS te verwerken krijgt? Want dat is echt serieus uberweinig to teh max. Een normale computer kan 100k interrupts per seconde verwerken en doet dat ook onder serieuze belasting. Zelfs idle zul je, uitgezonderd mechanisch gelimiteerde devices (hdd's enzo) nog honderden interrupts per seconde kunnen uitvoeren op een fractie van een procent CPU-belasting.

[Opperpanter2]

Het gaat om zowel hardware als software interrupts. Eigenlijk alles wat je cpu uit de idle state trekt.

http://www.linuxpowertop.org/powertop.php

Het idee is dat hoe minder interrupts je hebt, hoe zuiniger het geheel is.

Men beweert dat je met een volledige GNOME dektop toch op 3 interrupts per seconde uit moet kunnen komen.

Ik zat dus eerst op 5-7 en nu opeens op 20-30.

Waarschijnlijk geen ramp voor het verbruik (alhoewel dat lastig meten is met zo'n brakke Cresta), maar ik wil het gewoon snappen.

[mux]

OK. Tsja, voor het verbruik zal het absoluut niks uitmaken. Misschien dat je een meetbaar hoger verbruik krijgt tegen de 1000 int/s. Weten hoe het komt is echter een prima reden daar leef ik voor

[Opperpanter2]

mux schreef op maandag 20 juni 2011 @ 20:09:
OK. Tsja, voor het verbruik zal het absoluut niks uitmaken. Misschien dat je een meetbaar hoger verbruik krijgt tegen de 1000 int/s. Weten hoe het komt is echter een prima reden daar leef ik voor

Dan wil weten waarom 1000 int/s pas merkbaar is in verbruik?
Ik heb met 20-30 int/s al dat de cpu maar 98% idle zijn. Ik zie hem soms zelfs naar 2.4Ghz springen (ipv 1.2GHz in idle).

[mux]

Mja, voor dat soort dingen weet ik er niet genoeg vanaf. Interrupts worden niet gelijk geschapen; een USB-interrupt is intensiever dan een RTC tick. Verder ligt het aan hoe de CPU driver omgaat met frequency scaling of hij meteen omhoog springt bij enkele interrupts, of dat hij idle blijft tot een bepaald percentage belasting. Daarnaast zijn interrupts verre van een maat voor CPU-belasting, ook in idle. Mijn matlab-simulaties genereren maar liefst 3 interrupts per seconde, maar trekken wel m'n CPU vol.

Het enige dat ik je kan vertellen is dat mijn laptop momenteel ongeveer 1500 int/s verwerkt en op 1% cpu hangt, en dat dit ook redelijk normaal is. 20 interrupts per seconde zouden lang niet iets moeten zijn waar je je zorgen om moet maken per sé. En dan heb ik het nog niet eens gehad over hoe klein het aandeel van CPU processing is in je totale verbruik.

[Opperpanter2]

Het vormt inderdaad *geen* maat voor cpu belasting, maar een maat voor hoe goed je cpu in idle kan blijven.
Als een zwaar process als matlab je cpu voltrekt, zullen er inderdaad weinig interrupts zijn omdat er geen idle state is om te interrupten.
Als ik hier een stress testje draai, gaat hij naar 0 int/s.

[Opperpanter2]

H!GHGuY schreef op zaterdag 18 juni 2011 @ 09:36:
Je USB en audio controller worden beide nog over de PCIe bus getoond en dus zal Linux er nog een driver voor laden. Mocht de BIOS bij uitschakelen ervan ervoor zorgen dat ze niet over PCIe getoond worden dan zou linux ook geen driver laden.
Was er ook geen mogelijkheid om modprobe aan te geven bepaalde drivers niet te laden?

Met modprobe -r kan je ze wel unloaden (na opstarten en dus inladen van de modules).

Het grappige is echter dat de module wel geladen worden, maar vervolgens werkt de hardware niet.
bv usb stickje erin, geen resultaat. Als je usb weer aanzet in het bios, dan werkt het wel gewoon.

[DutchNutcase]

Opperpanter2 schreef op maandag 20 juni 2011 @ 21:01:
[...]

Met modprobe -r kan je ze wel unloaden (na opstarten en dus inladen van de modules).

Het grappige is echter dat de module wel geladen worden, maar vervolgens werkt de hardware niet.
bv usb stickje erin, geen resultaat. Als je usb weer aanzet in het bios, dan werkt het wel gewoon.

Je kunt ze ook gewoon blacklisten, hoor. Dan wordt de betreffende module uberhaupt niet geladen.

[Opperpanter2]

Opperpanter2 schreef op zaterdag 18 juni 2011 @ 14:54:
Blijkbaar hebben Intel bordjes last van gebrekkige ondersteuning in Linux.
Om de fanspeed te kunnen zien (en wijzigen), moet je via Intel QST gaan en heb je de heci kernel driver nodig.
http://lists.lm-sensors.o.../2009-October/026830.html

EDIT: Er schijnt weer licht aan het einde van de tunnel te zijn. Intel heeft nieuwe drivers geopensourced: http://software.intel.com...-amt-open-source-drivers/

Na wat klooien inderdaad de QST SDK aan de praat gekregen, met de sample applications krijg ik nu een hele rits met gegevens, waaronder een correcte cpu fan speed.
Om het te laten werken heb ik wel de AMT driver van intel moeten compilen en installeren.
http://software.intel.com...-amt-open-source-drivers/

De HECI driver van www.openamt.org is *niet* meer nodig, AMT (MEI) is de opvolger/nieuwe naam.

De AMT driver zal beschikbaar komen in de linux kernel 3.0,

[CAPSLOCK2000]

Opperpanter2 schreef op maandag 20 juni 2011 @ 20:50:
Het vormt inderdaad *geen* maat voor cpu belasting, maar een maat voor hoe goed je cpu in idle kan blijven.
Als een zwaar process als matlab je cpu voltrekt, zullen er inderdaad weinig interrupts zijn omdat er geen idle state is om te interrupten.
Als ik hier een stress testje draai, gaat hij naar 0 int/s.

He? Dit snap ik niet. Het is een heel andere definitie van interrupt dan ik gewend ben. Volgens mij is een interrupt een verzoek aan de processor om z'n aandacht even een bepaalde kant op te richten. Bijvoorbeeld "hey, er is op een toets gedrukt, lees het keyboard eens uit!". Die signalen worden altijd gestuurd, ongeacht wat de processor doet. Het is dus niet zo dat de processor bezig of in slaap moet zijn voor je een interrupt kan sturen.

Theoretisch is het volgens mij zelf mogelijk om interrupts te sturen zonder dat er uberhaupt een processor in je PC zit. (Het interrupt wordt dan natuurlijk niet ontvangen, maar dat terzijde

[deadinspace]

CAPSLOCK2000 schreef op maandag 27 juni 2011 @ 19:42:
He? Dit snap ik niet. Het is een heel andere definitie van interrupt dan ik gewend ben.

Volgensmij bedoelt hij niet "interrupts" maar "wake-ups"
(en wake-ups worden idd veroorzaakt door interrupts, maar niet iedere interrupt resulteert in een wake-up)

[schoene]

schoene schreef op zondag 19 juni 2011 @ 17:04:
Ik heb volgende server samengesteld:

#	Product	Prijs	Subtotaal
2	Western Digital Caviar GreenPower WD20EARS, 2TB	€ 60,90	€ 121,80
1	Western Digital Caviar Green WD5000AADS, 500GB	€ 29,20	€ 29,20
1	Cooler Master Elite 343	€ 31,14	€ 31,14
1	Intel Core i3 2100	€ 92,80	€ 92,80
1	be quiet! Pure Power L7 300W	€ 34,50	€ 34,50
1	Kingston ValueRAM KVR1333D3N9K2/4G	€ 31,02	€ 31,02
1	MSI H67MA-E35 (B3)	€ 71,22	€ 71,22
Bekijk collectie Importeer producten		Totaal	€ 411,68

Om mn verbruik te meten, heb ik een meter kunnen lenen die echter helemaal niet correct meet: de Brennenstuhl pm230 (om een indicatie van de kwaliteit te geven: http://nl.hardware.info/n...meters-terug-nav-hwi-test ).

Oorspronkelijk had ik op mijn server ubuntu 11.04 (amd64) geinstalleerd, met de kernel 2.38 opnieuw gecompileerd zodat ik de instellingen van vanaalten ( vanaalten in "Linux en zuinigheid" ) kon gebruiken. Ik kon echter niet alle commando's uitvoeren. bvb

echo 1 > /sys/devices/system/cpu/sched_smt_power_savings

gaf een foutmelding (file does not exist), zelf als ik dit als root uitvoerde. Het verbruik op de teller was rond de 36W

Omdat ik in dit topic regelmatig las dat Debian werd gebruikt, heb ik ook Debian squeeze geinstalleerd (netinstall-amd64 met enkel samba een ssh server als extra packages geselecteerd tijdens de installatie), en heb kernel 2.38.8 gecompileerd, en nu kon ik wel alle commando's uitvoeren. Als ik echter mn verbruik bekijk (ik heb ook modprobe i915 uitgevoerd) heb ik nu een verbruik van 57W met regelmatig pieken naar 70W.

Dus hoewel die meter niet betrouwbaar is, lijkt mij dit toch een sterke indicatie dat debian out of the box een stuk minder zuinig is, en dat had ik eigenlijk niet verwacht. Wat zou de oorzaak kunnen zijn, en wat kan ik er aan doen?

Ter info: Ik heb mij toch een Voltcraft energy logger 4000 aangeschaft, en mijn idle verbruik is dus helemaal geen 70W (na verloop van tijd werd het zogezegd zelfs meer dan 80W), maar varieert het tussen 25W en 27W. Hiervoor heb ik dus de 2.38.8 kernel gecompileerd, met de opties van vanaalten. In het Bios heb ik op dit moment enkel de audio uitgeschakeld en het bios automatisch de cpu-fan laten regelen (met max temperatuur van 50 graden).

Wat ik echter wel vreemd vind: ik heb in de .config voor het compileren van de kernel ingesteld dat de i915-module niet standaard moet geladen worden (CONFIG_DRM_I915=m), maar als ik na een reboot 'lsmod | grep 915' uitvoer, dan is de module reeds geladen.

[deadinspace]

schoene schreef op dinsdag 28 juni 2011 @ 08:54:
Ter info: Ik heb mij toch een Voltcraft energy logger 4000 aangeschaft, en mijn idle verbruik is dus helemaal geen 70W (na verloop van tijd werd het zogezegd zelfs meer dan 80W), maar varieert het tussen 25W en 27W. Hiervoor heb ik dus de 2.38.8 kernel gecompileerd, met de opties van vanaalten.

Zo, da's nogal een verschil met je vorige meter zeg.

Maar dit is met 2.6.38.8 dus? Wat is het gebruik als je Squeeze's default 2.6.32 gebruikt? Ik ben benieuwd of dat veel scheelt...

Wat ik echter wel vreemd vind: ik heb in de .config voor het compileren van de kernel ingesteld dat de i915-module niet standaard moet geladen worden (CONFIG_DRM_I915=m),

Nee, dat heb je niet, je hebt ingesteld dat hij als module gecompileerd moet worden (de andere opties zijn: niet compilen, of vast erin compilen). Dat heeft niks te maken met het feit of de resulterende module wel of niet geladen wordt.

maar als ik na een reboot 'lsmod | grep 915' uitvoer, dan is de module reeds geladen.

Jep, die zal wel geladen zijn door udev (of eventueel al door het initramfs).

[H!GHGuY]

deadinspace schreef op dinsdag 28 juni 2011 @ 12:42:
Jep, die zal wel geladen zijn door udev (of eventueel al door het initramfs).

Even voor de duidelijkheid (en het nageslacht): udev/initramfs an sich laden geen modules...

initramfs is gewoon een mini-filesystem die de kernel gebruikt om heel vroeg tijdens boot enkele kernel modules beschikbaar te hebben. Daar is het dus de kernel zelf die het laden doet (vziw).

Tijdens boot zal 1 v/d initscripts typisch een "modprobe -a" oproepen die alle modules laadt voor je systeem.

[deadinspace]

H!GHGuY schreef op dinsdag 28 juni 2011 @ 12:53:
Even voor de duidelijkheid (en het nageslacht): udev/initramfs an sich laden geen modules...

Jawel, dat doen ze wel.

Udev is een dynamische device manager die naar allerhande events luistert (zoals het ontdekken van nieuwe hardware) en als antwoord daarop actie onderneemt (zoals het laden van kernelmodules). Zie onder andere http://wiki.debian.org/udev en http://git.kernel.org/?p=...t;a=blob;hb=HEAD;f=README :

Operation:
...
- All kernel events are matched against a set of specified rules, which
possibly hook into the event processing and load required kernel
modules to set up devices.

initramfs is gewoon een mini-filesystem die de kernel gebruikt om heel vroeg tijdens boot enkele kernel modules beschikbaar te hebben.

Initramfs is een klein filesystem met een complete userspace er op (inclusief init service) welke verantwoordelijk is voor het vinden en mounten van het uiteindelijke root filesystem. Daarvoor bevat het initramfs dus ook modules welke geladen worden door de scripts op het initramfs.

Daar is het dus de kernel zelf die het laden doet (vziw).

Dat klopt niet. De kernel laadt nooit uit zichzelf modules, dit gebeurt altijd vanuit userspace.

[schoene]

deadinspace schreef op dinsdag 28 juni 2011 @ 12:42:
Maar dit is met 2.6.38.8 dus? Wat is het gebruik als je Squeeze's default 2.6.32 gebruikt? Ik ben benieuwd of dat veel scheelt...

Ik zal dit deze avond eens proberen.

Dus als ik het goed begrijp worden alle modules op 1 of andere manier automatisch geladen bij het opstarten. Ik kan me inbeelden dat dit geen positief effect heeft op het verbruik? Indien ik te weten kom waar dit gebeurt, en dit disable (en bvb enkel de i915 module laad), Zal ik dan nog steeds een volledig werkend systeem hebben? Of zijn bepaalde modules kritisch voor de correcte werking van het os?

[Opperpanter2]

schoene schreef op dinsdag 28 juni 2011 @ 15:27:
[...]


Ik zal dit deze avond eens proberen.

Dus als ik het goed begrijp worden alle modules op 1 of andere manier automatisch geladen bij het opstarten. Ik kan me inbeelden dat dit geen positief effect heeft op het verbruik? Indien ik te weten kom waar dit gebeurt, en dit disable (en bvb enkel de i915 module laad), Zal ik dan nog steeds een volledig werkend systeem hebben? Of zijn bepaalde modules kritisch voor de correcte werking van het os?

Op zich interessant om van te leren, echter tegenwoordig is het vaak beter om de modules *wel* te laten.
Een goed voorbeeld is al meteen de i915, maar steeds meer modules ondersteunen een zuinige modus en kunnen dus de hardware in een zuignig modus zetten. Zonder geladen modulen blijft de hardware soms/vaak default draaien op volle toeren.
Mooi voorbeeld is ook de cpu. Viel me op dat mijn cpu terwijl in bios zit te klooien veel warmer wordt dan in idle. Volgens mij draait de speedstepping dan nog niet en draait hij op volle snelheid.

[mux]

Klopt - hoewel in het BIOS maar één core op volle toeren draait en de rest uitstaat. Dat hij op volle toeren draait komt door de manier waarop een bios geprogrammeerd is (niet interrupt-based maar lineair).

[Wirf]

CAPSLOCK2000 schreef op maandag 27 juni 2011 @ 19:42:
[...]


He? Dit snap ik niet. Het is een heel andere definitie van interrupt dan ik gewend ben. Volgens mij is een interrupt een verzoek aan de processor om z'n aandacht even een bepaalde kant op te richten. Bijvoorbeeld "hey, er is op een toets gedrukt, lees het keyboard eens uit!".

Klopt tot zover helemaal.

Maar bedenk ook dat, behalve het keyboard, ook een timer een interrupt kan genereren.

Vroeger was het zo dat er 100 of 1000 keer per seconde werd gekeken wat de volgende taak moest worden om uit te voeren. Omdat deze frequentie hoger is dan de reactiesnelheid van mensen, lijkt het alsof de PC meerdere dingen tegelijkertijd doet, ook al heeft een PC maar 1 core.
Deze frequentie 100 of 1000 keer per seconden werd gemaakt door een timer te programmeren die 100 of 1000 keer per seconden een interrupt geeft.

Wat tegenwoordig gebeurd, bij "Tickless idle", is dat de periode tussen het omschakelen van taken geen vaste periode meer is. In plaats daarvan wordt de timer gezet op een tijdstip in de toekomst waarop de kernel denkt dat er een ander proces moet gaan draaien.
Als er dus nagenoeg niets te doen is, kan de kernel dus ook de periodes voor de timer erg lang maken, wat dus tot gevolg heeft dat er minder interrupts per seconde gegenereerd worden.

Hoe minder interrupts er gegenereerd worden, hoe langer de CPU kan slapen, hoe minder energie er gebruikt wordt.

(En ja, je keyboard genereert ook nog steeds interrupts, en ja, daar reageert de kernel ook nog steeds op, maar die komen niet 1000 keer per seconde voor... zo snel kun je niet typen namelijk)

[schoene]

Ik heb eens met de default squeeze kernel (2.6.32) getest, en het idle verbruik varieert dan tussen 26 en 28 W. Geen noemenswaardig verschil dus. Na dit topic en nieuws: Linux-kernel 2.6.38 met 'wonder patch' vrijgegeven te lezen had ik dit eigenlijk niet verwacht.

[H!GHGuY]

deadinspace schreef op dinsdag 28 juni 2011 @ 13:58:
[...]
Jawel, dat doen ze wel.

Udev is een dynamische device manager die naar allerhande events luistert (zoals het ontdekken van nieuwe hardware) en als antwoord daarop actie onderneemt (zoals het laden van kernelmodules). Zie onder andere http://wiki.debian.org/udev en http://git.kernel.org/?p=...t;a=blob;hb=HEAD;f=README :

Udev luistert naar events in /sys en kan daar eender welke actie op doen. Je moet niet lopen schermen met wikis of readme, als linux platform maintainer ken ik de source code maar al te best.

De kernel kan geen device proben zonder driver. Zonder device geen updates in /sys. Zonder updates in /sys geen udev event. Zonder udev event geen device nodes (of andere acties). Als jij udev dan laadt modules laden dan is er nooit een root-event die ervoor zorgt dat jouw driver geladen wordt.

Dus de logische volgorde is:
1) modprobe/insmod laden driver
2) kernel probeert om devices te proben met driver
3) als probing success dan kan driver devices aanmaken in /sys
4) udev krijgt events en leest /sys + udev rules om acties uit te voeren
typisch zijn deze acties het aanmaken van device nodes.

Je _kan_ udev modules laten laden (bvb laad module af_key voor ipsec als een ethernet device gevonden wordt) maar het is een atypisch gebruik.

Dus nogmaals: udev laadt geen modules (maw het is geen hoofdtaak van udev).

Initramfs is een klein filesystem met een complete userspace er op (inclusief init service) welke verantwoordelijk is voor het vinden en mounten van het uiteindelijke root filesystem. Daarvoor bevat het initramfs dus ook modules welke geladen worden door de scripts op het initramfs.

initramfs is een filesystem. Een filesystem doet niets uit zichzelf. Het is de content die erop staat die doet wat moet.

[...]
Dat klopt niet. De kernel laadt nooit uit zichzelf modules, dit gebeurt altijd vanuit userspace.

Ja en nee:
http://lxr.free-electrons.com/source/kernel/kmod.c#L68
De kernel kan aan userspace een module aanvragen, die userspace dan verwacht wordt te inserten.

[Elijan9]

Als je niet wilt dat i915.ko automatisch geladen wordt, zou je bijvoorbeeld een /etc/modprobe.d/blacklist-i915.conf kunnen maken met de volgende inhoud...

code:

blacklist i915

Dan wordt de module niet meer automatisch geladen door bijvoorbeeld udev.

H!GHGuY schreef op woensdag 29 juni 2011 @ 12:56:
Udev luistert naar events in /sys en kan daar eender welke actie op doen. Je moet niet lopen schermen met wikis of readme, als linux platform maintainer ken ik de source code maar al te best.

Laten we het netjes houden

Volgens mij werkt het zo: op het moment dat de kernel (nieuwe) pci ids publiceert of usb ids, kan udev aan de hand daarvan modules laden en doet dit ook, voor zover ik weet op basis van alias en niet op module naam (zie: /lib/modules/*/modules.alias). Dat is één van de ideeën van udev, dat je een USB of PCMCIA device kan aansluiten en dat de bijbehorende module geladen wordt indien nodig en je het apparaat vervolgens kunt gaan gebruiken. Op het moment dat die bijbehorende module wordt geladen, kan dit weer andere kernel events als gevolg hebben, die via udev weer andere acties kunnen triggeren, zoals het hernoemen van een ethernet device naar een standaard naam (bijvoorbeeld wlan0) e.d. Zo lees ik het ook terug in de linkjes van deadinspace.
Naar mijn bescheiden mening is dat het "typische" gedrag dat de meeste gebruikers verwachten, dat apparaten gaan werken op het moment dat je ze aansluit... (Tenzij je expliciet geen hotplugging wilt of nodig hebt.)

[Opperpanter2]

schoene schreef op woensdag 29 juni 2011 @ 08:47:
Ik heb eens met de default squeeze kernel (2.6.32) getest, en het idle verbruik varieert dan tussen 26 en 28 W. Geen noemenswaardig verschil dus. Na dit topic en nieuws: Linux-kernel 2.6.38 met 'wonder patch' vrijgegeven te lezen had ik dit eigenlijk niet verwacht.

Thanks voor de update.
Heb je teovallig ook ergens gepost (/gelezen) hoe je kernel upgrade naar 2.6.38 (dmv eigen compile in jouw geval begrijp ik). Ik kon het niet vinden nl. De posts die ik erover vind gaan allemaal uit van dat je ook een hele berg packages upgrade en eigenlijk gewoon tijdelijk pacakges binnenhaalt vanuit testing/wheezy.

EDIT: hmmm had beter moeten zoeken volgens mij: http://debian-bits-and-sn...in-squeeze-backports.html en http://www.broce.net/?p=54

[ Voor 9% gewijzigd door Opperpanter2 op 29-06-2011 21:37 ]

[irtimmer]

De linux kernel heeft sinds 2.6.38 wat problemen met power management, maar zie ook http://www.phoronix.com/s...=linux_mobile_uffda&num=1 en http://www.phoronix.com/s...?page=news_item&px=OTYwMQ voor meer informatie

[schoene]

Elijan9 schreef op woensdag 29 juni 2011 @ 17:12:
Als je niet wilt dat i915.ko automatisch geladen wordt, zou je bijvoorbeeld een /etc/modprobe.d/blacklist-i915.conf kunnen maken met de volgende inhoud...

code:

blacklist i915

Dan wordt de module niet meer automatisch geladen door bijvoorbeeld udev.

Eigenlijk was het net het omgekeerde wat ik wilde doen: alle modules blacklisten en enkel i915 laden, maar dat is me hierboven afgeraden.

Opperpanter2 schreef op woensdag 29 juni 2011 @ 21:32:
[...]

Thanks voor de update.
Heb je teovallig ook ergens gepost (/gelezen) hoe je kernel upgrade naar 2.6.38 (dmv eigen compile in jouw geval begrijp ik). Ik kon het niet vinden nl. De posts die ik erover vind gaan allemaal uit van dat je ook een hele berg packages upgrade en eigenlijk gewoon tijdelijk pacakges binnenhaalt vanuit testing/wheezy.

EDIT: hmmm had beter moeten zoeken volgens mij: http://debian-bits-and-sn...in-squeeze-backports.html en http://www.broce.net/?p=54

Na iets langer analyseren lijkt het me dat het verbruik met de 2.3.38-kernel eerder naar 25W neigt, en de 2.6.32 naar 28W, dus toch een verschil van 3W. Ik heb overigens volgende manual gebruikt om de kernel zelf te compileren: http://duopetalflower.blo...-in-ten-steps-ubuntu.html

Verder heb ik ook nog een vraag: Ik heb als processor een Intel i3 2100, dus een dual core met hyperthreading. Ik heb de gids op http://www.lesswatts.org/tips/cpu.php#smpsched een beetje gevolgd, en zou dus verwachten, aangezien het zowel een dual core als een processor met hyperthreading is, ik zowel

code:

echo 1 > /sys/devices/system/cpu/sched_mc_power_savings

als

code:

echo 1 > /sys/devices/system/cpu/sched_smt_power_savings

moet kunnen uitvoeren. Het 2e commando werkt, maar bij het eerste krijg ik een foutmelding (file not found dacht ik). Moet ik misschien in de config van de kernel aanduiden dat het een dual core processor betreft?

[Elijan9]

irtimmer schreef op woensdag 29 juni 2011 @ 23:12:
De linux kernel heeft sinds 2.6.38 wat problemen met power management, maar zie ook http://www.phoronix.com/s...=linux_mobile_uffda&num=1 en http://www.phoronix.com/s...?page=news_item&px=OTYwMQ voor meer informatie

Dit kan verholpen worden door "pcie_aspm=force" toe te voegen aan de kernel commandline. Dit gebruikte ik sowieso al voor mijn AMD laptop, de BIOS beweert namelijk dat mijn videokaart het niet zou ondersteunen, terwijl alles al lange tijd zonder problemen draait hiermee, en het scheelt mij inderdaad zo'n 2W (8% besparing).

Er is echter nog een regressie die al langer speelt, sinds 2.6.35. Zie ook http://www.phoronix.com/s...tem=linux_2638_aspm&num=3 en die is nog niet goed vastgesteld.

[Wirf]

schoene schreef op donderdag 30 juni 2011 @ 09:10:
Verder heb ik ook nog een vraag: Ik heb als processor een Intel i3 2100, dus een dual core met hyperthreading. Ik heb de gids op http://www.lesswatts.org/tips/cpu.php#smpsched een beetje gevolgd, en zou dus verwachten, aangezien het zowel een dual core als een processor met hyperthreading is, ik zowel

code:

echo 1 > /sys/devices/system/cpu/sched_mc_power_savings

als

code:

echo 1 > /sys/devices/system/cpu/sched_smt_power_savings

moet kunnen uitvoeren. Het 2e commando werkt, maar bij het eerste krijg ik een foutmelding (file not found dacht ik). Moet ik misschien in de config van de kernel aanduiden dat het een dual core processor betreft?

Voor dat eerste commando moet CONFIG_SCHED_MC aan staan in je kernel config.

[deepbass909]

Wirf schreef op donderdag 30 juni 2011 @ 09:45:
[...]

Voor dat eerste commando moet CONFIG_SCHED_MC aan staan in je kernel config.

En je moet natuurlijk ook SMP ondersteuning in de kernel aan hebben, anders draait je systeem op maar 1 core (heeft overigens vrijwel geen invloed op het verbruik).

Ik zit zelf met een ander raar dingetje. Mijn pc is niet extreem zuinig (idle rond de 100Watt zelfs), maar ik vond het omzetten van dvd's naar mkv's wat traag gaan. Wat blijkt, ongeacht de governor bleef de cpu op 800MHz draaien, en niet de maximale 2,8GHz... Via cpufreq is dit per core wel in te stellen, maar waarom staat de maximale snelheid op maar 800MHz?
Nu draait hij wel netjes in het bereik 800 - 2800MHz, maar bij een eerst volgende reboot zal het weer ongedaan gemaakt zijn.

Ik kan dit maar niet terug vinden. cpufreqd staat goed ingestelt, de kernel doet een autodetectie op de CPU die ook goed gaat, dus waarom dan toch de limiet op 800MHz?

Wie kan mij hierin opweg helpen?

[Wirf]

deepbass909 schreef op donderdag 30 juni 2011 @ 13:48:
[...]


En je moet natuurlijk ook SMP ondersteuning in de kernel aan hebben, anders draait je systeem op maar 1 core (heeft overigens vrijwel geen invloed op het verbruik).

Ik zit zelf met een ander raar dingetje. Mijn pc is niet extreem zuinig (idle rond de 100Watt zelfs), maar ik vond het omzetten van dvd's naar mkv's wat traag gaan. Wat blijkt, ongeacht de governor bleef de cpu op 800MHz draaien, en niet de maximale 2,8GHz... Via cpufreq is dit per core wel in te stellen, maar waarom staat de maximale snelheid op maar 800MHz?
Nu draait hij wel netjes in het bereik 800 - 2800MHz, maar bij een eerst volgende reboot zal het weer ongedaan gemaakt zijn.

Ik kan dit maar niet terug vinden. cpufreqd staat goed ingestelt, de kernel doet een autodetectie op de CPU die ook goed gaat, dus waarom dan toch de limiet op 800MHz?

Wie kan mij hierin opweg helpen?

Misschien heb je "ignore nice load" aan staan en is het omzetten ge-niced?

Wat staat er in /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load ?

(Er even van uit gaande dat je "ondemand" gebruikt als governor)

[Opperpanter2]

Ik zie dat ook hier de aanbevolen cpu governour "ondemand" is.
Ik kan weinig info vinden over of deze inderdaad beter is dan "conservative".
Mijn NAS heeft een kleine load, en als ik op conservative draai, springt hij af en toe naar 1.4Ghz en de rest draait hij idle (1.2GHz). Bij zo'n lichte load lijkt/voelt dit zuiniger dan op ondemand draaien. Deze sprint namelijk meteen naar 2.8GHz.

Zijn er hier metingen/ervaringen/bewijzen voor. Of voor het tegenovergestelde?

Ik vond alleen dit tot nu toe:

http://www.mail-archive.c...sswatts.org/msg00000.html

[Wirf]

Het idee achter de ondemand governor is dat je slechts heel kort meer energie verbruikt, en dat je daarna de CPU weer nagenoeg uit kunt zetten.

Of deze governor voor jouw specifieke situatie ook het beste is, zou je eigenlijk op je eigen hardware moeten meten. Want er zijn zoveel verschillende factoren die invloed hebben, dat je geen kant en klaar antwoord kunt geven op de vraag "welke governor is het beste"

[Sando]

Ik heb niet dit hele topic gelezen dus excuses als het al besproken is, maar ik herinner mij een aantal slechte nieuwsberichten op de frontpage over het verslechterde energieverbruik door nieuwe kernels. Ik heb verder nooit een goed follow-up bericht gehoord.

De acpi van mijn laptop wordt al (nog) niet ondersteund door Linux waardoor de batterij veel sneller leeg gaat dan in Windows, maar ik hoopte dat er ergens wat chille berichten over verbeterde energieverbruik in de nieuwste kernels te lezen waren zodat ik toch weer met een glimlag aan mijn eten kan beginnen.

[H!GHGuY]

Sando schreef op zondag 10 juli 2011 @ 20:21:
Ik heb niet dit hele topic gelezen dus excuses als het al besproken is, maar ik herinner mij een aantal slechte nieuwsberichten op de frontpage over het verslechterde energieverbruik door nieuwe kernels. Ik heb verder nooit een goed follow-up bericht gehoord.

De acpi van mijn laptop wordt al (nog) niet ondersteund door Linux waardoor de batterij veel sneller leeg gaat dan in Windows, maar ik hoopte dat er ergens wat chille berichten over verbeterde energieverbruik in de nieuwste kernels te lezen waren zodat ik toch weer met een glimlag aan mijn eten kan beginnen.

Zie dit bericht enkele posts hoger:
Elijan9 in "Linux en zuinigheid"

[Sando]

Hmm, nog niet helemaal netjes opgelost dus.

Ik zit nu op 2.6.32 maar de ACPI van mijn Thinkpad Edge heeft minstens 2.6.38 nodig om zuiniger te doen met de batterij, maar als de kernel dan zelf zo'n heethoofd is, tja 2.6.18 loopt verder ook gewoon goed.

[deepbass909]

Wirf schreef op donderdag 30 juni 2011 @ 15:40:
[...]

Misschien heb je "ignore nice load" aan staan en is het omzetten ge-niced?

Wat staat er in /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load ?

(Er even van uit gaande dat je "ondemand" gebruikt als governor)

Inmiddels lijkt het opgelost (wat het nou precies was weet ik eigenlijk niet...). Het punt was dat cpuinfo wel netjes aangaf dat de CPU op max 2.8GHz kon draaien, maar dat de maximaal beschikbare frequentie 800MHz was, ongeacht de governor. Dus zelfs in performance ging hij niet hoger dan 800MHz. Waarschijnlijk was het een cpufreqd instelling die verkeerd stond of niet deed wat hij moest doen.

Opperpanter2 schreef op woensdag 06 juli 2011 @ 22:48:
Ik zie dat ook hier de aanbevolen cpu governour "ondemand" is.
Ik kan weinig info vinden over of deze inderdaad beter is dan "conservative".
Mijn NAS heeft een kleine load, en als ik op conservative draai, springt hij af en toe naar 1.4Ghz en de rest draait hij idle (1.2GHz). Bij zo'n lichte load lijkt/voelt dit zuiniger dan op ondemand draaien. Deze sprint namelijk meteen naar 2.8GHz.

Zijn er hier metingen/ervaringen/bewijzen voor. Of voor het tegenovergestelde?

Ik vond alleen dit tot nu toe:

http://www.mail-archive.c...sswatts.org/msg00000.html

Voor energie beheer van moderne cpu's is het vaak beter om ondemand te gebruiken, omdat deze op een hogere klok meer in prestaties stijgen dan het energie verbruik stijgt. Simpel gesteld, als door de klokfrequentie te verhogen iets 10% sneller klaar is met een verbruik dat 8% hoger ligt dan bij de lagere klokfrequentie (in beide gevallen is het verbruik sowieso hoger dan in rust), is het energie-technisch dus verstandiger om even de snelheid te verhogen.
Dit wordt het "Rush to Idle" principe genoemd.
Conservative reageert veel trager dan Ondemand en kan daardoor onbedoeld juist een iets hoger verbruik veroorzaken. Powersave en Performance zijn dan weer de uitersten van het spectrum en vrijwel nooit nuttig. Powersave verlengt wel de batterij-duur van een laptop, maar maakt hem vaak ook erg traag, Performance is lekker snel maar de CPU gaat dan al snel een kookplaatje nadoen, ook als er niks te doen is.

Over het algemeen is Ondemand daarom de meest verstandige keus en ook vrijwel altijd de standaard setting, zelfs bij GSM's op Android of andere embedded apparaten met Linux.

Dit is een mooi plaatje waarin je het verschil tussen verschillende governors kan zien:


Voor de achterliggende info: http://www.ibm.com/develo...ry/l-cpufreq-1/index.html
(bron IBM, dus goede reden om het te vertrouwen )
Boven een processorbelasting van 50% maakt het eigenlijk niet meer uit welke governor je gebruikt, daaronder wel.

[Elijan9]

deepbass909 schreef op maandag 11 juli 2011 @ 15:46:
Voor energie beheer van moderne cpu's is het vaak beter om ondemand te gebruiken, omdat deze op een hogere klok meer in prestaties stijgen dan het energie verbruik stijgt. Simpel gesteld, als door de klokfrequentie te verhogen iets 10% sneller klaar is met een verbruik dat 8% hoger ligt dan bij de lagere klokfrequentie (in beide gevallen is het verbruik sowieso hoger dan in rust), is het energie-technisch dus verstandiger om even de snelheid te verhogen.
Dit wordt het "Rush to Idle" principe genoemd.

Ik weet niet waar je dit vandaan hebt, maar het stroomverbruik neemt eerder kwadratisch zo niet exponentieel toe. Dat geldt voor zowel desktop en notebook CPU's als embedded CPU's, simpelweg omdat de lekstromen veel meer op gaan spelen bij hogere schakelsnelheden.
Alleen als de idle states in verhouding met de laagste CPU snelheid erg veel verschil oplevert is het echt zinvol om ondemand te gebruiken. Dit kan best wel het geval zijn, als bij idle ook andere energiebesparende zaken worden ingeschakeld (geheugencontroller e.d.). Voor mijn AMD processors was dit in elk geval niet het geval.

Voor mijn AMD Turion RM-70 processor geldt:
2000MHz => 16 Watt
1000MHz => 5,6 Watt
500MHz => 2.3 Watt
idle => ca. 2.0 Watt (schatting n.a.v. metingen)
Daar komt ca. 7Watt als de GPU vrijwel niets doet en 12Watt vanuit de overige hardware (scherm, geheugen, ssd/hdd, powerlogic, enzovoort).

Het is dus veel efficiënter in dit geval om conservative te gebruiken.

Conservative reageert veel trager dan Ondemand en kan daardoor onbedoeld juist een iets hoger verbruik veroorzaken.

Dat is maar hoe je het instelt, net als bij ondemand, en in de meeste gevallen veroorzaakt die traagheid juist dat je minder verbruikt, omdat je voor korte bursts niet meteen de hoofdprijs betaald.

Over het algemeen is Ondemand daarom de meest verstandige keus en ook vrijwel altijd de standaard setting, zelfs bij GSM's op Android of andere embedded apparaten met Linux.

Waar haal je dat vandaan? Voor KDE is Ondemand de standaard op stroom en Conservative op accu, sterker nog, daar heb ik ook op aangedrongen na onderzoek op diverse hardware. Bovendien ondersteunt de grafiek die je meelinkt ook nog eens dit verhaal

(bron IBM, dus goede reden om het te vertrouwen )

LOL, ik neem aan dat je dat ook echt met een knipoog bedoelt, je klinkt als een typische directeur...

[mux]

Elijan9 schreef op maandag 11 juli 2011 @ 23:39:
[...]

Ik weet niet waar je dit vandaan hebt, maar het stroomverbruik neemt eerder kwadratisch zo niet exponentieel toe. Dat geldt voor zowel desktop en notebook CPU's als embedded CPU's, simpelweg omdat de lekstromen veel meer op gaan spelen bij hogere schakelsnelheden.

In het effect heb je gelijk, in de uitleg niet.

Het verbruik van een processor schaalt:
- lineair met de schakelfrequentie (en aantal schakelende elementen, uiteraard)
- kwadratisch met spanning
- zwak exponentieel met de absolute temperatuur

Het actieve verbruik van een CPU is bovendien een deel load-afhankelijk en een deel 'statisch' (lekstroom), waarbij de lekstroom wel als V^2 en exp(T-T0) schaalt, maar niet met frequentie.

Een CPU schaalt op zijn best dus lineair met de schakelfrequentie: geen lekstroom, altijd dezelfde temperatuur en onder load en idle dezelfde spanning. Elke praktische CPU heeft een performance/watt optimum. Als hij bijna niks aan het doen is is lekstroom dominant. Neem jouw getallen:

2W om helemaal niks te doen. Performance/watt = 0
2.3W om X te doen, en dan 5.6W om 2X te doen, 16W om 4X te doen. Het is duidelijk dat die hoogste stand minder efficiënt is dan de vorige twee standjes, maar dat alles efficiënter is dan idle.

Echter, een CPU leeft niet in een vacuüm. In het echt zit er nog een hele computer omheen, en daar komt het rush-to-idle-principe vandaan: neem een typisch idle-verbruik van de computer van 20W en gooi daar je eerdere cijfers bovenop:

22.3W om X te doen
25.6W om 2X te doen
36W om 4X te doen <--meeste X per watt

Je kunt dus het beste je CPU voluit laten stampen, want dan is de machine als geheel het efficiëntste. Niet alleen je CPU.

---

Op deze manier zie je dus ook waarom het zo belangrijk is om je idle-verbruik te minimaliseren. Niet dat het niet meteen obvious is maar: een computer die niks doet en 20W verbruikt, is ernstig inefficiënt

[Elijan9]

mux schreef op dinsdag 12 juli 2011 @ 00:05:
22.3W om X te doen
25.6W om 2X te doen
36W om 4X te doen <--meeste X per watt

Die berekening is niet erg reëel naar mijn mening. Een CPU heeft taken af te handelen.Voor een taak die vier tijddelen nodig had:
4t * 22,3W = 89,2 W*t
2t * 25,6W + 2t * 20W idle = 91,2 W*t
1t * 36W + 3t * 20W idle = 96 W*t

Als het idle dus laag genoeg is, bijvoorbeeld 15Watt in jouw berekening, dan werk het wel om meteen naar maximaal verbruik te gaan, echter bij maximale snelheid gebruikt de buscontroller en geheugencontroller ook meer dan ik in mijn plaatje schetste, dit zijn alleen de CPU kern verbruiken. (Overigens heb ik mijn Macbook nog niet onder de 15 Watt zien gaan en is het hoogste verbruik van de Intel processor daarin veel buitensporiger in verhouding tot de AMD systemen waar ik mee heb kunnen testen en haalt het maximale in combinatie met het idle verbruik het nog veel minder bij het verbruik in lagere snelheden.)

Het gaat trouwens om een dual core, dus berekening zou zijn:
23W (min of meer)idle
23,3W om X te doen op 1 core (25W is gemiddeld wat ik meet)
23,6W om 2X te doen op 2 cores (27W is gemiddeld wat ik meet)
26,6W om 2X te doen op 1 core (30W is gemiddeld wat ik meet)
30,2W om 4X te doen op 2 cores (30-34W is gemiddeld wat ik meet)
37W om 4X te doen op 1 core (40-45W is gemiddeld wat ik meet)
51W om 8X te doen. (rond de 55-60W meet ik)
(Alles +30W als de videokaart maximaal belast wordt)
(Alles -2W als de grafische kaart nagenoeg niets doet en ik ASPM heb geforceerd, ook al geeft ACPI aan dit niet te ondersteunen)

[mux]

Ugh, ik zat inderdaad te slapen. Je bent inderdaad ook 1/X keer zo lang bezig met een taak, dat zat niet in mijn 'formules'.

Het idee hoort te kloppen, maar mijn uitwerking was brak.

[Sando]

Ik vind het leuk om mijn oude computers te gebruiken voor wat ik er nog mee kan, maar het is bijna niet grappig meer zo schuldig als je je voelt voor het energiegebruik.

Mijn oude Pentium II 266 MHz: ~175 watt (jukebox)
Mijn Nokia N900 @ 1150 MHz: ~5 watt

Mijn oude Core II: ~220 watt (fileserver/mediaserver)
NAS+DLNA server: ~40 watt?

[Verwijderd]

Dadona schreef op maandag 13 juni 2011 @ 14:35:
Die X4 kost je 0,8W in idle ten opzichte van een zuinige C3 Athlon. Maar goed, nu is het wachten op testjes vanuit het Intel kamp

Dus geen noodzaak om over te schakelen van een X4 620 naar een X2 250e bedoel je?
Hoe kan dit verschil zo laag liggen?

[deepbass909]

Elijan9 schreef op maandag 11 juli 2011 @ 23:39:
[...]

Dat is maar hoe je het instelt, net als bij ondemand, en in de meeste gevallen veroorzaakt die traagheid juist dat je minder verbruikt, omdat je voor korte bursts niet meteen de hoofdprijs betaald.

Het gaat om de optelsom van alle taken. Beide governors hebben hun voors en tegens en onder de streep is er niet direct te zeggen welke precies de meeste winst oplevert. Alleen "voelt" ondemand het soepelst, omdat bij een iets hogere load de andere software niet geremd wordt. Bij een laptop zou ik conservative gebruiken (had ik in het verleden ook), op een werk pc juist ondemand.

[...]

Waar haal je dat vandaan? Voor KDE is Ondemand de standaard op stroom en Conservative op accu, sterker nog, daar heb ik ook op aangedrongen na onderzoek op diverse hardware. Bovendien ondersteunt de grafiek die je meelinkt ook nog eens dit verhaal
[...]

Ik zeg niks over gebruik van accu op een laptop, alleen dat Ondemand de standaard is (wat jij in feite ook al aangeeft), en in sommige gevallen een andere governor verstandiger kan zijn. Android draait afhankelijk van de kernel op ondemand of conservative, maar alle tweaks om de telefoon sneller te krijgen beginnen bijna altijd met het omzetten van de governor naar ondemand zonder echt in te leveren op accu-duur.

Volgens mij had ik overigens uit de blog van mux een mooie beschrijving waarom Rush-to-Idle over het algemeen de voorkeur heeft.

Overigens beschouw ik IBM als een bijzonder serieus en betrouwbare bron voor dit onderzoek. Welk belang heeft IBM er namelijk bij om voor bepaalde governors te pleiten anders dan informatie verstrekken aan sys-admins en serverbeheerders die met deze vraag zitten? Er zit geen enkel commercieel belang achter en IBM heeft zeker de know-how in huis om dit soort zaken grondig te kunnen onderzoeken. Daarnaast werk(t)en ze al jaren nauw samen met RedHat/Fedora voor het ontwikkelen van Linux kernel drivers voor diverse hardware en optimalisaties.

[Sando]

Kan je ook een videokaart tijdelijk uitzetten?

Ik wil graag mijn server/mediacenter wat zuiniger hebben. Oké, als ik een film kijk mag ie wel wat verbruiken, maar tijdens idle/download liever niet. Echter als ik ctrl+alt+f1 (tty) of als het scherm op zwart gaat verbruikt ie gewoon evenveel, ~150 - 175 watt.

Als ik eurobiljetten om de verschillende onderdelen vouw dan wordt ie wel zuiniger, maar ik vroeg me af of ik hier softwarematig nog wat kon harken. Het is toch raar dat ie idle zoveel moet gebruiken. Of deden ze 5 jaar geleden nog helemaal niets aan energiebesparing?

Op dit moment:

• Asus P5LP LE
  • HP Pavilion m7780
    • Product Name: RS884AA-ABH m7780.nl-a
  • BIOS
    • Vendor: Phoenix Technologies, LTD
    • Version: 5.06
    • Release Date: 11/24/2006
  • Intel Core2 Duo 6300 @ 1.86GHz
  • nVidia Corporation G73 [GeForce 7600 GS] (rev a1)
  • Audio Intel N10/ICH 7 Family High Definition Audio Controller (rev 01)
  • Chipset:
    • Intel ICH7
  • 4 Harde schijven

Ik draai op het moment 2.6.32-33 in Ubuntu 10.04 LTS. Kan ik wel forcen naar 2.6.35 of 2.6.38 als het moet. Ook speel ik met het idee CentOS 6 er op te zetten. LTS is een beetje LOL. Na anderhalf jaar patches en backports kan ie nog steeds niet shutdownen vanuit een netwerk X-sessie of ssh (op sommige hardware) en meerdere 'grapjes' die willekeurig de kop op steken.

[Elijan9]

deepbass909 schreef op maandag 08 augustus 2011 @ 16:51:
Ik zeg niks over gebruik van accu op een laptop, alleen dat Ondemand de standaard is (wat jij in feite ook al aangeeft)

Dat is niet wat ik aangeef, bij KDE is conservative de standaard op accu en dat is ook de beste keuze over het algemeen...

Android draait afhankelijk van de kernel op ondemand of conservative, maar alle tweaks om de telefoon sneller te krijgen beginnen bijna altijd met het omzetten van de governor naar ondemand zonder echt in te leveren op accu-duur.

Klinkt toch ook logisch, het idle verbruik is daar meestal wél veel lager dan het verbruik in de laagste snelheid. Bovendien is het verschil in stroomverbruik tussen verschillende snelheden lang niet zo groot. Bij PC's is het verschil tussen idle verbruik en de laagste kloksnelheid vrijwel altijd te klein om ondemand te kunnen rechtvaardigen (ten opzichte van het stroomverbruik) en werkt het juist tegen, zoals ook op te maken uit de grafiek van IBM (stroomverbruik ondemand nergens lager dan conservative).

[Tim]

Sando schreef op maandag 08 augustus 2011 @ 18:34:
Kan je ook een videokaart tijdelijk uitzetten?

Uitzetten niet, maar je kan je monitor op standby forceren (kan ook met vbetool vanuit een tty):

xset dpms force off

De nvidia driver klokt zichzelf automatisch naar beneden (als de hardware dat ondersteund).

Of deden ze 5 jaar geleden nog helemaal niets aan energiebesparing?

5 jaar geleden was midden in de Intel EXTREME EDITION periode, waarin de race nog vol om snelheid ging en een pc net zo veel mocht verbruiken als een stofzuiger.

[Verwijderd]

Sommige schijven (zoals de WD20EARS heb ik recent ontdekt) kun je booten in standby, door een jumper op pin 3+4 te plaatsen, mits je mobo dit ondersteunt (beetje modern mobo.)
Alleen nu loop ik klooien in Ubuntu 10.10 hoe ik de upstart-job "mountall" veilig kan editten, zodat alleen de ssd op /dev/sda wordt gemount na de initiatie.

Na het booten blijft de hdd gewoon "down"- pas bij het zwarte opstartscherm, voor de Plymouth progress-bar begint het OS toch alle schijven te mounten, om ze vervolgens bij udev aan te melden en in mtab op te nemen vermoed ik, na het opspinnen loopt het bootproces door en staat de desktop in een mum van tijd.

Iemand ervaring hier met het editten van deze settings, v.w.b. upstart en "mountall"?
Vijf schijven down houden, totdat ze echt nodig zijn levert weer een aardige slijtage en energiewinst op, dacht ik zo. Dat hele linux hangt van scripts in elkaar gehaakt lijkt het, verander je hier iets- dan loopt het daar vast

[Mafketel]

gewoon in de fstab aangeven dat ze niet automatisch bij boot gemount moeten worden

[Verwijderd]

Met "noauto" bedoel je? Heb ik gedaan, maar toch pakt de initialisatie ze mee, het gaat om de stappen nog voor init van start gaat (upstart werkt voor init) en de kernel vanuit initrfs (oid, vanuit het geheugen zijn mountpoint gaat zoeken op een vast schijf) en dan alle hardware die /proc vindt gaat booten.

Wat ik zou willen, is dat die schijven met rust worden gelaten qua opspinnen, maar zij wel worden meegenomen door udev, zodat zij te zien zijn in de dropdown-list van Gnome en vervolgens makkelijk te mounten zijn, indien nodig (en dan pas opspinnen, anders gewoon totaal niet.)
De bios ben ik dus al voorbij dmv die jumper, maar nu nog Ubuntu...

Ik denk dat als het lukt om die eerste fase van de kernel-boot door te komen, idd noauto ervoor zorgt dat zij ook verder niet onnodig gemount worden etc.- maar dit is weer een stap verder.
(Het laatste is de shutdown aanpassen, die normaliter alle mountpoints forced om te controleren&cache weg te schrijven voordat runlevel 0 of 6 in kunnen gaan.)

[Sando]

In Gnome heb je van die mooie powersettings, harde schijven uit na x, slaapstand na y (als je dat al wilt gebruiken), maar gaan die instellingen voor spindown van je harde schijven ook door als je Gnome een tijdje niet start? Of is dat allemaal Gnome-only?

Ik zoek naar een oplossing om alleen (afentoe) in Gnome te booten als ik wat wil desktoppen, (standaard) in een lichte DM booten als ik TV wil kijken (XBMC) en verder eigenlijk niet in een GUI booten. Naja booten, switchen bedoel ik, mijn geplande nieuwe media center is straks ook een nas. Waarschijnlijk een Zotac AMD Fusion low profile iets.

Het liefst heb ik (zoals ik het nu heb) dat XBMC automatisch start en gewoon altijd aan is, maar als ik naar een 24/7 low energy oplossing ga kan het niet handig zijn dat die hardware accelerated XBMC gui constant de gpu loopt te gijzelen.

In theorie zou t/m F4 TTY, F5 XBMC en F6 GDM het mooiste zijn. Maar niet alleen is dat lang niet zo 'makkelijk' als vroeger meer, ook merk ik bij mijn huidige (oldskool onzuinige desktop) media center dat het kwa energieverbruik geen halve Watt scheelt of ik nu in XBMC of in TTY zit. Alsof alles toch wordt berekent in actieve sessies, of ze nu naar je monitor worden gestuurd of niet.

Is dat zonder hoofdpijn nog mogelijk trouwens? GDM onder F5 en XBMC-only onder F6 (oid)?
Ik wil de boel bouwen met Debian Squeeze, of als EcryptFS-pam nog gerepareerd wordt de komende maand liever CentOS.

-edit- extra nuttigheid

Je kan XBMC als aparte sessie draaien door een default sessie aan te maken:
/usr/share/xsessions/xbmc.desktop

code:

[Desktop Entry]
Encoding=UTF-8
Name=XBMC
Comment=XBMC Media Center session
Exec=/usr/bin/xbmc
Icon=
Type=Application

XBMC start dan wel gewoon vanuit GDM, en zover ik weet kan je geen twee GDMs draaien, dus niet XBMC onder F5 en GDM (voor Gnome desktopwerk) onder F6.

Ik ben benieuwd hoe je /etc/inittab moet aanpassen voor iets wat lijkt op dit:

code:

gdm -- :0
startx /usr/bin/xbmc -- :1

[ Voor 18% gewijzigd door Sando op 22-08-2011 03:24 ]