# [OT] segnalazione powertop

## comio

Ciao,

volevo segnalarvi questo tool di tuning del risparmio energetico: poewertop

E' usabile sia su x86 e su x86_64 anche se ci sono delle limitazioni in base al kernel (vedere il sito!).

C'è chi ha proposto anche un ebuild (che non ho testato): sys-power/powertop-1.0 (new Package)

a me ha detto di attivare delle opzioni del kernel per risparmiare un po' di corrente...  :Very Happy: 

ciao

luigi

----------

## riverdragon

Sembra semplicemente meraviglioso. Sul sito poi ci sono anche alcune patch da applicare al kernel, a firefox... ci provo!

Passo subito al kernel 2.6.21 (incrocio le dita, voglio rimanere con la vecchia libata) così da vedere quanto riesco a risparmiare!

EDIT: sei riuscito ad attivare l'opzione CONFIG_TIMER_STATS nel kernel? Io ancora no, e powertop non mi dà alcun consiglio utile.

Inoltre, nonostante io abbia compilato la versione da cvs (indispensabile per il kernel 2.6.21) acpi4asus non carica il modulo, e la versione 0.32-r1 non riesce più nemmeno a finire la compilazione.

Non trovo che abbia senso tenere il kernel 2.6.21 per cercare di ridurre i consumi quando l'assenza del modulo che gestisce la luminosità dello schermo mi preclude la fetta maggiore di questi risparmi. Torno all'ultimo kernel stabile, il 2.6.20-r8. Ultimamente gli aggiornamenti del kernel, per un motivo o per l'altro, finiscono sempre con la ricompilazione del kernel vecchio.  :Sad: 

EDIT2: CONFIG_TIMER_STATS è presente solo nel kernel 2.6.21, si abilita da Kernel hacking -> Kernel debugging -> Collect kernel timers statistics.

----------

## .:deadhead:.

strabello, l'ho provato e devo dire che è molto carino. Usate la versione da SVN: ho segnalato sul canale IRC del programma alcune migliorie che il devel ha prontamente apportato.

Interessante sopratutto i consigli sulle opzioni da attivare o disattivare nel kernel.

----------

## skypjack

Bella Comio, ma come le trovi?

Appena ho un minuto lo provo... Dell'ebuild che sai dirmi?

----------

## comio

 *skypjack wrote:*   

> Bella Comio, ma come le trovi?

 

bo, quando capitano.

 *Quote:*   

> 
> 
> Appena ho un minuto lo provo... Dell'ebuild che sai dirmi?

 

Per l'ebuild svn (dirty&quick):

```

# Copyright 1999-2007 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

inherit eutils linux-info subversion

ESVN_REPO_URI="http://powertop.googlecode.com/svn/trunk/"

#If you want to know when this package will be marked stable please see the Changelog

RESTRICT="nomirror nostrip"

DESCRIPTION="Power usage is a hot topic for computer users everywhere."

HOMEPAGE="http://www.linuxpowertop.org/"

SRC_URI=""

LICENSE="GPL-2"

SLOT="0"

KEYWORDS="~amd64 ~x86"

DEPEND=""

RDEPEND="${DEPEND}"

S="${WORKDIR}/${PN}"

src_compile() {

        cd ${WORKDIR}/powertop

        emake || die

}

src_install() {

        cd ${WORKDIR}/powertop

        exeinto /usr/bin

        doexe powertop

        dodoc COPYING

        dodoc README

}

```

poi sul bugzilla ho visto che qualcuno ha postato un ebuild.

ciao

----------

## .:deadhead:.

in genere anche io consiglio ebuild etc etc... 

Ma questi sono 4 file di numero: un readme ed un Makefile e 2 .c

fate prima ad andare in temp e lanciare 

```
svn checkout http://powertop.googlecode.com/svn/trunk/ powertop && cd powertop && make
```

buon divertimento  :Very Happy: 

----------

## skypjack

Ok, thanks!!

Come detto, oggi non ci sto di testa, ma appena posso provo!!

Grazie delle indicazioni...

----------

## riverdragon

Ma voi usate tutti già il kernel 2.6.21?

----------

## skypjack

Ma perchè dice di settare l'inesistente CONFIG_TIMER_STATS nel kernel?????

Ok, visto: ho un kernel .20!!

Aggiorno e riprovo...

----------

## riverdragon

Sono riuscito a far funzionare tutto con il 2.6.21 (maledette opzioni nascoste!) e ora devo già ricompilare il kernel per togliere l'opzione CONFIG_IRQBALANCE.

Comunque, ottimo.

EDIT: powertop mi mostra questo

```
< Detailed C-state information is only available on Mobile CPUs (laptops) >
```

