Václav Pašek včera otestoval avizované vylepšení spotřeby jádra 3.2.5. K testu využil notebook HP Probook 5330m a distribuci Fedora 16 64bit. Systém nastavil na poměrně úsporný režim a nechal běžet s běžnou zátěží.
Z výsledků jeho měření vyplývá, že stav se nijak neliší od předchozího testu s jádrem 3.1.4. Spotřeba notebooku je neustále o mnoho vyšší než s Windows 7 64 bit a ohlášený patch, který vylepšuje nastavení ASPM nepřinesl žádné zlepšení.
neni. problem je v RC6, ktera je stale vypnuta by default. Povolenim RC6 se lze dostat pod 10W.
mozes mi prosim poslat tvoje boot parametre pripadne cely .config alebo ja som sa na mojej t420s i7 s kernel 3.3.0-rc3 64bit boot parametre: i915.lvds_downclock=1 i915.i915_enable_fbc=1 i915.i915_enable_rc6=1 pcie_aspm=force nedostal pod 9W (a to nesmiem nic robit iba sledovat powertop :))
dakujem
Muzu potvrdit setrvaly stav problemu. Mam lenovo ThinkPad T410 a s kernelem 3.3-rc3 jsem se nedostal pod 10W. A to jen v priapde, ze ABSOLUTNE nic nedelam. Jak otevru firefox nebo libreoffice spotreba okamzite vzroste spotreba na udesnych 18-20W a to jen pisu nebo scroluji v dokumentu!!!
Ztratil jsem dalsiho pul dne jen abych zjistil, ze ani kernel 3.3-rc3 problem s vysokou spotrebou neresi.
Ne kazde lenivo T420 ma pouze Intel grafiku. Pokud mate nvidii, mate smulu. Pokud mate optimus a nvidia neni nejakym skriptem uplne vypnuta, mate smulu.
Docela jeste pomuze v pripade nepouzivani dat down eth0 a nastavit neosahavani cdrom (idealne cdrom vytahnout z baye uplne pryc).
No a samozrejme taky zalezi na rozezranosti pouziteho prostredi. Ja bazmeky typu gnome nepouzivam a uz vubec ne nejake 3D efekty, kompozitor a co ja vim, co jeste. Staci mi openbox + lista z xfce. Pak se pod tech 10W dostanu.
i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 i915.i915_semaphores=1
aspm=force jsem oddělal, neb je to již opravené. Nvidiu vypínám přes bbswitch. Mám Core i5, SSD disk do mSATA, a vypnutý bluetooth přes /proc/acpi/ibm/bluetooth.
http://store.lisk.in/tmp/.config
Snad ti to pomůže. :-)
No jasne, jeste ze jsou tady Windows a MacOSX, jinak by uz fakt nebylo s cim Linux srovnavat.
Vzdycky, kdyz nekdo poukaze na problem v linuxu je otazka chvilky, kdy se ozve nejaky "odbornik" a rekne: "Co chcete? Podivejte se na Windows nebo Mac"
Tenhle problem uz pretrvava v kernelu vice jak rok!!!
Dalsi oblibene klise v linux komunite: "Misto poukazovani na problem prilozte radeji ruku k dilu". Bezte se bodnout!!!
Faktem je, ze nikdo presne nevi jestli bude problem se spotrebou uspokojive vyresen i v avizovanem kernelu 3.3. To je po vice jak rocnim (ne)snazeni dost ubohy vysledek.
tak treba si vygooglit zakladni informace a nesirit tady famy a neplivat na neco, cemu nerozumite.
Autodetekce power-saving featur neni jednoducha vec, zvlast, kdyz jde BIOS proti vam, nahlasi vam lzi a pak se to kousne, kdyz chcete nejakou tu nalhanou featuru vyuzit.
Pokud vim, ty zakladni featury se daji manualne zapnout a vyzkouset, jestli to beha...
Dalsi klise linux komunity: "vygoogli si to sam a neplivej na nas"!
Co z toho co tady tvrdim je fama???
Boot parametry kernelu pro vypnuti resp. zapnuti aspm a rc6 jsou uz znami asi vsem. Problem jenom je, ze dost casto (resp. skoro vubec) nefunguji. A v tom je ten problem, proste spotreba je furt vysoka at se snazite jak chcete.
Musím se k vám připojit (i když mě to zase bude stát nějakou tu auru).
Připomínám pana Krčmáře z jeho článku k tématu:
Přestože byla situace řádně zmedializována a všichni uživatelé chtěli znát odpověď, byl Larabel [Michael Larabel ze serveru Phoronix] pravděpodobně jediným člověkem, který se intenzivně věnoval odhalení chyby.
Smiřte se s tím, jak to není relevantní pro server, tak to mnoho pozornosti nevzbudí. Linuxový desktop = minimální rozšíření + minimální příjmy = málo peněz na vývojáře = pomalý vývoj, minimální pozornost. Bohužel.
Nezapomeňte, že "komunita" okolo vývoje jádra tvoří ze 2/3 lidé sponzorovaní komerčními společnostmi, a ty mají jiné zájmy než linux na laptopu. Podívejte se na problémy s podporou wifi karet, ALSA, webkamery, grafické karty. Co jsem tak sledoval dění kolem grafických karet Intelu, to byl (je?) taky porod. A to je společnost která Linuxu přeje a vývoj aktivně podporuje.
asi budu ukamenován, ale problém je podle mne jinde.
základní kámen úrazu je monolitické linuxové jádro, které je již téměř neudržovatelné a bohužel nejsou lidi, co by jej přepsali. Výhody se postupem času na desktopech změnily na nevýhody a živelný neprofesionální vývoj mnohdy bez dokumentace zpečetil osud...
problém se spotřebou je jenom špička ledovce...
pokud vim, tak problem neni v architekture Linuxu, ale v tom, ze si vyrobci HW delaji co se jim zlibi, pak napisi ovladace pro wokna a konec. Ty ovladace pak umozni prechod do stavu setreni energie a takove veci.
Ono by ale mozna vubec stacilo davat najevo BIOSu existenci linuxu: acpi_osi=Linux
Jasne ... chyba je na strane INTELu, ktery nedodrzuje vlastni specifikace (to alespon tvrdili vic nez rok vyvojari kernelu) ... ale to je mi jako uzivateli opravdu jedno.
Ted uz vyvojarum kernelu doslo, ze INTEL ze INTEL se jim neprizpusobi a ze budou muset s problemem udelat neco sami. Jenze co? Mam pocit, ze ani sami moc nevedi jak na to?
Parada ... vysledek je, ze na notebooku je kvuli vysoke spotrebe Linux zcela konkurence neschopny (a nikdo zatim nevi, kdy se to zlepsi)!!! Kdyz pominu tech par geeku, kteri si nainstaluji kernel 3.3-rc3 a tvrdi, ze s nim uz je to docela OK, tak si myslim, ze to spis hlava nebera vam.
Je mi líto, ale nemáte moc představu, o čem mluvíte. Problémy s grafikami SNB a nefunkčním ASPM jsou na sobě nezávislé a jejich řešení zcela oddělené.
Problém s ASPM vznikl v jádře 2.6.38.(2?) zařazením patche, co ASPM vyřadil na všech zařízeních, u kterých BIOS explicitně nehlásil, že ho podporují, pokud se nepletu, je to dle specifikace ACPI zcela korektní předpoklad. V praxi se to však nedodržuje a Windows ASPM na zařízeních vyřadí jen tehdy, pokud se jim přes _OSC předá plná kontrola nad daným HW. Protože výrobci HW na jiném OS než Windows moc (vůbec) netestují, podobnými potížemi trpí solidní řádka zařízení. Patch backportovaný do 3.2.5 se snaží napodobit chování Windows. Pokud nejste majitelem stroje, kde ASPM na nějakém HW nefunguje, bylo vždy možno jej povolit parametrem pcie_aspm=force.
RC6 je úsporný režim SNB grafik, který z nějakého důvodu způsobuje (způsoboval?) některým uživatelům problémy a proto byl ve výchozím nastavení vypnutý. Na strojích, kde bylo vše v pořádku se dal aktivovat příslušným kernel parametrem. Intel na problému docela zapracoval a předevčírem byla zaslána sada patchů, která by problém snad měla řešit definitivně.
Přidat dva parametry do boot-line GRUBu skutečně nevyžaduje inženýrský titul a pokud něco z toho způsobuje problémy, je na místě si stěžovat spíše u výrobců dodávajících zabugovaný HW než u vývojářů jádra, kteří jejich lajdáckosti musí řešit.
"Přidat dva parametry do boot-line GRUBu skutečně nevyžaduje inženýrský titul a pokud něco z toho způsobuje problémy, je na místě si stěžovat spíše u výrobců dodávajících zabugovaný HW než u vývojářů jádra, kteří jejich lajdáckosti musí řešit."
Probelm je, ze ty dva parametry nic moc neresi!!! (To se jsem tady jedinej, kdo to zkusil nebo co?) Spotreba je stale vysoka a to jak ve srovnani s kernely < 2.6.38 tak s Windows. Vydrz baterii v Ubuntu 10.10 (kernel 2.6.32 ... cca 4-5hod). Pro kernel 2.6.38 a vyse je vydrz baterii sotva polovicni a to i kdyz jsou v boot-line ty vami zminovane parametry.
Mne jenom stve, ze cilem by snad melo byt mit pouzitelny notebook s linuxem a ne si stezovat na vyrobce HW, ze jsou lajdaci. To evidentne nikam nevede!!!
To je solidní nesmysl. pcie_aspm=force natvrdo povolí ASPM na všech dostupných zařízeních bez ohledu na to, zda jej zařízení podporuje či ne. Pokud vám tedy jádro 2.6.38 žere výrazně více, než jádra starší, ten parametr to řešit _musí_. V případě, že to nefunguje, je váš problém asi někde jinde, hlásil jste to?
Mimochodem, máte správně nastavené powersaving skripty v pm-utils(pokud je používáte)? Samotné povolení ASPM totiž neznamená, že se při provozu na baterii zapne úsporný režim automaticky - takto to nefunguje ani ve Windows. Vypište si "/sys/module/pcie_aspm/policy" a při provozu na baterii toto nastavte na "powersave". Pokud to totiž necháte na "default" (nebo nedej bože "performance"), je na hardware, jak se zachová a asi je vám jasné, že HW se nemusí vždy rozhodnout správně.
Co se porovnání s Windows týče, používáte další úsporná opatření jako ALPM, power management a snížení výkonu Wifi vysílače, vypnutí bluetooth a podobně? Pro většinu toho jsou v pm-utils skripty, jen je stačí povolit.
Aplikací podobných triků se na tři roky staré baterce dostanu při mírné zátěži na cca hodinovou výdrž. Výrobce uváděl výdrž hodinu a půl, což s přihlédnutím ke stáří aku a optimismu marketingových oddělení nepovažuji za vůbec špatný výsledek.
Tak nevim jak jste to myslel s tim "solidnim nesmyslem".
Ale stejny problem jaky tady prezentuji ja, ma na nasem pracovisti i dalsich cca 40 lidi, kteri pouzivaji business class notebooky Lenovo a Dell (vetsinou distribuci Ubuntu 11.10 na kterou maji tyto notebooky oficialni certifikaci).
Stejne problemy reportovali (jako bug) stovky lidi na forech Ubuntu, ktera dost detailne sleduji.
Navic, stejny problem, ktery tady popisuji, vlastne potvrdil i V. Pasek na svem blogu http://electriccz.blogspot.com/2012/02/linuxove-jadro-325-procesory-sandy.html
Problem jsme nekolikrat reportovali v ruznych obmenach na LaunchPad-Ubuntu, kde je podobnych reportu halda, ale vsecnhy konci do stracena.
Z poznamek lidi v teto diskusi mam pocit, jako by zadny problem se spotrebou vlastne ani neexistoval. Skoro to vypada, jako bych popuze neumel googlit a zbytecne tady otravuji.
P.S. Samozrejmne, ze pm-utils jsou pri provozu na baterie v rezimu "powersave". V tom asi problem nebude.
Myslel jsem to tak, že pokud "pcie_aspm=force" nemá na spotřebu výrazný vliv, pak s největší pravděpodobností nemáte problém s ASPM. Rozhodně netvrdím, že problém neexistuje, byl změřen, vyšetřen a přinejmenším o určité míry vyřešen.
Problém týkající se RC6 by již měl být vyřešen také, jen příslušné patche ještě nejsou k dispozici ani v -nextu.
S těmi "oficiálními certifikacemi" bych to neviděl tak horké, pochybuji, že výrobci "certifikují" podle jiného schématu než "jde to nainstalovat - dobrý, funguje WiFi a uspávání - výborný". Z diskuse jsem vyrozuměl, že máte Lenovo T410, nejde náhodou o model vybavený zázračnou technologií nVidia Optimus? Tato technologie je na Linuxu značně problematická a je možné, že i když tu nVidia grafiku nepoužíváte, je stále aktivní a žere ne zrovna zanedbatelné množství proudu. Řešením může být nainstalovat poslední verzi bumblebee, pokud však 3D výkon k ničemu nepotřebujete, je ještě lepší tu grafiku v BIOSu úplně odstřelit (pokud to BIOS dovolí).
Pokud ani to nepomůže, kouknetě do PowerTOPu, co vám generuje nejvíce wakeupů, u mě s přehledem vedou PS/2 interrupts a iwlwifi. V případě zájmu můžu někam uploadovat svoje bonusové skripty pro pm-utils.
Technicke udaje TP T410:
http://www.thinkwiki.org/wiki/Category:T410
top:
ps/2, nvidia, iwlang, resheduling interrupts (Kernel IPI)
v klidu ... cca 10-11W
otevreny firefox www.idnes.cz (scroling) ... 16-20W
kernel: 3.1.9 x86-64 (opeSUSE 12.1)
Pred tydnem jsem zavcal testovat openSUSE 12.1, ktere se chova vyrazne lepe nez Ubuntu 11.10.
Vida. Jak na ty technické specifikace koukám, tak T410 je dost obšírný pojem zahrnující dost modelů, s Intel grafikou i bez, s Optimus i bez něj. Pokud jste tím vyvoleným a Optimus (kombinaci Intel a nV grafiky) máte, je to nejspíš váš problém.
Ta nVidií grafika je totiž pořád zapnutá, sice nic nedělá, ale pořád něco žere. Ani proprietální ovladače nVidie zatím Optimus nijak neřeší, ve Windows se pokud vím nV grafika úplně vypíná přes nějaká ACPI volání.
V Linuxu tohle jakž-takž řeší Bumblebee (https://github.com/Bumblebee-Project), ale je to tak trochu hit-and-miss, na jedné mašině jsem to ve Fedoře 15 rozchodil, v Archu to spolupracovat odmítlo. Pokud k něčemu tu nVidia grafiku skutečně nepotřebujete, většinou se dá v BIOSu odstřelit (druhou možností je použít acpi_call, ale to je podobná loterie jako Bumblebee).
To mi přijde dost vtipné. Můžete vinit výrobce HW, a můžete mít i technicky pravdu. Ale faktem zůstává, že takový HW je prostě na trhu, a lidé ho používají. Pokud autoři Linuxu (kernelu i dister) chtějí Linux rozšířit, je nutné podporovat takový HW, jaký uživatelé mají. Existuje několik možností:
- Napsat podporu power managementu tak, aby fungovala univerzálně. To je dost práce.
- Přesvědčit výrobce HW, aby kvůli tomu 1% uživatelů odstranili chyby ve firmwaru bdoucích zařízení, a zpětně vydali i firmware pro starší zařízení. Opět je to dost práce.
- Vytvářet drivery pro konkrétní systémy, podle reálného HW, a ne podle nějakých nezávazných specifikací. Opět je to dost práce.
- Napsat utilitu, která si stáhne DB hardwaru, a podle HW konkrétního stroje pozapíná správné options, upraví skripty, přidá do boot line parametry atd. Je to nečisté, ale není to moc pracné.
- Vést o celé věci dlouhé akademické diskuse, a na uživatele se vykašlat.
Zatím to vypadá, že si všichni vybrali tu poslední možnost. Steve Ballmer nemusí Linux nijak potírat. Vývojáři Linuxu to udělají za něj.
Nějak tomu nerozumím.
- Patch Matthew Garretta se snaží pracovat s ASPM bity stejně jako Windows - vyřešeno
- Jevgenij Dodonov zaslal 11. 2. snad už finální patch pro RC6 na SNB - vyřešeno
- Ostatní problémy s power managementem: buď nehlášené, nedostatečně diagnostikované nebo způsobené chybnou konfigurací ze strany uživatele.
Kde že se kdo na uživatele vykašlal či vedl ony diskuse, o kterých mluvíte?
To mi připadá dost alibistické. Notebooky s Linuxem mají už delší dobu problémy s výdrží, a řeší se to na řadě míst, včetně bug reportů distribucí. Co se za tu dobu vyřešilo? Podle tohoto článku, stejně jako podle několika dalších, řešení zatím není. Vymlouvat se na to, že široce známý problém není hlášený, dignostikovaný, nebo že za něj může uživatel? Alibismus. Uživatel má být na prvním místě. Tohle je ukázka nedostatečného testování a nedostatečné spolupráce autorů kernelu s uživateli. A pokud mají pravdu hlasy, které tvrdí, že je vzniklá situace projevem problémů s údržbou kódu kernelu, které přímo souvisejí s jeho architekturou, tak je to fakt špatné.
flosshub.org/system/files/SchachOffutt.pdf
Ty problémy nejsou tak strašné, jak se říká a existuje řada testů, co to potvrzují. Ten "široce známý problém" je s nejvyšší pravděpodobností vyřešený - teď je na uživatelích, aby opravu otestovali a hlásili případné problémy.
Vůbec celý tenhle miničlánek stojí za bačkoru, protože zmíněný blogger zaměnil problém s ASPM za problém s RC6 a pak se děsně divil, jaktože fix na ASPM (které mu očividně fungovalo, jak plyne z jeho předchozích zápisků) neřeší problém s RC6. RC6 už je mimochodem snad konečně zazáplatované také. Pokud má někdo problém i po aplikaci výše zmíněných oprav, nechť použije LKML a problém nahlásí. Samozřejmě by si měl být jist, že má v Lin powersaving nastaven tak, jako v OS, kde má spotřebu menší.
O architektuře nechť si myslí každý co chce, ASPM a RC6 s ní nijak nesouvisí. Když byl problém identifikován, řešení se smrsklo na hledání "největšího společného dělitele" tak, aby oprava nic nerozbila a pokryla co možná nejvíc HW. Upřímně si myslím, že vývojáři odvedli dobrou práci, říct "nekupujte si zabugovaný HW" by bylo mnohem jednodušší a skoro i pochopitelné.
Celou dobu nas tady mystifikujete, ze problem s RC6 je vyreseny ... a neni!!!
Na kernelu 3.2, ktery bude soucasti Ubuntu 12.04 jsou problemy stale!!!
http://www.root.cz/zpravicky/ubuntu-12-04-bude-mit-zapnutou-podporu-rc6-od-intelu/
Skutečne není?
(http://www.phoronix.com/scan.php?page=article&item=intel_rc6_go&num=1)
Změna bude implementována nejspíš až v jádře 3.4, Ubuntu 12.04 má jádro 3.2 a onen patch od Intelu se Canonical zjevně neobtěžoval backportovat. To jen pro pořádek.
To se mi snad zda ... tazke vase argumenty, ze vse je vlastne vyreseno jsou v poradku?! Jen Canonical se neobtezoval backportovat patch do sveho jadra? Vy jste totalni demagog.
Ja tady neustale mluvim o tom, ze problem je setrvaly (99% uzivatelu linuxu totiz pouziva distribuce tak jak jsou a nepatchuji si jadro), navic stejne neni jiste ze ten patch of Intelu funguje jak ma, protoze zadna distribuce dosud tento patch nedokazala implementovat uspesne resp. patch neprokazal svou plnou funkcnost. Takze si dovolim tvrdit, ze problem nebyl dosud vyresen!!!
Ze mam pravdu potvrzuje i Vami citovany clanek ... najednou se tvrdi, ze problem vyresi az jadro 3.4 (To bude v distribucich kdy? Pristi rok?). Pamatuji si doby kdy se tvrdilo, ze to bude jadro 3.2, pak 3.3 a ted az 3.4??!!
Myslim, ze vyvojari kernelu proste naprosto selhali a vy uz se nesnazte furt dokola dokazovat, ze problem je vlastne vyreseny. NENI!!!
Jak si přejete. Pokud je Vám velmi nadějný patch určený k zařazení při nejbližší příležitosti (tedy v merge window jádra 3.4) málo, o moc více toho pro Vás asi nikdo udělat nemůže. Řešení je k dispozici, máte možnost ho otestovat, používat a hlásit problémy, co Vám tedy vlastně schází?
Když už jste šermoval tou demagogií, neškodilo by zamést si před vlastním prahem. Pokud v kauze RC6 někdo selhal, byl to jen a pouze Intel, určitě ne vývojáři jádra jako celek.
V podstate tento problem zasadne diskvalifikuje notebooky na platforme linux z hlediska spotreby energie.
Na základě problémů některých notebooků je najednou celý Linux na noteboocích špatný? Třeba můj Thinkpad W500 vydrží s Kubuntu 11.10 a dva roky starou baterií přes šest hodin (oficiální windowsí čas jsou čtyři hodiny), na Dellu, který jsem měl v práci (s Kubuntu 11.04), to bylo podobné. Ono to totiž vypadá, že na pořádných noteboocích jsou diskvalifikovány spíše ty Windows :-)
Promiňte takto laický dotaz, jak je na tom Android a MeeGo? Případně jiné distribuce/jádra specializovaná vysloveně na mobilní sektor. Zmíněný problémy netrpí? Netýkají se jich? Zcela odlišný HW? ASPM není relevantní?
Jestliže je zvýšená spotřeba pro notebooky "jen" silně otravná chyba, pro mobilní zařízení je to chyba přímo fatální.
