Un peu moins de bruit que diable !

Je vous en ai parlé ... maintenant qu'il tourne depuis 10 jours sans que mon processeur ait fumé, je vous le soumet.... à utiliser à vos risques et périls... Son principe est simple, lorsque la machine n'est pas utilisée, il passe en basse fréquence et il adapte la vitesse des ventilos à la température du cpu et la charge en cours pour anticiper la chauffe. Le script régule bien ma machine et ce, en silence.

Lire la suite

Comme dit précédemment, je suis enfin maitre de mes ventilateurs et des capteurs de température ... je vais pouvoir mettre au point un programme de régulation permettant de limiter les nuisance sonore de la bête ... Pour rappel, même si je revit d'une solution 100% fan-less, on dirait bien que la carte via epia sn 18000 ne soit pas la bonne référence, Il aurait mieux valu la version SN 10000 mais bon, voila, ce n'est pas celle que j'ai et puis, 1G ... coté perf, c'est un peu juste pour mon usage. La solution soft reste donc la meilleure dans mon cas.

Lire la suite

Bon, le problème des Compact Flash et des flash en général, c'est que les écritures ont tendance à les user. Il est donc préférable de les protéger en réduisant les ecritures. En général, sur Linux, les répertoires qui sont couremment accédés en écriture sont:

• /tmp : les données sont ici totalement volatiles, donc on pourra les mettre en ram pour eviter l'usure
• /home : de toute façon pour un PC de bureau, les données utilisateurs ne tiennent pas sur une CF, un disque réseau viendra à notre secour
• /var : les données ici sont plus ou moins volatiles et peuvent être costaud, donc le ramfs n'est pas top, à voir mais une solution de type unionfs avec nfs et un stockage des élément modifiés sur disque réseau pourrait être une solution... Ce point étant le plus sensible on verra plus tard
• swap : celui là peut vite être mortel... Si la machine à pas mal de mémoire, il y a des chances qu'il ne soit pas trop solicité et c'est donc là une solution. Pour être sûr, on pourrait carrement le couper ; pour ma part, je le garde pour le cas où mais en utilisation normale, il est utilisé à 0% car ma taille mémoire est sur-sizée... Dans le cas où le swap serait plus solicitable, je pense que son installation sur une seconde CF de plus petite taille et de plus bas prix serait une solution acceptable ... à voir ; mais dans tous les cas à 70€ les 2Go de mémoire autant ajouter de la RAM.
  

Commençons par voir ce qu'il en est du /tmp ... Je propose de la mettre dans un ram-fs et à mon avis, 512Mo devraient suffir. Les ramdisk étaient des périphériques que l'on trouvait sous le nom __/dev/ram0-15, ils avaient une taille par defaut définie par un paramètre au démarrage du système. Dans mon cas, où j'aurai souhaité créer un ramfs de 512Mo, j'aurai dû ajouter dans mon fichier grub, "menu.lst" le paramètre suivant : ramdisk_size=512000, ce qui aurait donné :
kernel /boot/vmlinuz-2.6.22.13-0.3-custom root=/dev/disk/by-id/... ramdisk_size=512000

Cependant, avec les nouveaux noyau comme le 2.6.23, les ramfs ont été revu, maintenant, il suffit simplement de mettre dans le fichier fstab des entrées de la sorte :
ramfs /tmp ramfs default 0 0

Il semble que la mémoire soit allouée dynamiquement au fur et à mesure et non reservée. malheureusement, les commandes de type df ne fonctionnent pas. RamFS a ainsi l'air d'être un filesystème et non un pseudo périphérique ce qui permet de ne pas avoir à le formater ... Pas mal d'avantge donc. La taille maxi devrait pouvoir être fixé à l'aide de l'option maxsize=1000

J'ai un peu de ma à trouver une bonne description du mode de fontionnement de ramfs, il semble que ce système ait été revu dans les dernieres versions de noyau et la doc n'est pas des plus claire. Toutefois, on peu parlé des autre systemes équivalent.

Dans la même famille, il y a le tmpfs, qui a la bonne idée de pouvoir avoir une taille fixe et qui peut être swappé au besoin. Les tmpfs peut aussi être retaillé à la volé. Bref c'est une version amélioré du ramfs d'origine. Tmp fs peut être monitoré avec la commande df contrairement à ramfs.

