Hello @ tous,
Après divers échecs de ma part pour overclocker j'ai enfin compris ce qui n'allait pas dans ma manière de faire. Etant passé à linux en mode 100%, il est donc nécessaire de rassembler les outils qu'utilisent nos amis overclockers sous l'autre OS.
Rassurez-vous, tous les outils nécessaires existent sous notre OS préféré pour faire chauffer du silicium.
Le topic est articulé autour d'un exemple d'O/C, le mien : cet overclocking modéré vise à assurer un système rock stable mais bien performant.
La config et explication rapide :
Gigabyte EP45 DS4
Q6600 G0
8 go (4 x 2) Corsair PC8500 CL5
Geforce 6800 Ultra @ stock
+ le reste.
La carte mère est bien stable en alimentation, bien refroidie et a un bios complet. En plus, des LEDs permettent un diagnostic de panne facile. Enfin, on peut s'amuser à voir l'allumage des phases d'alimentation quand on charge le processeur.
Le proc est choisi pour sa facilité à s'O/C
La RAM est choisie d'une part pour les bons timings, d'autre part pour sa capacité à fonctionner à 1066 MHz+. On a choisi bien sur des barettes identiques de RAM.
Le reste est là pour sa compatibilité excellente avec nux.
Description de l'O/C :
FSB 366 Mhz
Tous les voltages en auto (oui je sais,
)
Ram en x2.5 => 1098 Mhz
Let's go
Tester la stabilité initiale du système
Le premier élément à tester est la RAM. Elle doit tourner sans erreur pour au moins espérer que le système sera stable :
Pour cà on a le fabuleux memtest. Il est dispo par exemple sur tout cd d'install ubuntu, sur le UBCD, etc, etc. De plus il permet d'estimer grossièrement la bande passante de la RAM. Notez cette valeur, on va s'en resservir.
En espace utilisateur, on a memtester http://pyropus.ca/software/memtester/ . Comme il est entièrement en espace utilisateur, une simple compilation puis execution en ligne de commande suffit.
note : les options de gcc, ses versions, version du kernel, etc... varient et cela peut engendrer des diffs de perf indépendantes du matos. On les considèrera comme négligeables par rapport au gain apporté. Certains tests montrent que des distros gonflent trop et bouffent des perfs. Ceci est source de troll mais néanmoins vrai, il est donc important de préciser la méthodologie de vos tests.
Toutes les infos sur votre système
pour remplacer CPUID : c'est très simple
lol@debian:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel
cpu family : 6 model : 15
model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz stepping : 11
cpu MHz : 3293.896
cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10
wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon p ebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority
bogomips : 6587.79 clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual power management: |
J'ai pas mis les 4 proces, c'est tout pareil.
pour lire les différents voltages il faut utiliser lm-sensors, voici un "tuto vitesse éclair", version debian :
aptitude install lm-sensors
sensors-detect
sensors
|
voila, si vous répondez oui à la dernière question il remplit le fichier /etc/modules comme ca tout est chargé au démarrage.
Pour la EP45-DS4 le chip utilisé est un ITE8720 qui s'occupe du lecteur disquette, du port COM mais aussi de monitorer différents voltages. Il est dispo dans le dernier lm-sensors, mais il faut ajouter à la mano un patch sur le kernel 2.6.28, et voici le résultat
lol@debian:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +34.0°C (high = +82.0°C, crit = +100.0°C)
coretemp-isa-0001
Adapter: ISA adapter
Core 1: +34.0°C (high = +82.0°C, crit = +100.0°C)
coretemp-isa-0002
Adapter: ISA adapter
Core 2: +34.0°C (high = +82.0°C, crit = +100.0°C)
coretemp-isa-0003
Adapter: ISA adapter
Core 3: +30.0°C (high = +82.0°C, crit = +100.0°C)
it8720-isa-0290
Adapter: ISA adapter
in0: +1.42 V (min = +0.00 V, max = +4.08 V)
in1: +2.10 V (min = +0.00 V, max = +4.08 V)
in2: +3.33 V (min = +0.00 V, max = +4.08 V)
in3: +2.99 V (min = +0.00 V, max = +4.08 V)
in4: +1.68 V (min = +0.00 V, max = +4.08 V)
in5: +3.10 V (min = +0.00 V, max = +4.08 V)
in6: +0.43 V (min = +0.00 V, max = +4.08 V)
in7: +2.14 V (min = +0.00 V, max = +4.08 V)
in8: +3.10 V
fan1: 1350 RPM (min = 10 RPM)
fan2: 0 RPM (min = 10 RPM)
fan3: 510 RPM (min = 10 RPM)
fan4: 736 RPM (min = 10 RPM)
temp1: +29.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
temp2: +31.0°C (low = +127.0°C, high = +70.0°C) sensor = thermal diode
temp3: -2.0°C (low = +127.0°C, high = +127.0°C) sensor = thermistor
cpu0_vid: +0.000 V
|
Pour coretemp, le driver permettant d'avoir les sondes du proc, c'est parfait.
On constate un support encore un peu bancal, mais ca marche. Par contre les tensions ne sont pas encore reliées par leur nom. Faut que je voie ca avec les devs
Sinon, sachez que lm-sensors s'appuie maintenant sur sysfs et qu'on a donc un accès granulaire à toutes ces infos.
Ensuite différentes interfaces telles gkrellm pour gnome, ou encore ksystemmonitor permettent d'afficher ces différentes infos. On peut aussi les récupérer pour les utiliser dans des widgets avec toute la panoplie habituelle.
Comment monitorer mon hard ?
Comme on se contente d'une charge minimale du proc quand on charge la mémoire (hors AMD64 et i7, qui ont un comtrôleur mémoire intégré), on a ensuite besoin e charger le proce.
Tester la stabilité globale du système :
Installer une distro stable qui ne fait habituellement pas de bug à l'install. Si ca ne marche pas, c'est très mal parti
L'installeur de debian permet un test de stabilité initiale avec cpuburn. Pour pouvoir utiliser ce test qui n'est pas proposé dans les options standard, utiliser la ligne suivante :
Spoiler :
installgui priority=medium |
proposera d'utiliser CPUburn. Mais ATTENTION ! Ceci se fait sans AUCUN MONITORING et donc ca peut cramer votre matos si vous ne savez pas ce que vous faites. Les N cores sont TOUS chargés à 100% pendant une durée déterminée par vous-même.
Cette option est surtout utile quand on recoit un matos nouveau qu'il faut immédiatement tester pendant une durée variable. En cas de pépin retour @ envoyeur avec
(@stock bien sur
)
Pour utiliser CPUburn correctement, il faut charger les N cores à 100%, ce qui n'est pas fait de base. Sur debian, j'utilise le script très bien fait livré avec le udeb cpuburn du debian-installer. Rapidement,
ar -x cpuburn.udeb
tar -xjf control.tar.gz
./postinst |
ATTENTION SI VOUS TUEZ LE SCRIPT, LES PROCESS CPUBURN NE SERONT PAS ARRETES ET VOUS DEVREZ LE FAIRE A LA MAIN (désolé pour les caps)
Ensuite, on peut tester la compilation d'un kernel. Ceci fait appel à la mémoire et charge bien le système.
Il existe aussi cpustressMT
Comment bencher mon système ?
Le bench le plus évident est de mesurer la bande passante des différentes mémoires du processeur. Pour ceci, on utilise :
- bandwidth http://home.comcast.net/~fbui/bandwidth.html
permet de mesurer l'accès au L1, L2, et RAM
- MBW qui est plus précis sur ce qu'il fait http://linux.softpedia.com/get/Pro [...] 2167.shtml
Pour tester l'efficacité de l'O/C en terme de taches usuelles, on peut par exemple utiliser la phoronix test suite qui s'installera bien sous debian par exemple : http://www.phoronix-test-suite.com/
Bien sûr, on peut utiliser toute la panoplie des outils utilisés pour mesurer les perfs des serveurs, clusters et autres joyeusetés : http://lbs.sourceforge.net/
Le classique superpi existe en version linux
Et ce qui est marrant c'est qu'on obtient de meilleures perfs chez nous à matos équivalent que sous windows (pour info avec mon Q6600 je fais le même temps qu'un Q9550 bien O/C)
Pour finir, le seul truc que tout le monde regardera
: un screenshot
Voila, c'est prêt
infos, commentaires bienvenus 