...non va bene. Ho un core duo, non capisco perché non riconosca il processore. Aiuti?

----------

## comio

 *riverdragon wrote:*   

> Sono riuscito a far funzionare tutto con il 2.6.21 (maledette opzioni nascoste!) e ora devo già ricompilare il kernel per togliere l'opzione CONFIG_IRQBALANCE.
> 
> Comunque, ottimo.
> 
> EDIT: powertop mi mostra questo
> ...

 

caricato ACPI&co?

ciao

luigi

----------

## .:deadhead:.

 *riverdragon wrote:*   

> Sono riuscito a far funzionare tutto con il 2.6.21 (maledette opzioni nascoste!) e ora devo già ricompilare il kernel per togliere l'opzione CONFIG_IRQBALANCE.

 Potrebbe non esserci nel kernel gentoo. Io almeno usando il kernel standard gentoo non ce l'avevo su un centrino. Ho scritto al devel per fargli notare che se l'opzione non c'è nel kernel, sarebbe meglio passare oltre e nel SVN l'ha fatto. Prova ad usare quella release  :Wink: 

----------

## riverdragon

@comio: acpi attivato, cpufreqd attivo... 

EDIT: forse è solo un problema di powertop, qui lo ammette anche lo sviluppatore.

@deadhead: l'opzione CONFIG_IRQBALANCE c'è, quella nascosta è quella per attivare il supporto nuovo (asus-laptop anziché asus_acpi) ai portatili asus, che viene visualizzata solo con una combinazione di altre opzioni attivate o disattivate, e prima di ieri mi impediva di usare un kernel successivo al 2.6.20. Uso anche io powertop da svn, nella speranza che funzioni il riconoscimento dei miei c-states, senza successo.

----------

## Guglie

ci ho giocato un po' oggi

kernel 2.6.21.1, 2 utenti loggati, sessione X con xfce, aperti firefox con un 3 tabs, claws-mails, pidgin, liferea e una shell urxvt:

- configurazione che usavo prima: consumo oscillante fra i 20-22 W

- dopo aver abilitato le opzioni consigliate e la patch al kernel: consumo oscillante fra i 16-16.5 W

il che - se il programma funziona - implicherebbe una riduzione del consumo di circa il 20%.

appoggiandosi però il programma ad acpi e avendomi dato acpi in passato risultati un po' sballati non mi sbilancio troppo..

voi invece che consumi avete?

----------

## skypjack

Ok, mi avete convinto: gentoo-sources in package.keywords e lo provo!!

Se riduce così tanto, è una manna per me, farebbe guadagnare un bel pò di giorno al mio pc (e di ore alla batteria!)...

Speriamo bene!!

@guglie: che problemi hai avuto in passato con acpi? Spiegati meglio, per favore...Last edited by skypjack on Tue May 15, 2007 10:10 am; edited 1 time in total

----------

## riverdragon

Per me il consumo è molto maggiore, con la patch al kernel e due opzioni disattivate (CONFIG_HPET_ECCETERA e CONFIG_IRQBALANCE) arrivo a 18 W e mezzo, circa; prima ero a 21.

Sto ancora aspettando l'aggiornamento che permetterà di vedere i miei c-states, dal link segnalato nel mio post precedente il bugfix dovrebbe essere integrato a breve, ieri sera ancora non funzionava.

@skypjack: non serve package.unmask, basta package.keywords.

----------

## skypjack

Si, sul package.unmask è stato un lapsus, che ho corretto, ma mi hai preceduto!! Sorry...

Sto ricompilando il .21 e poi provo powertop... Speriamo bene!!

[EDIT]: Nessun suggerimento!!

```

    PowerTOP version 1.0       (C) 2007 Intel Corporation                       

Cn          Avg residency (5s)  Long term residency avg

C0 (cpu running)        (11.7%)

C1                0.0ms ( 0.0%)                   0.0ms

C2                0.6ms (88.3%)                   0.5ms

Wakeups-from-idle per second :  3067.8 

Top causes for wakeups:

  24.7%        <interrupt> : uhci_hcd:usb2, HDA Intel 

  21.9%        <interrupt> : i915@pci:0000:00:02.0 

  11.6%              beryl : schedule_timeout (process_timeout) 

  11.5%        firefox-bin : schedule_timeout (process_timeout) 

   5.1%        <interrupt> : ipw3945, eth0 

   5.1%               Xorg : do_setitimer (it_real_fn) 

   4.7%      mixer_applet2 : schedule_timeout (process_timeout) 

   3.6%           cpufreqd : queue_delayed_work_on (delayed_work_timer_fn) 

   2.1%           cpufreqd : cpufreq_governor_dbs (delayed_work_timer_fn) 

   2.1%     gnome-terminal : schedule_timeout (process_timeout) 

Suggestion: Enable the CONFIG_USB_SUSPEND kernel configuration option.

This option will automatically disable UHCI USB when not in use, and may

save approximately 1 Watt of power.

```