J'avais lu qu'il pourrait être utile d'utiliser un système de fichier type JFFS2 plutôt que ext2 ou ext3, ce système pouvant permettre des écritures aléatoires sur la flash pour éviter de trop "user" le composant. Toutefois, j'ai aussi lu ceci : "JFFS2, ce FS ne travaille pas sur un block device mais sur un MTD (Memory Technology Device) qui travaille directement au niveau des blocs flash, ce qui est impossible avec une CF ou une clé USB, le contrôleur flash s'occupant de l'interface. Et même si c'était possible ce serait inutile et userait la flash car ce contrôleur gere aussi le wear leveling." ... Du coup n'ayant pas eu l'occasion d'expérimenter, je ne saurait que dire, si ce n'est que celui qui connaît le file système le plsu adapté aux flash ou SSD me le fasse savoir !

Si votre usage est plutôt embarqué de type routeur par exemple, il faut jeter un oeil du coté d'union-fs qui permet par exemple d'avoir un système en read-only sur la flash tout en laissant aux application la possibilité d'écrire sur le système de fichier, au travers d'un ramfs par exemple monté en union. La sauvegarde de certain fichiers particulier (log, config) etan toujours possible sur la flash ou ailleurs, à tout moment. C'est je pense LA solution à envisager en embarqué, pour de la bureautique, cette solution pose un problème : la synchro lors de l'installation de paquets, malheureusement fréquente.

