[Eisfair] acpi neuer Kernel 4.9.207-eisfair-64-VIRT :-( 17/100 mehr Verbrauch

[D. Oezbilen]

Hallo Thomas.

> Habe gerade noch mal nachgesehen. In den 3.16er Kernel waren ONDEMAND jepp, das habe ich gestern im Vergleich auch festgestellt.
Weiterhin habe ich beim Auslesen der modifizierbaren Parameter 
(rw-Rechte) in diesem Kontext

	/sys/devices/system/cpu/

festgestellt,  dass die

CPU	bei 3.x mit 2,6
	bei K4.x mit 3,1

getaktet wird.

4.9.207-eisfair-64-VIRT
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor - performance
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq - 3300000
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed - <unsupported>
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq - 1200000

K.3.X
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq - 2601000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq - 1200000

laut
<https://ark.intel.com/content/www/de/de/ark/products/64595/intel-xeon-processor-e5-2670-20m-cache-2-60-ghz-8-00-gt-s-intel-qpi.html>

kann die CPU bis 3,3 (K4.9 liegt richtig). Warum liegt 3.x falsch. :-)

> Nur indem man ondemand wieder zum Default macht. Aber ich habe mich bei 
> dieser Änderung an Debian orientiert. Die setzen performance als 
> Default, damit der Rechner so schnell wie möglich startet und stellen 
> erst nach dem Booten um.
Ich dachte, der Kernel 3.x hat sich diese Werte aus der kvm Umgebung von 
einer anderen HW gezogen. Keine Ahnung, was ich da fuer eine vCPU 
durchgereicht habe.

Doch, wie Du auch schreibst, die Werte sind rw-Werte, sprich man kann 
diese (irgendwann) modifizieren, zudem widerspruechlich waere, dass man 
eine veraenderte CPU/Plattform beim naechsten Boot nach einem Boot nicht 
wahrnimmt. Deswegen sind diese Werte sicher nicht statisch.

Insofern, angenommen -diese Freguenzen varieren- ist es z.Z. fuer mich 
nicht nachvollziehbar, warum der K3.x nur 2,6 erkennt, und nicht wie 
K4.x die richtige max-f der CPU. Nicht dass, ich das brauche, aber 3.x 
patzt da.

Wenn der Boot jedoch abgehakt ist, sollte die Maschine auch nicht mit 
3,3 oder 2,6 laufen, was top/htop auch belegt, 0,0x ist die Last, also 
weit v. _irgendeiner_ Last weg.
Deswegen scheitert auch der Erklaerungsversuch, dass die hohe f (wenn 
Last waere) auch den Mehrverbrauch nachvollziehbar macht.  Irgendwie 
dead lock. :-( Nix Greifbares.

> https://www.phoronix.com/scan.php?page=news_item&px=MTM3NDQ
> ###################################

Auf dieser Seite habe ich heute morgen noch dies gefunden.
<https://www.phoronix.com/scan.php?page=news_item&px=Linux-19-Idle-Power-Draw>
K.4.3-4.5, 4.7, aber auch 3.12 waren etwas verschwenderischer waren.
Hingegen 4.6 besser, stromsparender.

4.9 sieht gar einen kleinen Tick besser aus als 3.16.
Insofern, habe ich mit der HW wohl die A-Karte. :-( ;-) dg.
Die Rettung koennte die Virtualisierung sein des eisx64 sein.

> In eisfair sind folgende Treiber eingebaut (fest oder modularisiert, 
> Beispiel eisfair-64):

> CONFIG_X86_SPEEDSTEP_CENTRINO=y
> CONFIG_X86_P4_CLOCKMOD=m
> 
> Eingebaute (fest oder modularisiert, Beispiel eisfair-64) governors:
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
> # CONFIG_CPU_FREQ_GOV_SCHEDUTIL is not set


Und es gibt wohl die Moeglichkeit andere Governor-Vorlagen einzubinden. 
Neue Ufer.

<https://unix.stackexchange.com/questions/242382/how-do-i-add-cpu-frequency-governors-to-the-linux-kernel?rq=1>
=>
<https://github.com/tegrak/lulz-kernel_gt-i9100/blob/master/kernel/drivers/cpufreq/cpufreq_lulzactive.c>
=>
<http://tegrak2x.blogspot.com/2011/11/lulzactive-governor-v2.html>

Da es keine richtigen Winterabende mehr gibt, koennen wir diesen Einbau 
auch abhaken. :-) Ist auch die Frage, _was_ / _wieviel_ es bringt. 
Nachvollziehbar, dass bei Android, mit begrenztem Stromvorrat max. 
gespart werden soll.

Ich werde wieder umbauen und die eisx64 auf einer andern HW booten, um 
zu vergleichen, ob der Stromverbrauch dort auch so  unterschiedlich ist.

Derya