Le dieci cause maggiori di wake-up non vedo come potrei eliminarle, in realtà, ma ogni consiglio è ben accetto!!

La proposta sul CONFIG_USB_SUSPEND credo sia di default o me la spari lì per via del mouse usb attaccato, perchè l0opzione è già attiva nel kernel.

Sono scemo io o ho un kenrel già configurato abbastanza bene?

Offendetemi, non vi riguardate, se non capisco...

----------

## flocchini

io ho messo il .21 ma config timer stats mica c'e'... Mi sono perso qualche passaggio? Cosa devo attivare?   :Rolling Eyes: 

----------

## skypjack

 *riverdragon wrote:*   

> EDIT2: CONFIG_TIMER_STATS è presente solo nel kernel 2.6.21, si abilita da Kernel hacking -> Kernel debugging -> Collect kernel timers statistics.

 

Secondo post, bastava leggere...  :Rolling Eyes: 

----------

## flocchini

che idiota era sotto kernel debugging... oooops   :Embarassed: 

----------

## skypjack

 *flocchini wrote:*   

> Se ci fosse sarei d'accordissimo con te 

 

Non l'ho capita, scusa. Se non ci fosse, io da dove avrei preso quell'informazione riportata da riverdragon???

Ok, dai, la risposta l'hai avuta, chiudiamo qua!!

----------

## Guglie

 *skypjack wrote:*   

> @guglie: che problemi hai avuto in passato con acpi? Spiegati meglio, per favore...

 

- quando la batteria scende sotto il 3% non mi da più la capacità rimanente

- la mia batteria non si consuma linearmente, ovvero: da 100 a 80 si scarica in ad es. 10 min, mentre da 50 a 30 in 20 min

----------

## riverdragon

Che la batteria non si scarichi regolarmente è normale, non è un problema di acpi.

Per chi non riesce a vedere i propri c-states, lo sviluppatore non ha ancora modificato il metodo di calcolo, quantomeno da svn non risulta. Ho provato a mettere un po' le mani sul codice, forzando la variabile al maxcstate contenuto di /sys/module/processor/parameters/max_cstate ma ovviamente poi ci sono da valutare i singoli c-state, qui mi risulta sempre al 100%. Spero che sistemi la cosa in fretta, e che aggiunga altri suggerimenti!

Al momento sono presenti suggerimenti solo per Beagle, CONFIG_USB_SUSPEND, CONFIG_CPU_FREQ_GOV_ONDEMAND, CONFIG_HPET e CONFIG_IRQBALANCE.

P.S. la nuova versione spiega anche dove trovare l'opzione CONFIG_TIMER_STATS  :Wink: 

----------

## Dece

 *riverdragon wrote:*   

> Per me il consumo è molto maggiore, con la patch al kernel e due opzioni disattivate (CONFIG_HPET_ECCETERA e CONFIG_IRQBALANCE) arrivo a 18 W e mezzo, circa; prima ero a 21

 

Per ora ho provato solo a seguire in consigli di powertop senza applicare le patch: scusa l'ignoranza ma da dove riesci a leggere il consumo in watt?

----------

## .:deadhead:.

lo sviluppo continua frenetico... Usate SVN  :Very Happy: 

----------

## flocchini

 *riverdragon wrote:*   

> 
> 
> Al momento sono presenti suggerimenti solo per Beagle, CONFIG_USB_SUSPEND, CONFIG_CPU_FREQ_GOV_ONDEMAND, CONFIG_HPET e CONFIG_IRQBALANCE.
> 
> P.S. la nuova versione spiega anche dove trovare l'opzione CONFIG_TIMER_STATS 

 

ma sono ciecato io o questi consigli sono nelal sezione "tips & tricks" sul sito e basta? Dove li vedo gli altri?

E perche' non mi fa vedere i watt di consumo?   :Rolling Eyes: 

O non ho trovato io la doc oppure mi pare davvero un po' criptico sto coso :p

----------

## riverdragon

Il consumo in watt si vede staccando l'alimentazione di linea e lasciando il portatile a batteria.

I suggerimenti di cui parlavo prima sono presenti nel codice, e vengono visualizzati solo se il programma li ritiene utili; sul sito sono presenti suggerimenti diversi.

----------

## flocchini

ti ringrazio. Quindi se mi suggerisce solo il suspend delle usb (che non posso usare x problemi di audio) significa che il resto e' a posto... Dopo undocko e vedo quanto consumo :p

----------

## Dece

