Porovnanie spotreby jadier

12.11.2011 20:15 | Přečteno: 2183× | Žumpa | poslední úprava: 13.11.2011 01:58

Rozhodol som sa spraviť toto meranie, pretože už ma štve prístup robme testy na spotrebu stále len pre Intel, keď sa sekneme tak je to ASPM a generalizujme výsledky o jadre. Hoci som rád že tu je portál ako Phoronix, ale toš člověk nekdy ...

Distro Linux MINT 11 64-bit

sudo dmidecode -s baseboard-manufacturer
ASUSTeK Computer INC.

sudo dmidecode -s baseboard-product-name
M4N68T-M-V2

nvidia-settings -v (skrátený výpis)
/usr/share/themes/Murrina-Blue/gtk-2.0/gtkrc:59: Murrine configuration option "scrollbar_color" is no longer supported and will be ignored.

nvidia-settings:  version 285.05.09

cat /proc/cpuinfo (skrátený a celé si to dajte krát dva pretože je to dvojjadro)
vendor_id	: AuthenticAMD
model name	: AMD Athlon(tm) II X2 250 Processor
cpu MHz		: 800.000
cache size	: 1024 KB
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save
bogomips	: 6027.56
power management: ts ttp tm stc 100mhzsteps hwpstate

lspci
00:00.0 RAM memory: nVidia Corporation MCP61 LPC Bridge (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2)
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:08.1 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control
02:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 8400 GS] (rev a1)

Použitý merací prístroj:
Silver Crest
Model-No.: 9149

Config pre Kernel 3.1.1 som použil vlastný, pre 2.6.38-8 a 2.6.37 distribučný pretože som mal problém s kompiláciou, ale zistil som, že je to len light bug a stačilo zmeniť CONFIG_XEN=y->n. Jadro 3.1.1, 2.6.37 vanilka a 2.6.38-8 distribučné.

Aktivita/Jadro	Kernel 3.1.1	Kernel 2.6.38-8	Kernel 2.6.37
Procesor do 3%	63W	63W	63W
Enemy Territory	93-100W	93-100W	93-100W

Vyzerá to neuveriteľne s porovnaním na Phoronixe, rád by som im dal za pravdu, ale vynášať radikálne súdy je tak populárne. Sám som nečakal, že to takto dopadne, pár hodín som s tým zabil, ale popri tom som aj surfoval programoval a až neuveriteľne rovnako lietala spotreba. Určite na nejakom HW, čo sa týka notebookov to bude poznať, ale nedávno sa tu strhla debata o tom ako budú žrať serveri atď. Takže budte v klude a čakajte na Wolfa ktorý je už na ceste :)

Práve píšem z jadra 2.6.37 a fakt nieje nič poznať, tie jadrá sa správajú ako jedno. Čakal som problém, že 2.6.37 nezožerie najnovší NVidia ovládač, ale aj tu to bolo OK. Proste rozdiel ani jeden Watt nechápem ako niekto môže generalizovať podľa pár notebokov, keď bola tá správička o 30% zvýšenej spotrebe. Inak tento istý stroj žral v kľude s 32bit Ubuntu 62W, takže rozdiel jeden Watt.

EDIT: Ešte dopĺňam, že k meraniam ma dohnalo viacero zdrojov, ale rozpútal to pred časom Phoronix o opisovaní problémov so spotrebou v jadre. Koho zaujímalo že či sa to týka aj krabíc z AMD môže byť v kľude, možno som niekomu ušetril čas s meraním.

http://www.phoronix.com/scan.php?page=article&item=linux_31_power_regress&num=1        

Komentáře

[Limoto]

Jenže problém je v tom, že se na těch notebookách nevyužívá ASPM, což je funkce, která se u desktopů vůbec nepoužívá, takže tyhle měření o tom vůbec nic nevypovídají.

[Bedňa]

O tom vieme, ale čo nedávny článok na Phoronixe, zvýšenie spotreby Linuxu o 30%? Sú to kecy a nenapíšu na niektorých notebookoch môže stúpnuť spotreba a keď máte bastl menom SandyBridge tak aj o 30%. Po tejto správičke sa strhla diskusia o tom ako budú žrať servery o 30% a čo to bude znamenať pre serverové farmy a pritom ide o kulové. Je to kačica prvého rangu.

[Bedňa]

Zápisok som doplnil o odkaz na

http://www.phoronix.com/scan.php?page=article&item=linux_31_power_regress&num=1

Affected systems can easily see a 30% increase in power consumption simply when comparing the Linux 3.0 kernel to the current code being assembled for Linux 3.1.

[Mrkva]

Affected systems!!! Affected systems!!! Affected systems!!! Víš vůbec, co to znamená? :)

[Martin Mareš]

Poněkud afektované chování jednoho z diskutujících?

Jinak si nicméně myslím, že Phoronix dělá z komára velblouda – problém sice existuje, ale projevuje se na poměrně malé množině strojů.

[Bedňa]

Sériou článkov spustili dojem že sa niečo v jadre rozbilo a pritom sa to prejavuje len na rozbitom HW.

[ehm ehm]

viz moje odpověď ve zprávičce o Midori.

[Mrkva]

Ani ne, jen mi to přišlo nutné nějak zvýraznit. Phoronix z toho sice dělá senzaci, ale pokud vím nikde netvrdí že "Linux žere o 30% víc na všech systémech". Oproti tomu, autor tohohle blogu se tváří jakože žádný problém neexistuje.

[ehm ehm]

+1 btw. Bez té senzačnosti by řešení problému nejspíš trvalo mnohem déle.

[Martin Mareš]

To netvrdí. Ale seriózně psaný článek by upozornil na to, že problém nastává jen na poměrně malé množině strojů. A navíc to velmi pravděpodobně není bug v kernelu, nýbrž bug ve firmware těchto strojů. Jenže lehce bulvární pan novinář holt chtěl přimět kernelové vývojáře, aby se postarali o jeho bolístku...

Problémů tohoto ražení ("autoři firmware stroje X přemýšleli kolenem, takže je potřeba přidat do jádra další hack, který kolenu zvyšuje IQ") jsou stovky, to, že někdo vyřešil tenhle, dost možná znamená, že neměl čas vyřešit jiný, možná závažnější.

[Migi]

inako esli ASPM na notebooku běží by se mělo dát zjistit z výpisu

cat /sys/module/pcie_aspm/parameters/policy

Pokud výpis obsahuje položku powersave tak ASPM běží, pokud ne, tak neběží. Dobrodruzi mohou spustit parametrem jádra

GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=force"

v /etc/default/grub (poté třeba spustit sudo update-grub).

Viz root.