Mein “erster” EeePC, ein Testgerät mit US-Tastatur, PCIe-Slot und weissem Gehäuse lief auf 900MHz. Alle derzeit ausgelieferten Geräte scheinen aber aus 630MHz getaktet zu sein. Die Taktfrequenz ist das Ergebnis aus 70MHZ FSB-Frequenz und einem Multiplikator von 9. Gelingt es, die FSB-Frequenz auf 100MHz anzuheben, hat man wieder die 900MHz der Vorseriengerätes. Sourcen für ein Kernelmodul, dass die FSB-Änderung durchführt, finden Sie unter http://code.google.com/p/eeepc-linux/. Ich habe das Modul einmal ausprobiert und bin folgendermaßen vorgegangen:
- Kompiliert wird das Modul mit einem simplen make
- Ein make install gibt es nicht. Kopieren Sie das Modul einfach von Hand:
cp eee.ko /lib/modules/$( uname -r )/kernel/drivers/misc - Erstellen Sie mit depmod -a alle Modulabhängigkeiten neu
- Jetzt können Sie zuerst den I2C-Bus-Treiber und dann das Kontrollmodul laden:
modprobe i2c_i801
insmod /lib/modules/$( uname -r )/kernel/drivers/misc/eee.ko
Das Laden von eee per modprobe funktionierte leider bei mir nicht, keine Probleme mit insmod
Die Verwendung ist recht simpel:
- Anheben des FSB auf 75MHz
echo 75 24 0 > /proc/eee/fsb - Anheben des FSB auf 100MHz und Anheben der Core-Spannung
echo 100 24 1 > /proc/eee/fsb - Umschalten auf manuelle Lüftersteuerung
echo 1 > /proc/eee/fan_manual - Abschalten des Lüfters
echo 0 > /proc/eee/fan_speed - Auslesen der Temperatur
cat /proc/eee/temperature
Natürlich sollte man hohe FSB-Geschwindigkeiten nicht mit einem abgeschalteten Lüfter kombinieren. Auch kann es bei hohen FSB-Geschwindigkeiten vorkommen, dass der Prozessor nicht mehr stabil läuft, ein Anheben der Corespannung hilft möglicherweise ab, verursacht aber 14% mehr Leistungsaufnahme und dementsprechend weniger Akkulaufzeit. Aufgefallen ist mir, dass sich der EeePC an zu großen FSB-Änderungen auf einmal verschluckt. Auf der sicheren Seite war ich mit:
for i in $( seq 73 3 91 )
do
echo $i 24 0 > /proc/eee/fsb
cat /proc/eee/fsb
sleep 1
done
Mit abgeschaltetem Lüfter, 91MHz FSB, niedriger Core-Spannung und drei Minuten bzip2 landete bei mir die Prozessortemperatur bei 61°C, was wohl gerade noch im Rahmen liegt. Ich überlege, das Modul in das Xubuntu-Image aufzunehmen und per Startupscript eine FSB-Frequenz von 85 bis 91MHz einzustellen (3MHz-Schritte), ohne Änderungen an der Lüftersteuerung vorzunehmen, bräuchte dafür aber noch Erfahrungswerte von anderen Nutzern. Mittelfristig wäre natürlich an ein kleines, in Python geschriebenes Applet fürs XFCE-Tray zu denken.
Primitives Benchmarking mit bzip2:
(Absturz beim falschen seq und der daraus resultierenden schlagartigen Änderung des FSB)
Interessante Links
- Sehr umfangreiche Anleitung im Eee-User-Wiki
- Ein Daemon zur Lüftersteuerung (noch nicht von mir getestet)
Nachtrag, 10. März: Läuft bei mir stabil bis 9x91MHz, also 819MHz, darüber sporadische Abstürze, ein Init-Script wird folgen — das wird dann die Bootzeile auslesen, so dass man den maximalen Takt per Bootparameter setzen kann, was bei Problemen eine leichte Behebung ohne Rettungssystem ermöglicht.
Ich arbeite unter dem original xandros und bekam das Modul 0.2 nicht richtig kompiliert:
make[1]: Entering directory `/usr/src/linux-source-2.6.21.4-eeepc’
CC [M] /usr/src/eeepc-LINUX02/module/eee.o
/usr/src/eeepc-LINUX02/module/eee.c: In function ‘eee_pll_read’:
/usr/src/eeepc-LINUX02/module/eee.c:76: warning: implicit declaration of function
‘i2c_smbus_read_block_data’
Building modules, stage 2.
MODPOST 1 modules
WARNING: “i2c_smbus_read_block_data” [/usr/src/eeepc-LINUX02/module/eee.ko] undefined!
Das erzeugte Kernelmodul läesst sich aus selbem Grund auch nicht laden. Habe dann die version 0.1 kompiliert, disee kompiliert und funktioniert. Leider keine fan-regelung. Also weiter mit 0.2 rumgespielt.
In den headerfiles vom kerneltree ist in der i2c.h i2c_smbus_read_i2c_block_data deklariert. Scheint mir auch gleichartige args zu erwarten, also im Quellcode des moduls ausgetauscht, kompiliert und geladen.
Nach dem Boot zeigt fsb schon komische Werte an, z.B.
-1 63 1
Habe den “primitiven benchmark” nachgebaut und muss feststellen das es so einfach nicht funktioniert, fsb nimmt zwar die erwarteten Werte an, die cpu taktet aber wie im bios definiert.
Sun Jun 15 17:28:47 CEST 2008
Temperatur: 53
Vom Bios kommend:0 0 0
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 281.627 seconds, 372 kB/s
real 4m42.359s
user 2m58.110s
sys 1m27.130s
Temperatur: 56
64 24 0
67 24 0
70 24 0
Temperatur: 56
FSB jetzt 70: 70 24 0
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 286.608 seconds, 366 kB/s
real 4m47.363s
user 3m3.080s
sys 1m27.280s
Temperatur: 56
70 24 0
73 24 0
76 24 0
79 24 0
82 24 0
85 24 0
FSB jetzt 85: 85 24 0
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 286.973 seconds, 365 kB/s
real 4m47.732s
user 3m3.660s
sys 1m27.060s
Temperatur: 56
85 24 0
88 24 0
91 24 0
94 24 0
97 24 0
100 24 0
FSB jetzt 100: 100 24 0
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 286.365 seconds, 366 kB/s
real 4m47.109s
user 3m2.390s
sys 1m27.650s
Temperatur: 56
Schade, irgendwelche infos bzgl. unterschied zwischen
a) i2c_smbus_read_i2c_block_data
b) i2c_smbus_read_block_data
???
danke
klaus
Es stellt sich natürlich die Frage wie sich der erhöhte FSB Takt auf die Batterie auswirkt. Infolge der Probleme mit obigem Kernelmodul habe ich das BIOS 8804 aufgespielt (diese Version ermöglicht einem die Einstellung des FSB auf 70 oder 100 MHZ) und einen Praxistest durchgeführt.
In beiden Fällen wurde der Akku bis zum Anschlag geladen, dann der EEEPC gebootet. Einzige aktive Anwendung war dann ein (echter – also nicht dieser Asuskrüppel) VDR der das Bild über den ShmClient auf den X-Desk
ausgab, WLAN war auch aktiv, Ton runtergedreht.
Die Ergebnisse sind ein wenig ernuechternd:
FSB 100 MHZ / ShmClient
Sun Jun 15 22:16:07 CEST 2008
Sun Jun 15 23:41:55 CEST 2008
1:25 Laufzeit
FSB 70 MHZ / ShmClient
Mon Jun 16 07:27:05 CEST 2008
Mon Jun 16 09:58:12 CEST 2008
2:31 Min Laufzeit
Zur Ergaenzung noch Mitschnitt aus meinem LOG (gute Durchschnittswerte rausgesucht). Zunächst die 100MHZ Variante:
Sun Jun 15 23:13:39 CEST 2008
26001 root 18 0 1636 480 412 S 2.0 0.1 0:00.01 tac
882 root 15 0 271m 9444 4980 R 2.0 1.9 5:48.42 Xorg
15293 root 13 -2 137m 23m 5744 S 18.1 4.7 2:42.64 vdr
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
Swap: 0k total, 0k used, 0k free, 90600k cached
Mem: 508328k total, 213920k used, 294408k free, 14528k buffers
Cpu(s): 22.3%us, 3.0%sy, 0.3%ni, 68.3%id, 5.2%wa, 0.8%hi, 0.2%si, 0.0%st
Tasks: 72 total, 2 running, 69 sleeping, 0 stopped, 1 zombie
top – 23:13:39 up 58 min, 1 user, load average: 1.27, 1.12, 0.86
TEMP:59
Luefter:760
Dann die 70MHZ Variante. Hier ist die CPU Last im Schnitt immer höher, das Erscheinungsbild der Bildausgabe ist (subjektiv) auch schlechter (ruckt schon mal öfters).
Mon Jun 16 08:04:27 CEST 2008
17624 root 20 0 1592 388 316 S 1.9 0.1 0:00.01 tail
882 root 15 0 271m 9420 4964 S 5.8 1.9 1:43.76 Xorg
2001 root 13 -2 129m 23m 5680 S 25.3 4.7 10:47.40 vdr
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
Swap: 0k total, 0k used, 0k free, 90744k cached
Mem: 508328k total, 221140k used, 287188k free, 21724k buffers
Cpu(s): 37.2%us, 4.6%sy, 0.4%ni, 52.6%id, 3.9%wa, 1.2%hi, 0.2%si, 0.0%st
Tasks: 72 total, 1 running, 70 sleeping, 0 stopped, 1 zombie
top – 08:04:27 up 38 min, 1 user, load average: 3.57, 3.13, 2.48
Temp:52
Luefter:710
Fazit: 100MHZ fressen lecker viel Akku auf, wobei ich aber leider nicht weiss ob das ASUS Bios bei 100MHZ FSB auch die Corespannung erhöht (was aber zu vermuten ist). Hinzu kommt die höhere Wärme, ob das dem EEE auf Dauer gut tun wird weiss man auch nicht. Ich denke es gibt Gründe dafür das ASUS das wieder aus dem BIOS entfernt hat.
Klaus
Oh Schock, das mit den Umlauten ist ja leider sehr unschoen hier …..
Ich bitte das zu entschuldigen
klaus