Veramente io continuo a non vedere il consumo in watt...  :Confused: 

----------

## riverdragon

Piccola nota di colore: quando la intel ha sviluppato i driver per la scheda wireless ipw3945 notizia è giunta al mondo quando i sorgenti erano ad una versione 0.0.X; hanno proceduto così prudentemente con le versioni che la versione 0.0.69 è diventata la 1.0

Ora invece la prima versione pubblica di powertop è la 1.0, e nel giro di qualche giorno siamo già alla 1.2  :Very Happy: 

----------

## unz

```
    PowerTOP version 1.2       (C) 2007 Intel Corporation                       

Cn          Avg residency (5s)  Long term residency avg

C0 (cpu running)        (14.5%)

C1                0.0ms ( 0.0%)                   0.0ms

C2                0.6ms (30.7%)                   0.9ms

C3                0.7ms (54.8%)                   1.1ms

Wakeups-from-idle per second :  2614.8 

Power usage (ACPI estimate) :   0.0 W (0.7 hours left)

Top causes for wakeups:

  47.0% (491.0)       <interrupt> : i8042 

  27.0% (281.8)       firefox-bin : schedule_timeout (process_timeout) 

   9.6% (100.0)       cpufreq-set : queue_delayed_work_on (delayed_work_timer_ 

   3.7% (38.6)   at-spi-registry : schedule_timeout (process_timeout) 

   3.4% (35.8)                   : do_setitimer (it_real_fn) 

   2.6% (26.8)       <interrupt> : ipw3945 

   1.9% (20.2)                   : schedule_timeout (process_timeout) 

   1.3% (13.8)       <interrupt> : libata 

   0.9% ( 9.6)       <interrupt> : acpi 

   0.5% ( 5.0)          modprobe : start_polling (acerhk_poll_event) 

Suggestion: Enable the CONFIG_SND_AC97_POWER_SAVE kernel configuration option.

This option will automatically power down your sound codec when not in use,

and can save approximately half a Watt of power.

```

Ma anche a voi segna power usage 0.0? O è un mio problema?

Poi quel consiglio sull'AC97 non è presente nei gentoo-sources, c'è un kernel di riferimento?

Ulteriore info ... le patch proposte nel sito qualcuno le ha applicate? Se mi devo riscrivere gli ebuild e ricompilare tutto per guadagnare 2 minuti di batteria ... me lo risparmio  :Very Happy: 

----------

## riverdragon

Anche a me ha consigliato di abilitare CONFIG_SND_AC97_POWER_SAVE, ma ho scoperto che viene visualizzata solo se attivi il supporto ai chipset audio intel-boh-ac97. Io uso il supporto intel-hda quindi l'opzione per me non è utile (e immagino neanche per te): il supporto ac97 non è mai attivo quindi non ha senso permettere al kernel di farlo fermare temporaneamente.

----------

## ashlar

 *Quote:*   

> 
> 
>     PowerTOP version 1.2       (C) 2007 Intel Corporation                       
> 
> Cn          Avg residency (5s)  Long term residency avg
> ...

 

Questo è quello che mi vede, non mi da info riguardo al powerusage... sapete perchè?

P.S. il mio portatile è un sony fe11h

----------

## unz

Staccato il cavo d'alimentazione?

----------

## riverdragon

Pensa che a me non riesce a riconoscere i c-states... E ho un core duo, quindi intel!

----------

## ashlar

anche staccando il cavo di alimentazione il risultato non cambia

----------

## ashlar

Per provare ho scaricato powertop da svn e adesso mi ha aggiunto questo nuovo consiglio:

 *Quote:*   

> 
> 
> Cn          Avg residency (5s)  Long term residency avg
> 
> C0 (cpu running)        ( 5,1%)
> ...

 

Ho provato ad abilitare ciò che chiede ma proprio non riesco a trovarlo qualcuno che lo ha fatto può mettere passo passo quali voci abilitare/disabilitare del kernel?

----------

## riverdragon

C'è un mio post a riguardo proprio in questa pagina.

----------

## ashlar

 *riverdragon wrote:*   

> C'è un mio post a riguardo proprio in questa pagina.

 

si avevo letto la tua risposta, ma tu come hai fatto a eliminare quel messaggio?

----------

## unz

 *riverdragon wrote:*   

> Pensa che a me non riesce a riconoscere i c-states... E ho un core duo, quindi intel!

 

Io pure, quelo che ho incollato sopra è un Core Duo i686 Genuine Intel(R) CPU T2300 @ 1.66GHz GenuineIntel GNU/Linux

----------

## riverdragon

 *ashlar wrote:*   

