| poslední úprava: 2.6.2007 21:47
Portál AbcLinuxu, 6. listopadu 2025 22:45
2.6.2007 18:55
| Přečteno: 2195×
| Rady
|
| poslední úprava: 2.6.2007 21:47
Tak jsem se po delší době opět dostal k tunění svého placatého přítele (HP nx6110). Od jisté doby, ani nevím od kdy, mi nechce moje Pentium M740 snižovat frekvenci. Prostě pořád běží na maximální frekvenci. Co z toho plyne, jednak spotřebovává relativně hodně energie a druhak se chladič může v obzvláště horkých dnech doslova zbláznit.
Cílem tedy je přinutit procesor ke snižování frekvence CPU. Co budeme potřebovat: dvě vejce, 0.5l mléka, ... né dělám si srandu:) Teď vážně. První co potřebujeme je
samozřejmě podpora v jádře, jak pro Frequency scaling tak pro
ACPI:
# # CPU Frequency scaling # CONFIG_CPU_FREQ=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=m CONFIG_CPU_FREQ_TABLE=mModuly pro
ACPI nebudu ani vypisovat, jsou většinou všude
předvoleny.
Je samozřejmě možné používat i některé deamony jako cpufreqd nebo powersaved. Ale nač používat deamona, když je k dispozici modul. Jak jsem již řekl použijeme služeb jaderných modulů, konkrétně těchto:
cpufreq_ondemand cpufreq_powersave cpufreq_conservative cpufreq_stats acpi_cpufreq freq_tableMožná některé z nich nejsou potřeba, každopádně já mám zavedeny tyto.
Prostředkem pro komunikaci s moduly jsou soubory v /sys/devices/system/cpu/cpu0/cpufreq/
:~$ ls /sys/devices/system/cpu/cpu0/cpufreq/ affected_cpus ondemand scaling_driver stats cpuinfo_cur_freq scaling_available_frequencies scaling_governor cpuinfo_max_freq scaling_available_governors scaling_max_freq cpuinfo_min_freq scaling_cur_freq scaling_min_freqMůžeme nahlédnout do všech souborů, jejich názvy jsou dostatečně výstižné, nebudu je proto komentovat. Ucelenější přehled dostaneme pomocí
cpufreq-info, viz.například:
:~$ cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 0
hardware limits: 800 MHz - 1.73 GHz
available frequency steps: 1.73 GHz, 1.33 GHz, 1.07 GHz, 800 MHz
available cpufreq governors: userspace, ondemand, conservative, powersave, performance
current policy: frequency should be within 800 MHz and 1.73 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz.
Rozsahy frekvencí se mění v souborech scaling_max_freq resp
scaling_min_freq a chování v scaling_governor. Jak je
vidět ja mám zvolen rozsah 1.73GHz - 800MHz a governor = "ondemand". Nastavení
konkrétních parametrů je jednoduché:
cd /sys/devices/system/cpu/cpu0/cpufreq/ echo 800000 > scaling_min_freq echo odemand > scaling_governorSamozřejmě jako
root.
Pro klikače Gnomisty jsem při svém brouzdání narazil na popis zprovoznění appletu pro Gnome-applets, viz. zde. Je zde i poměrně přehledná tabulka taktovacích startegií.
Teď již jen zbývá zařídit, aby se hodnoty nastavovaly například když odpojím AC adaptér, nebo naopak. O tom ale příště protože jsem to ještě pořádně nedoladil.
Jakékoliv náměty na vylepšení, či opravení jsou vítány.
Zdroje:
Kromě toho co jsem uvedl v textu.
Enhanced Intel SpeedStep Technology and Demand-Based Switching on Linux*
WEBlog -- Wouter's Eclectic Blog
Tiskni
Sdílej:
2.6.2007 19:03
pele | skóre: 28
| blog: Bleabr
| UH
To je celkem jednoduchý, na to stačí následující shell skript* (/etc/acpi/battery.sh):
2.6.2007 18:59
#!/bin/sh
if grep 'off-line' /proc/acpi/ac_adapter/C1BA/state; then
echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
else
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
fi
a příslušnej konfigurační soubor (/etc/acpi/events/battery) pro acpid:
event=battery.* action=/etc/acpi/battery.sh %e
*přesný názvy "zařízení" baterek je třeba nastavit "na míru" systému
Super věc
Zas tak super to neni - když jsem začal přemejšlet, že bych to teda napsal do toho FAQ a zkusil to pro jistotu znovu otestovat, zjistil jsem, že to najednou (když jsem ten skript vymejšlel, tak to ale určitě fungovalo 
) až tak úplně nefunguje...
Při přechodu z baterky na AC se to nepřepne zpět. Na vině je to, že /proc/acpi/ac_adapter/C1BA/state se změní o něco později, než dostane acpid informaci o změně napájení (divné, ale je to tak). Problém (i případný problém v "opačném" směru) nicméně spolehlivě řeší sleep na začátku skriptu (před testem stavu napájení)
#!/bin/sh
sleep 1
if grep 'off-line' /proc/acpi/ac_adapter/C1BA/state; then
echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
else
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
fi
Použití ac_adapter místo battery nemá na funkci vliv.
Otázkou spíš je, jak je možný, že acpid dostane informaci od jádra o změně "baterky" dřív, než jádro změní příslušnej soubor v /proc, což je situace proti který nejsou "imunní" ani skripty z Debianu. V době, kdy jsem si ty skripty psal tahle situace nenastávala, takže bych tipoval, že to že to u Debianu s těmi skripty (možná) funguje je způsobeno buď tím, že je tam starší jádro, kde tahle situace nenastane, nebo složitostí těch skriptů - než se dostanou k testu souboru v /proc, je ten už nastavenej správně.
Nesmysl. Jak u battery tak u ac_adapter dostaneš oba dva signály, tzn. odpojení napájení i jeho připojení.
odpojenie adaptera => event=ac_adapter AC 00000080 00000000 pripojenie adaptera => event=ac_adapter AC 00000080 00000001a viac ma nezaujima, ani to ci nahodou nemam BAT1 v ultrabay ani ci sa jedna len o vybratie/zalozie baterky a pod. :)
Ten sleep je v těch Debianích skriptech IMHO až po detekci statusu v /proc. A získání tý informace je mnohem složitější, než jenom jediný grep v /proc. Volají se další skripty, například /usr/bin/on_ac_power (takže dotaz na status v /proc se provádí 2x...) atd. Ale zas tak podrobně jsem ten bordel (zlatej Arch a jeho KISS strategie ) nezkoumal.
3.6.2007 11:39
pele | skóre: 28
| blog: Bleabr
| UH
power.sh, ktery je spousten z event=ac_adapter a vse funguje jak sem si predstavoval.
2.6.2007 21:41
pele | skóre: 28
| blog: Bleabr
| UH
Teorie sice je taková, že spotřeba CMOSu je nejvýrazněji závislá na frekvenci přepínání hradel
Ne tak docela.. jako obecnej vzorec pro ztrátovej výkon CMOSu se udává P = c·V²·f, kde c je technologická konstanta. Rostoucí podíl parazitních proudů na ztrátovém výkonu je nicméně taky fakt (bodejť by ne, když jsou dneska hradla tranzistorů "vysoký" jen jednotky atomovejch vrstev...)
Klasický CMOS (4xxx) je sice na napětí celkem nenáročný, ale dnešní procesor má podstatně méně prostoru pro změnu voltáže mezi podpětím (leda, že by se voltáž a frekvence měnily synchronně, což je modus operandi speedstepu) a vyhořením, takže až donedávna nebyly nějaké úpravy napájení moc na pořadu dne. Jsou na to i nějaké husté patenty, přinejmenším jeden od Chucka Moorea. 
Možná jsem měl napsat "pokud nevezmeme v úvahu změny napětí a zaměříme se jen na to, co se v těch hradlech děje".
Zrušíte tím ztrátový výkon a tím i produkci tepla. Jenom musíte dávat pozor, aby vám to nequenchlo jako náš supravodivý magnet na NMR
. Povolil jsem v jadru timer s vysokym rozlisenim. Pocet preruseni klesl na 50 v idle, a priblizne 120 pri praci. Teplota klesa z 47 stupnu na 40. Spotreba 11.5W, vydrz 4.7 hodiny.
Podminky nejsou uplne ferovy - mam vypnuty amarok a lifereu, protoze zrejmne maji nejaky bugy, kvuli kterym se budi zbytecne casto. ehci taky pusobilo casty preruseni procesoru, po te co jsem z nej udelal moduly je to uz v poradku. Ale nemam tady zadny usb zarizeni, abych vyzkousel, jak se jeho pripojeni projevi.
2.6.2007 21:44
pele | skóre: 28
| blog: Bleabr
| UH
/sys, ale stačí použít nástroj cpufreq-set.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.