Je vous en ai dejà parlé, pour fonctionner en fan-less, il y a deux choses importante avec cette carte : pourvoir réduire la fréquence du cpu (ça c'est ok) et controler température et vitesse de rotation des ventillos... Dans un précédent article, j'expliquai mes déboires et la non détection des chips de control de l'epia sn18000 par lm_sensors, heureusement, il y a du nouveau, la communauté réagit et des solutions pointent le bout de leur nez. Dans cet article, je vais vous expliquer ce bricolage un peu compliqué, il faut donc "lire la suite"

Lire la suite

Petit test de ce vendredi soir (un peu comme s'il fallait amortir mon wattmetre ! lol) Un comparatif de consommation avec plusieurs alimentations différentes. Depuis que j'ai appris que les alim avait un rendement (ca je m'en doutait) qui pouvait avoir de fortes variations, je me suis demandé si d'une alimentation à l'autre je pouvais trouver un gros écart. J'ai donc sorti mon stock d'alim du placard pour quelques tests. L'alim est branchée sur ma carte epia sn 1800 avec vidéo ati HD 2600 pro, un lecteur de CD et un disque usb.
Les résultats ne sont pas mirobolants mais je vous les propose tout de même:

• Alimentation dell 150w ; conso à vide 15W ; démarrage (n'a pas voulu démarrer (n'aime que les dell on dirait))
• Alimentation bas de gamme 350W : conso à vide 13W ; en charge 59W
• Alimentation Fortron 300W ; conso à vide 9W ; en charge 65W
• Alimentation ACC 350W ; conso à vide 9W ; en charge 66W
• Alimentation Fortron ZEN 300W ; conso à vide 22W ; en charge 68W

Bref, ce n'est pas parce que l'on paye une alim cher que l'on va faire des économies si l'on regarde la conso d'une bas de gamme par rapport à une Fortron. Le gain est par contre ailleurs, stabilité de l'alim, ventilation plus silencieuse... Reste à mesurer si l'alim Fortron ZEN 300W, sencée se distinguer par son rendement (87%) fait mieux que les autres.
Ensuite, la consommation à vide est celle de l'alim branchée alors que rien ne tire dessus. Ajoutez 2W en gros pour la veille de la carte mère. Là dessus les alimentations de qualité supérieure se distinguent et ce d'autant plus qu'elle possèdent un interrupteur 220V permettant pour de vrai de tout couper. Pour rappel, 15 W sur 1 an coûte dans les 13€ d'électricité.

Je vais accorder un plus ample test à l'alim Fortron ZEN 300W, mais à première vue suivant les résultats ci-dessus, il s'agit de la moins économique (celle qui consomme le plus à charge équivalente) Ce point est surprenant car elle est connu pour avoir un très bon rendement permettant d'avoir moins de perte en chaleur et donc un refroidissement fan-less... et bien, étrangement c'est celle qui a le plus mauvais rendement selon mon test ... reste qu'elle a tendance à affoler mon wattmètre d'habitude stable et qui là oscille entre 66 et 75W (Peut être le signe de condo tampon moins gros, ce qui visuellement semble se confirmer)

Je n'ai jamais pu installé compiz fusion, faute à une des rares cartes video non supportée par les drivers propriétaires Nvidia. Cette nouvelle carte est une occasion de m'y mettre, ne serait-ce que pour voir.
Compiz-fusion avec la suse 10.3, c'est une histoire de click. Cette version est en effet complète : du répository ATI aux composent Compiz, bery, xgl... tout est là et presque installé en standard. J'ai donc commencé par installé les drivers fglrx en rencontrant un petit soucis car le module installé par suse ne portait pas la meme référence que le noyau que j'avais moi même recompilé. Qu'à celà ne tienne, une modprobe -f fglrx.ko règle le problème. Cette situation ne sera cependant que temporaire car du coup le module refuse de se charger automatiquement.
J'ai donc installé les drivers fournis sur le site d'ATI (je pense que ce sont les même en fait, en ce moment) et recompilé le module (il est possible que cette manip puisse se faire avec le packet de Suse, mais je n'ai pas testé avant). Attention, pour recompiler le module il faudra faire pas mal de ménage et à la main.

La présence du module est importante : lorsque le serveur X fglrx est installé sans que le DRI soit chargé, les fenetres deviennent extrèmement lente, non sans me rappeler la fluidité d'un 486 sous windows 95 (ceux qui étaient nés me comprendront)... Instant de nostalgie passé, cette situation n'est pas tenable ! Bon bref, dans une telle situation, vérifiez la présence du module fglrx (lsmod | grep fglrx). S'il n'est pas présent c'est normal.

Vous pouvez aussi diagnostiquer le bon fonctionnement des parties 3D par les commandes suivantes:

root@epia> fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Radeon HD 2600 Pro
OpenGL version string: 2.1.7170 Release

Glxgear doit donner un nombre de frame conséquent (notez que autour de 300 FPS c'est deja pas mal et que quand tout va mal, il y en a plutôt 40
root@epia> glxgears
24874 frames in 5.0 seconds = 4974.736 FPS

fgl_glxgears doit aussi donner un bon nombre de frames par seconde
root@epia>fgl_glxgears
Pour ma part les résultats sont de l'ordre de 100 FPS.

Pour l'étape suivante, à savoir faire fonctionner Compiz-fusion, il faut que le glx soit activé et fonctionne bien ; il sera possible de vérifier quelques points préalable avec les commandes suivantes:
root@epia> glxinfo | grep "direct rendering" qui doit retourner une ligne avec "direct rendering: Yes"

Tout cela vérifié, vous devriez être à même d'activer le mode sgl et de lancer Compiz-Fusion ... Si cela fonctionne chez vous c'est que vous êtes plus chanceux que moi .... L'activation se fait de la façon suivante : lancez en tant que root la commande suivante : gnome-xgl-switch --enable-xgl puis rebootez le PC. Une fois redémarré Compiz devrait pouvoir se lancer.

Pour ma part, une fois xgl activé j'ai de très nombreux soucis de raffraicissement, en fait je dirait même que plus rien ne se raffraichi, bref, c'est totalement inutilisable. Je n'ai trouvé aucune information sur ce problème pour l'instant sur Internet, donc si vous avez des pistes, laissez moi quelques commentaires, je suis preneur.

Quelques liens qui m'ont bien aidés:

• La page Compiz-Fusion d'opensuse 10.3

Je vous propose la comparaison suivante réalisée entre la carte Epia 1.8G et mon Athlon 1.5G (1800+) ; Nous avons comparé ces machines en terme de bogomips qui reste quelque chose d'assez subjectif, j'ai donc effectué un test sur ces deux machine à l'aide de l'outil lmbench3. Le test est plutot long (4 heures) mais il ya beaucoup de résultats. Voici les premiers :

• athlon | kernel / freq / tlb page / cache line | 2.6.18 / 1513Mhz / 32 / 64o
• epia... | kernel / freq / tlb page / cache line | 2.6.22 / 1781Mhz / 64 / 64o
• p4..... | kernel / freq / tlb page / cache line | 2.6.18 / 1700MHz / 55 / 128o

Process, temps en microsecondes (le plus petit est le mieux) :

• athlon | null call / null IO / open-close / slct TCP / fork / exec prog / sh prog | 0,3 / 0,47 / 4,67 / 35,5 / 205 / 1398 / 8236
• epia... | null call / null IO / open-close / slct TCP / fork / exec prog / sh prog | 0,1 / 0,31 / 2,42 / 13.0 / 256 / 1173 / 7213

La carte epia offre un gain non négligeable sur l'ensemble des tests, hors mis le fork ; l'exec de programme ou sh peut être faussé par le fait que le filesysteme de l'epia est sur usb. Le kernel plus récent peut aussi jouer en la faveur de l'epia.

Calculs entiers (en nano secondes - le plus petit est le meilleur) :

• athlon | calculs bits / addition / mult/ div / modulo | 0,69 / 0,02 / 2,83 / 28,9 / 28,2
• epia... | calculs bits / addition / mult/ div / modulo | 0,56 / 0,02 / 0,61 / 29.0 / 30,1
• p4..... | calculs bits / addition / mult/ div / modulo | 0,30 / 0,01 / 8,37 / 43,9 / 37,1

Hors mis un point étrange sur la multiplication de l'athlon, les l'epia et l'athlon se valent, la différence de fréquence justifiant les écarts. Le P4 performe en addition / masquage mais se trouve plutôt moyen sur les calculs plus complexes.

Calculs flottant -float- ( en ns - le plus petit est le meilleur) :

• athlon | calculs addition / mult/ div / bogo | 2,7 / 2,9 / 16,3 / 15,8
• epia... | calculs addition / mult/ div / bogo | 3,9 / 4,2 / 40,8 / 51,4
• p4..... | calculs addition / mult/ div / bogo | 2,9 / 4,2 / 25,5 / 25,4

L'unité de calcul en virgule flottante de l'athlon semble beaucoup plus efficace que celle de l'epia surtout pour les divisions.

Calculs flottant -double- ( en ns - le plus petit est le meilleur) :

• athlon | calculs addition / mult/ div / bogo | 2.72 / 2.74 / 47,5 / 15,6
• epia... | calculs addition / mult/ div / bogo | 3,90 / 4,47 / 40,8 / 51,4
• p4..... | calculs addition / mult/ div / bogo | 2,90 / 4,20 / 25,5 / 25,4

Il semble que l'unité de traitement de l'epia calcule en double comme en float (comme le P4) alors que l'athlon optimise certaines partie dans le cas de float. Il est intéressant de prendre ceci en compte lorsque l'on calcul la puissance de calcul par watt par exemple car cet exemple illustre que l'architecture interne du processeur peut avoir un impact fort sur la vitesse de calculs, surtout dans le cas de float/doubles.

Latence des communications ( en microseconde - le plus petit est le mieux) :

• athlon | context switch / AF UNIX / UDP / RPC-UDP / TCP / RCP-TCP / TCP-CON | 2,18 / 11,6 / 18,0 / 35,1 / 59,0 / 43,2 / 89
• epia... | context switch / AF UNIX / UDP / RPC-UDP / TCP / RCP-TCP / TCP-CON | 0,90 / 8,55 / 10,7 / 16,5 / 13,2 / 20,1 / 48

On retrouve ici les performance système bien meilleures pour l'epia, mais ceci peut toujours venir du noyau plus récent et compilé spécifiquement pour le processeur.

Latence sur les fichiers ( en microseconde - le plus petit est le mieux) :

• athlon | 0k create / 0K delete / 10K create / 10K delete / Page Fault | 30,1 / 32,1 / 119,2 / 58,0 / 4,17
• epia... | 0k create / 0K delete / 10K create / 10K delete / Page Fault | 16,0 / 13,5 / 123,4 / 27,3 / 1,96

Résultat très intéressant car l'epia a un file système sur usb qui, comme nous l'avons vu est peu performant. Malgré tout les performance sont meilleures que sur l'athlon, donc là encore la performance "système" est meilleure.

Débit avec la mémoire ( en MB/s - le plus grand est le mieux) :

• athlon | Mmap reread / bcopy libc / bcopy manuel / mem read / mem write | 554 / 240 / 278 / 617 / 385
• epia... | Mmap reread / bcopy libc / bcopy manuel / mem read / mem write | 601 / 408 / 406 / 565 / 980

Très bons résultats pour l'epia, sauf en lecture mémoire où il est équivalent. La technologie mémoire n'est pas la même : DDR vs DDR2 il n'y a rien d'étonnant à ce que l'epia performe, et c'est une très bonne nouvelle pour les performances.

Latence mémoire ( en ns - le plus petit est le mieux ) :

• athlon | cache L1 / cache L2 / Main memory / random | 2.04 / 13.8 / 174 / 422
• epia... | cache L1 / cache L2 / Main memory / random | 3.36 / 16.2 / 080 / 320
• p4..... | cache L1 / cache L2 / Main memory / random | 1.21 / 29.2 / 151 / 284

Le cache de l'Athlon semble plus performant mais l'accès hors cache de l'epia est bien meilleur. L'architecture cache du C7 est sans doute moins évoluée (normal si l'on veut consommer moins) mais la techno mémoire plus récente permet un gain qui sera utile. Le P4 offre visiblement un meilleur accès aux cache L1 et à la mémoire que l'athlon pour une technologie similaire.

En conclusion, l'objet de ce test n'était pas de comparer un Athlon avec un C7, mais plus simplement de comparer ma machine actuelle avec sa future remplaçante. Mon inquiétude était que celle orientée basse consommation d'énergie ait renié sur les performance et que la fréquence indiquée ne soit qu'un leurre marketing. Même si sur certains point on sent bien que l'architecture internet et plus simpliste que sur un composant bien plus gourmand en énergie les résultats, au global sont à la hauteur de mes attentes.

La solution mise en place sera basée sur l'utilisation d'une carte compact flash en guise de disque dur, l'occasion de comparer la performance de différents supports qui peuvent être utilisés dans de l'embarqué. N'ayant pas encore ma carte CF ultra-rapide j'ai effectué le test avec une carte très ancienne (acheté en 1999) de 40Mo, je vous livrerez donc un complément dès que ma carte 8G @ 40MB/s (sur le papier) sera arrivée. (ça y est, elle est là !)
Pour ce qui est des tests réalisés, en voici les résultats:
Performance max obtenue par un hdparm -t <device>

• Disque dur SATA - RAID 0 : 55 Mo/s
• Disque virtuel basé sur disque précédent : 53 Mo/s
• Compact Flash 8G (sur port ATA) : 39 Mo/s
• Disque dur sur ATA (La référence que je souhaite remplacer) : 30 Mo/s
• Disque dur sur USB : 10.8 Mo/s
• Disque virtuel sur NFS (reseau 100Mb) : 10.3 Mo/s
• Clef USB2 récente : 10.4 Mo/s
• Compact Flash 40 Mo (sur port ATA) : 1,8Mo/s
• Clef USB1 ancienne : 1,02 Mo/s

Performance min estimée avec le programme seeker (cf ici )

• Compact Flash 8G (sur port ATA) : 8,1 Mo/s
• Compact Flash 40 Mo (sur port ATA) : 2,5Mo/s
• Clef USB2 récente : 1,2 Mo/s
• Disque dur sur USB : 332 Ko/s
• Disque dur sur ATA : 220 Ko/s (en fait, doit être comme le précédent mais le disque n'est pas le même)
• Clef USB1 ancienne : 240 Ko/s
• Disque virtuel sur NFS (reseau 100Mb) : 148 Ko/s

Ce résultat est intéressant, car ce test met en avant la perte de temps lié à l'aspect mécanique des disques dur. Si dans le test précédent, où l'on lit des données en continu, le HD est de loin le plus rapide (les autres étant limité par leur bus (usb) ou leur technologie (CF) ), ses temps d'accès ne sont pas bon à cause des mouvements mécaniques. On peut considéré que la carte compact flash testée est aussi rapide sur un accès d'un seul gros fichier que d'une multitude de tout petits fichiers disséminés partout. On retrouve de la même façon un écart intéressant sur la clef USB2 avec une pénalité sans doute dû à l'accès série au données.

Temps de réponse mesuré avec seeker

• Compact Flash 8G (sur port ATA) : 0,56ms
• Compact Flash 40 Mo (sur port ATA) : 1,6ms
• Clef USB2 récente : 3,39ms
• Disque dur sur USB : 11,9ms
• Clef USB1 ancienne : 14,6ms
• Disque virtuel sur NFS (reseau 100Mb) : 26.74ms
• Disque dur sur ATA : 32 ms (en fait, doit être comme sur usb mais le disque n'est pas le même)

On remarque ici l'énorme écart entre une technologie flash et une technologie magnétique (mécanique) avec un facteur de l'ordre de 10.

En conclusion, si la promesse d'un débit en pointe de 40Mo/s est tenu par la compact flash nouvelle génération que j'ai commandé, les performance disque du système seront au moins égales à celle d'un disque dur (du moins celui que j'ai actuellement) en outre, le temps d'accès sera largement meilleurs, bref, à l'usage, la partie stockage de masse devrait être plus confortable qu'un disque dur classique. (l'espace de stockage en moins, c'est sûr, mais pour ma part j'utilise un NAS donc ce n'est pas un problème)

En complément, j'ai effectué des tests supplémentaires à l'aide de l'outil bonnie++ qui permet une analyse plus fine:

• Write ( seq char / seq bloc / rewrite )
  • Disque dur SATA RAID : 35M / 31M / 15M
  • Disque dur ATA : 21M / 35M / 13M
  • Disque dur sur USB : 11M / 26M / 12M
  • Disque dur sur NFS : 9M / 9M / 3M
  • Compact Flash 8G (sur port ATA) : bientot

• Read (seq char / seq block)
  • Disque dur SATA RAID : 23M / 45M
  • Disque dur ATA : 24M / 26M
  • Disque dur sur USB : 10M / 26M
  • Disque dur sur NFS : 7M / 7M
  • Compact Flash 8G (sur port ATA) : bientot

Je viens de réaliser un superbe investissement, dans ce magnifique Wattmètre, pour la somme rondelette de 13 euros chez Leroy Merlin ...

Vous avez tout compris on ne va trop parler taille de quéquette en frame par seconde, mais plutot Watt / heure ... concernant la machine, aller, je ferai un effort, on va aussi causer bogomips par watt si vous voulez !

J'ai donc réalisé les tests suivants en pause au bios à 1.8GHz (tests statiques):

• Consommation de le carte mère seule (avec l'alim tout de même) : 40 W
• Consommation de le carte mère seule + Compact Flash : 42 W
• Consommation avec lecteur de cd branché mais inactif : 43 W
• Consommation de mon HD usb éteint : 6W (c'est énorme !!)
• Consommation de mon HD usb allumé : 15W

Essayons quelques tests dynamiques:

• Consommation au boot en pic 43W
• Consommation en environnement graphique sans application entre 33 et 43W. Il semble qu'en idle la carte consomme autour de 33W et qu'elle monte à 43 lorsque le processeur bosse.
• Consommation lorsque le processeur est mis en basse fréquence entre 31 et 35W.

Voyons un peu l'analyse que l'on peut en faire

• Le coût par an (365j) en électricité (a 0.1€/kWh) est entre : 28.9€ (0.1*33*24*365/1000) et 38€ (0.1*43*24*365/1000) en mode full
• Le coût par an en mode low est entre 27.1€ et 30€

=> L'économie est au mieux de 20% sur cet élément, mais au global avec écran, elle sera vraiment moindre, disons qu'au lieux le gain sera de 8€. Le mode basse consommation n'a pas un grand intérêt pour la planète il permettra je l'espère de réduire le bruit de l'ensemble...

• Le rapport Watt / bogomips en full est de : 43/3593 = 0,012W/bogomips
• Le rapport Watt / bogomips en low est de 35/1597 = 0,022W/bogomips

=> Le rapport entre puissance de calcul et puissance consommée est clairement en faveur du mode 1.8GHz, le facteur étant de l'ordre de 2. Calculer en mode 800M est donc un gachi d'énergie.

Si je compare cette machine à mon PC actuel (UC seule) basé sur un Athlon à 1.5G avec 1HD, la consommation est entre 117W et 128W, le coût de fonctionneme annuel est estimable entre 102 et 112€.

De là, on peut déterminer le Retour sur investissement de la solution basse consommation. La solution epia coûte (cm+cf+ram) 420€, le gain annuel etant de 74€ il faudra 5,6 an pour que l'achat soit couvert par le gain d'énergie. Cette durée, en informatique, signifie que le ROI ne sera jamais atteint ... Par contre si l'on compare le coût d'achat d'une solution neuve non epia (disons cm+hd+ram = 80+70+50 = 200) la différence sera amortie en 3 ans ce qui est la durée de vie d'un PC. Bref ... pas vraiment de ROI à une solution basse consommation, surtout lorsque la machine ne tourne pas 24/24 et de toute façon on ne pourra pas comparer les modèles comme étant équivalent. C'est donc bien du coté du bruit et de l'encombrement qu'il faut regarder pour l'énergie, on aura, au mieux la sensation de faire faire des économies de gaz à effet de serre à la planète (quoi que l'électricité en France est assez propre de ce coté là).

Petit retour sur les classement watt/bogomips:

• solution macbook @ 2x1.8G : 50 / 9334 = 0,005W/bogomips
• solution core 2 duo @ 2x1.8G : 98 / 9334 = 0,010W/bogomips
• solution epia @ 1.8G : 43/3593 = 0,012W/bogomips
• solution P4 @ 1.7G : 60/4254 = 0,014W/bogomips
• solution sempron @ 1.4G : 60/2816 = 0,021W/bogomips
• solution athlon @ 1.5G : 128/3032 = 0,042W/bogomips

=> Quoi en conclure... pas grand chose, car les configuration sont assez différentes :

• macbook = 1 hd 2'' sans doute coupé lors du test mais un écran.
• core 2 duo = 2 hd, 4 ventillos, 4Go de mémoire ....
• epia = compact flash, vidéo intégrée et rien d'autre
• P4 = pas de HD, pas d'ecran (video off et vieille carte)
• sempron = 3 HD, 4 ventillos ...
• athlon = 1 hd, 2 lect cd, 4 ventillos, clavier souris, 2 ecrans (non comptabilisés mais CV costaude)

Bref des configurations vraiment hétéroclites, ajoutons à cela en onduleur en série sur chaque machine. l'idée est donc plutôt d'avoir des ordres de grandeur pour moi. Je note d'ailleurs que le remplacement que je vais effectuer (l'epia à la place de l'athlon est donc le plus rentable)

Au passage .... ma facture d'électricité annuelle liée aux PC : 350Wh soit 300€ ... pas mal quand même et l'epia devrait me faire gagner 20% là dessus... bonne nouvelle ! Non ?!?

Non en effet, pas tout à fait ... je vous ai parlé de mon grille pain (la carte video fan-less) et bien quand on met les deux ensemble :

On arrive à une consommation de 63W soit une conso supplémentaire de 20W alors que je ne fait que de la 2D de base sur un seul écran sans compter l'échauffement énorme qui va avec bref l'économie passe de 128W à 60W c'est toujours ça mais c'est moins bien.
L'utilisation du lecteur cd me fait monter à 75W, donc 12W de mieux.

J'en ai parlé hier suite à la configuration de la gestion dynamique de la fréquence de fonctionnement pour transformer cette carte EPIA SN en une carte silencieuse, il va me faloir user d'un minimum de configuration... Si je résume ma problématique, on peut dire les choses ainsi :
Le bios ne permet pas de régler la fréquence, ainsi la carte démarre en mode consommation maximum et élévation de la température associée. Il y a bien moyen de régler la vitesse des ventilateurs pour faire taire la bête mais l'échauffement au boot et trop dangereux. Le mode dans lequel le bios se charge de la régulation serait très utile, mais une fois le noyau lancé, il ne fait plus rien. Bref, il n'y a pas beaucoup de solutions: il faut démarrer tout ventilateur en route.
C'est donc dans une seconde étape, une fois le kernel booté que l'on va pouvoir jouer avec la fréquence et la vitesse des ventilateurs, dès lors que ces éléments seront controlable par soft. Mon but est le suivant : reproduire l'asservissement des ventilateurs réalisé par le bios par l'emploi d'un logiciel lisant la température et pilotant la ventilation. Ce logiciel pourra en outre activer ou non la puissance maximum de la CPU en fonction du besoin utilisateur. Pour être plus clair : ma machine tourne 24/24, lorsque je ne suis pas devant je lui fait faire e gros calculs (en idle) ; pour cela une mode basse conso sans ventilo me semble très bien, si par contre, je commence à consommer plus de x% de cpu hors idle et ce un certain temps, je souhaite que la CPU puisse délivrer le meilleur d'elle même... Tout ca n'est pas très novateur ca existe sur les portables depuis belle lurette (à la gestion du nice près). Voila donc où je veux en venir ... reste à en voir les étapes

Je pars donc de ce lien qui va me permettre de mettre à jour mon noyau pour supporter le pilotage du ventilo et des capteur de température (enfin j'espère). Pour ce qui est de la fréquence, il faut voir cet article sur le sujet.

D'après la doc il faut commencé par patcher le noyau pour lui permettre de supporter le vt1211, comme le patch est spécifique à des ditributions autres que la Suse 10.3, il faut se faire le patch à la mano ... et là pour l'instant, demi bonne nouvelle le VT1211 est intégré à mon noyau, cependant le code est assez différent... et il semble que par défaut ca ne soit pas intégré à mon noyau ... la petite dépendence sur "EXPERIMENTAL" me rassure quand à la faisabilité donc GO!!! pour un make xconfig Et là ohhh déception !!! le vt1211 est bien présent, il est même compilé ... Mais sur cette carte VIA EPIA SN ... il n'y a pas de vt1211 pour le monitoring hardware, mais sans doute un autre chip non supporté !!!!

Bon, bref ... pour l'instant c'est mort .... et j'avoue que ca m'ennuie fortement !! Heureusement, la solution n'a pas tardé à venir ... et cet article décrit tout cela ...

Suivant un article disponible ici tout est fourni pour permettre le support de cpu-freq...
Je dois donc installer les sources du noyau, le patcher, pour commencer, il faut aussi installer les RPM de gcc et de Make (grrrrrrrr ce n'est pas par défaut !! on est plus sous Linux ou quoi ?!?) bon passons !

Etape n°1 - récupérer la config du noyau courant pour le futur noyau par un petit make cloneconfig des familles.
Etape n°2 - patcher comme dans la doc, à savoir :

• décompresser l'archive kernel_e_powersaver_v...zip
• aller dans le directory créé : cd kernel_e_powersaver
• copier le fichier e_powersaver.c vers les sources de linux arch/i386/kernel/cpu/cpufreq/ en ayant pris soin de sauvegardé préalablement le fichier d'origine.
• lancer la configuration du noyau make xconfig (a condition d'installer les lib qt de développement)
• le noyau est alors modifié comme indiqué dans la documentation de référence (choix du modèle de processeur de type C7 et configuration de la gestion de la fréquence du CPU au niveau utilisateur.
• le noyau est recompilé par la commande make puis make modules_install
• copier les élements du nouveau noyau dans /boot (voir doc)
• créer l'initrd (simplement en tapant mkinitrd)
• créer la nouvelle entrée dans grub/menu.lst (comme dans la doc)

Apres un reboot sur le nouveau noyau, il faut charger le module modprobe e_powersaver puis il est possible de modifier la fréquence de fonctionnement du cpu en allant dans le répertoire /sys/devices/system/cpu/cpu0/cpufreq. Il sera alors possible de passer le cpu à 800 Mhz en envoyant echo 798096 > scaling_setspeed ou de revenir à la frequence haute avec la valeur 1795716. J'ai pu vérifié le résultat avec un petit programme de calcul très simple, rien à dire à 1800MHz ca va plus de 2 fois plus vite.Il reste à voir si l'on ne peut pas avoir plus de valeur ou au moins forcer un 1G plutot que 800M...
Attention, les nombre donnés ci-dessus peuvent varier, il faut donc lire le fichier scaling_available_frequencies pour connaitre les bonne valeurs.

Du coup, pour que la manip soit complete, il faudrait arriver à piloter le PWM des ventilo car le système géré par le bios n'a pas l'air de fonctionner au top une fois Linux démarré... et il serait alors possible de choisir un mode rapide avec ventilo et un mode traquilou... sans ventilo ! Ce qui va me conduire à bricoler quelque chose autour de ce lien... à suivre dans un prochain article ...