>  *riverdragon wrote:*   C'è un mio post a riguardo proprio in questa pagina. 
> 
> si avevo letto la tua risposta, ma tu come hai fatto a eliminare quel messaggio?

 Non lo elimini, e` un problema del programma che non capisce che e` fuori luogo. Ignoralo e basta.

 *unz wrote:*   

> Io pure, quelo che ho incollato sopra è un Core Duo i686 Genuine Intel(R) CPU T2300 @ 1.66GHz GenuineIntel GNU/Linux

 Mi posteresti qui la parte del tuo .config del kernel relativa a "processor type and features"?

----------

## ashlar

 *riverdragon wrote:*   

>  *ashlar wrote:*    *riverdragon wrote:*   C'è un mio post a riguardo proprio in questa pagina. 
> 
> si avevo letto la tua risposta, ma tu come hai fatto a eliminare quel messaggio? Non lo elimini, e` un problema del programma che non capisce che e` fuori luogo. Ignoralo e basta.
> 
> 

 

Lo chiedevo perchè ho visto dagli altri "consigli" che powertop mi ha dato in precedenza, che passa alle altre configurazioni del kernel una volta che tu hai tolto quello che lui crede essere un possibile dispendio di energia.

----------

## unz

 *riverdragon wrote:*   

>  *unz wrote:*   Io pure, quelo che ho incollato sopra è un Core Duo i686 Genuine Intel(R) CPU T2300 @ 1.66GHz GenuineIntel GNU/Linux 
> 
> Mi posteresti qui la parte del tuo .config del kernel relativa a "processor type and features"?

 

Mmm non credo sia quello il punto. Lì ho segnato SMP, e pentiumm

Credo sia più una cosa di acpi, che ti incollo

```
#

# ACPI (Advanced Configuration and Power Interface) Support

#

CONFIG_ACPI=y

CONFIG_ACPI_SLEEP=y

CONFIG_ACPI_SLEEP_PROC_FS=y

CONFIG_ACPI_SLEEP_PROC_SLEEP=y

# CONFIG_ACPI_PROCFS is not set

CONFIG_ACPI_AC=y

CONFIG_ACPI_BATTERY=y

CONFIG_ACPI_BUTTON=y

CONFIG_ACPI_VIDEO=y

CONFIG_ACPI_FAN=y

# CONFIG_ACPI_DOCK is not set

CONFIG_ACPI_PROCESSOR=y

CONFIG_ACPI_HOTPLUG_CPU=y

CONFIG_ACPI_THERMAL=y

# CONFIG_ACPI_ASUS is not set

# CONFIG_ACPI_IBM is not set

# CONFIG_ACPI_TOSHIBA is not set

CONFIG_ACPI_BLACKLIST_YEAR=0

# CONFIG_ACPI_DEBUG is not set

CONFIG_ACPI_EC=y

CONFIG_ACPI_POWER=y

CONFIG_ACPI_SYSTEM=y

CONFIG_X86_PM_TIMER=y

CONFIG_ACPI_CONTAINER=y

CONFIG_ACPI_SBS=y

#

# APM (Advanced Power Management) BIOS Support

#

# CONFIG_APM is not set

#

# CPU Frequency scaling

#

CONFIG_CPU_FREQ=y

CONFIG_CPU_FREQ_TABLE=y

# CONFIG_CPU_FREQ_DEBUG is not set

CONFIG_CPU_FREQ_STAT=y

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=y

CONFIG_CPU_FREQ_GOV_POWERSAVE=y

CONFIG_CPU_FREQ_GOV_USERSPACE=y

CONFIG_CPU_FREQ_GOV_ONDEMAND=y

CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

#

# CPUFreq processor drivers

#

CONFIG_X86_ACPI_CPUFREQ=y

# CONFIG_X86_POWERNOW_K6 is not set

# CONFIG_X86_POWERNOW_K7 is not set

# CONFIG_X86_POWERNOW_K8 is not set

# CONFIG_X86_GX_SUSPMOD is not set

CONFIG_X86_SPEEDSTEP_CENTRINO=y

# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set

CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y

CONFIG_X86_SPEEDSTEP_ICH=y

CONFIG_X86_SPEEDSTEP_SMI=m

CONFIG_X86_P4_CLOCKMOD=m

# CONFIG_X86_CPUFREQ_NFORCE2 is not set

# CONFIG_X86_LONGRUN is not set

# CONFIG_X86_LONGHAUL is not set

# CONFIG_X86_E_POWERSAVER is not set

#

# shared options

#

# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set

CONFIG_X86_SPEEDSTEP_LIB=y

CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y
```

----------

## riverdragon

Invece potrebbe essere proprio quello, io come processore ho impostato pentium4 (coerentemente con le indicazioni che dicono di usare -march=prescott per gcc). Provo a ricompilare con pentium-m e vediamo.

@ashlar: se vuoi puoi aprire il file powertop.c e andare in fondo a leggere tutti i suggerimenti che può proporre, sono quattro o cinque in tutto.

----------

## gioi

 *riverdragon wrote:*   

> Invece potrebbe essere proprio quello, io come processore ho impostato pentium4 (coerentemente con le indicazioni che dicono di usare -march=prescott per gcc). Provo a ricompilare con pentium-m e vediamo.
> 
> @ashlar: se vuoi puoi aprire il file powertop.c e andare in fondo a leggere tutti i suggerimenti che può proporre, sono quattro o cinque in tutto.

 

Scusa river ma un core duo non è sicuramente un pentium4 che, in teoria, è basato sull'architettura netburst completamente diversa dalla core sia in quanto a profondità della pipeline, che a cache ecc ecc

Al max, ma proprio al max, se proprio non vuoi usare pentium-m dovresti usare pentium3 (da cui deriva il pentium-m), di sicuro non pentium4 che è totalmente diverso...

Anche l'abilitazione dell'smp del pentium 4, poi, è mooolto diversa, perchè scaturisce dall'HT e non da una reale implementazione di routine SMP, ma qui le scuole di pensiero sono le più disparate...

----------

## riverdragon

C'è una lunga discussione qui sul forum italiano dove si parla di quello. Per il compilatore non c'è differenza tra core duo (non core2) e pentium4; -march=prescott è uguale a -march=pentium-m -msse3, anche qui dicono uguale.

L'unica cosa che posso presumere è che impostando il kernel per un pentium4/pentium4M eccetera le opzioni di scaling della cpu siano attivate diversamente; tuttavia ogni volta che ci penso sono sempre meno convinto che la strada sia questa.

----------

## gioi

 *riverdragon wrote:*   

> C'è una lunga discussione qui sul forum italiano dove si parla di quello. Per il compilatore non c'è differenza tra core duo (non core2) e pentium4; -march=prescott è uguale a -march=pentium-m -msse3, anche qui dicono uguale.
> 
> L'unica cosa che posso presumere è che impostando il kernel per un pentium4/pentium4M eccetera le opzioni di scaling della cpu siano attivate diversamente; tuttavia ogni volta che ci penso sono sempre meno convinto che la strada sia questa.

 

Sono al corrente delle "disquisizioni"(più che discussioni in materia  :Razz:  ) e le argomentazioni portate da una parte e dall'altra sono ora convincenti ora del tutto ipotetiche, quindi sinceramente, se dovessi scegliere la "configurazione" più performante non saprei scegliere, perchè anche cronometro alla mano, la vedo dura trovare differenze apprezzabili di prestazioni.

Il mio discoro, in generale, riguarda un utilizzo "SAFE" la cui filosofia dovrebbe essere più o meno: nel dubbio utilizza l'opzione più generalistica possibile.

Sicuramente scegliendo pentium-m o pentium3 si corre il rischio di perdere ottimizzazioni comuni tra i processori core ed i pentium4 (anche se appartenenti a differenti famiglie di architetture, non mi sembra improbabile che vi sia stato un travaso di tecnologia tra quanto di buono c'era su netburst e l'attuale architettura core e core 2 basata sui pentium-m.

Tuttavia, basandomi sulle mie sole (poche) conoscenze, di ottimizzazioni a livello di microcodice (c'ho fatto la tesi di laurea, quindi sono nozioni solo a livello di algoritmi e di teorie), la lunghezza della pipeline è un fattore imprescindibile per fare scelte ottimali riguardanti le ottimizzazioni (scusate la ripetizione) di codice macchina. E la differenza in questo caso è abissale essendo rientrati dai 30 e passa stadi della netburst a valori più umani nei processori core e core 2 (sia single che duo).

Per questo IMHO, alla fine, tutti i vantaggi che si potrebbero acquisire dalle ottimizzazioni mancanti nel profilo pentium-m rispetto a quello pentium4, sarebbero del tutto vanificati nell'errata impostazione della lunghezza ottimale di gruppi di istruzioni processate, in virtù dell'errato calcolo della dimensione massima della catena di pipeline...

ovviamente IMHO

----------

## riverdragon

Vero, ma la discussione si e` arenata nel momento in cui e` uscita una risposta di uno sviluppatore gcc, che diceva che il core duo e` corretto ottimizzarlo come il prescott. Visto che alla fine chi decide e` gcc...

Concordo sul fatto che non ho notato nessuna differenza quando sono passato da -march=pentium-m a -march=prescott.

----------

## gioi

 *riverdragon wrote:*   

> Vero, ma la discussione si e` arenata nel momento in cui e` uscita una risposta di uno sviluppatore gcc, che diceva che il core duo e` corretto ottimizzarlo come il prescott. Visto che alla fine chi decide e` gcc...
> 
> Concordo sul fatto che non ho notato nessuna differenza quando sono passato da -march=pentium-m a -march=prescott.

 

No, aspetta forse mi sono perso io da qualche parte, stiamo parlando di due cose diverse...

tu parli delle use flags io del tipo di processore da scegliere nel kernel... credevo che l'argomento del discorso fosse quello...

Per le use flags, la corretta è appunto prescott!

----------

## riverdragon

Visto che il kernel viene compilato da gcc non credo che ci sia differenza... sbaglio?

----------

## gioi

 *riverdragon wrote:*   

> Visto che il kernel viene compilato da gcc non credo che ci sia differenza... sbaglio?

 

Mi son perso nella discussione, e non sono un kernel-devel, però credo che la scelta del processore nell'appositò menu del kernel influenzi profondamente vari aspetti della compilazione del kernel stesso... a partire dalla possibilità o meno per il sistema di sfruttare determinate features hw (tipo risparmio energetico, et similia), per continuare con le varie estensioni multimediali (un'errata abilitazione/disabilitazione delle quali potrebbe influenzare il funzionamento stesso di programmi come mplayer et similia)...

Poi non so...

credo che il discorso processore per quanto riguarda gcc ti dica "come" compilare, mentre per il kernel ti dica "cosa"...

----------

## riverdragon

Comunque:

ho scoperto un'opzione sulle statistiche del processore non attiva, ma attivarla non mi ha mostrato i c-states;

ho infine compilato il kernel come pentium m, ma tuttora powertop non riesce a mostrarmi niente.

----------

## ashlar

Dopo tre giorni di smanettamento sono ancora nella condizione in cui powertop non mi mostra i watt al secondo come ho visto in altri screen ciò che mi mostra è solo questo:

 *Quote:*   

> 
> 
> Cn          Avg residency (5s)  Long term residency avg
> 
> C0 (cpu running)        ( 2,6%)
> ...

 

P.S Ho questo risultato sia con alimentatore attaccato che con alimentatore staccato.

----------

## Guglie

 *ashlar wrote:*   

> Dopo tre giorni di smanettamento sono ancora nella condizione in cui powertop non mi mostra i watt al secondo 

 

potrebbe essere un modulo del kernel che ti manca: powetop controlla che $rate sia > 0 prima di outputtare il consumo, quindi probabilmente ti manca qualche parametro in /proc/acpi/battery/BAT0 e ciò impedisce a powerop di calcolare il consumo

posta il contenuto di /proc/acpi/battery/BAT0 pf

----------

## riverdragon

 *Guglie wrote:*   

> outputtare

 OMG

Ho caricato qui la mia configurazione del kernel, tuttora non vedo i cstates... se qualcuno riesce a darmi una dritta mi fa un gran favore.

----------

## unz

Ecco, ho notato una cosa, io nell'acpi ho il wattaggio [ :Very Happy: ] della batteria, solo che la mia batteria è riconosciuta come BAT1 ... che sia lì il problema della non visualizzazione?

----------

## ashlar

 *Guglie wrote:*   

>  *ashlar wrote:*   Dopo tre giorni di smanettamento sono ancora nella condizione in cui powertop non mi mostra i watt al secondo  
> 
> potrebbe essere un modulo del kernel che ti manca: powetop controlla che $rate sia > 0 prima di outputtare il consumo, quindi probabilmente ti manca qualche parametro in /proc/acpi/battery/BAT0 e ciò impedisce a powerop di calcolare il consumo
> 
> posta il contenuto di /proc/acpi/battery/BAT0 pf

 

Facendo un ls della cartella che mi hai detto ottengo questo risultato:

```
 ls  /proc/acpi/battery/BAT0   

alarm  info  state

```

----------

## riverdragon

Gooooooooooooooooooooool! Era una questione di bios, evidentemente! Ho aggiornato all'ultimissima versione (che sembrava risolvere solo problemi di vista) e invece ecco qui il risultato!

```
Cn          Avg residency (10s) Long term residency avg

C0 (cpu running)        ( 6.2%)

C1                0.0ms ( 0.0%)                   0.0ms

C2                0.4ms ( 0.5%)                   0.7ms

C3                2.5ms ( 5.6%)                   2.2ms

C4                4.2ms (87.7%)                   3.8ms

Wakeups-from-idle per second :  484.4 

Power usage (ACPI estimate) :  15.8 W (2.7 hours left)

Top causes for wakeups:

  27.4% (66.3)       <interrupt> : uhci_hcd:usb5, HDA Intel, ohci1394, eth0, nvidia 

  19.9% (48.3)                   : do_setitimer (it_real_fn) 

  19.9% (48.3)         syndaemon : do_nanosleep (hrtimer_wakeup) 

   9.9% (24.0)       <interrupt> : acpi 

   5.9% (14.3)     mixer_applet2 : schedule_timeout (process_timeout) 

   3.7% ( 9.0)       <interrupt> : ide0 

   3.6% ( 8.7)            compiz : schedule_timeout (process_timeout) 

   3.4% ( 8.2)    gnome-terminal : schedule_timeout (process_timeout) 

   1.2% ( 3.0)           xfsbufd : schedule_timeout (process_timeout) 

   1.1% ( 2.7)   gnome-power-man : schedule_timeout (process_timeout)
```

Domanda: il programma mi suggerisce

```
Suggestion: Enable laptop-mode by executing the following command:

   echo 5 > /proc/sys/vm/laptop_mode 

and/or putting this command into /etc/rc.local
```

ma non uso i laptop-mode-tools... quindi il suggerimento diventa inutile?

----------

## Guglie

 *ashlar wrote:*   

> Facendo un ls della cartella che mi hai detto ottengo questo risultato:
> 
> ```
>  ls  /proc/acpi/battery/BAT0   
> 
> ...

 

hai ragione, imprecisione mia: il file in questione sarebbe state

----------

## ashlar

 *Guglie wrote:*   

>  *ashlar wrote:*   Facendo un ls della cartella che mi hai detto ottengo questo risultato:
> 
> ```
>  ls  /proc/acpi/battery/BAT0   
> 
> ...

 

ecco qua cosa c'è dentro state:

```
present:                 yes

capacity state:          ok

charging state:          discharging

present rate:            unknown

remaining capacity:      4435 mAh

present voltage:         unknown

```

----------

## Guglie

 *ashlar wrote:*   

> ecco qua cosa c'è dentro state:
> 
> ```
> present:                 yes
> 
> ...

 

non hai le informazioni relative a charging state e present voltage e questo impedisce il calcolo del consumo.

il perchè tu non le abbia non lo so; come ha detto riverdragon potrebbe essere un problema del bios

----------

## unz

```
unz@gUnzLess ~ $ cat /proc/acpi/battery/BAT1/state

present:                 yes

capacity state:          ok

charging state:          discharging

present rate:            2230 mA

remaining capacity:      2699 mAh

present voltage:         1 mV

```

... io ce l'ho ...   :Sad: 

edit: tutte le congetture su BAT1 saltano, mi sembra d'aver capito che i valori escano da HAL, ed HAL non ha notizie sulla mia batteria.

----------

## Sparker

Ma secondo voi:

```

89.4% (4281.6)       <interrupt> : eth0

```

Questo trasferendo dati, in idle è sui 200 interrupt

E' una scheda di rete integrata di un chipset nForce2.

Sono solo i driver forcedeth scritti da cani o forse c'è qualche opzione sballata nel kernel?

(e' un fisso, quindi il problema è relativo, ma il numero di interrupt mi sembra comunque esagerato)

----------

## Guglie

 *unz wrote:*   

> edit: tutte le congetture su BAT1 saltano, mi sembra d'aver capito che i valori escano da HAL, ed HAL non ha notizie sulla mia batteria.

 

è strano, tu hai tutti i dati che servirebbero e il programma mi pare li prenda proprio da quel file (guarda powertop.c alla riga 300).

----------

## unz

Uscita la 1.4 ... ora si sparano i comandi di risparmio energetico direttamente da console tramite shortcuts!

----------

## Dece

 *Guglie wrote:*   

>  *unz wrote:*   edit: tutte le congetture su BAT1 saltano, mi sembra d'aver capito che i valori escano da HAL, ed HAL non ha notizie sulla mia batteria. 
> 
> è strano, tu hai tutti i dati che servirebbero e il programma mi pare li prenda proprio da quel file (guarda powertop.c alla riga 300).

 

Infatti da me è cosi:

 *Quote:*   

> deckard@bejelit ~ $ cat /proc/acpi/battery/BAT0/state
> 
> present:                 yes
> 
> capacity state:          ok
> ...

 

sia ad alimentazione inserita che a batteria

Dando un'occhiata al codice (riga 340 e poco sopra), fa un po di calcoli anche con quei valori e se il risultato è maggiore di 0, stampa la riga con il consumo e la durata: ovviamente se il valore nel file è unknown i calcoli vanno a farsi benedire  :Sad: 

Qualcuno sa se c'è qualcosa di particolare da abilitare nel kernel per avere tutte le informazioni in proc, oppure è colpa dell'acpi e quindi ci si deve arrendere?

----------

