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.

En première approche, j’ai tenté une régulation dans la zone des 40-45°C, solution qui ne s’avère pas un très bon choix… nous le verrons bientôt. Par conséquent, j’ai tenté de tracer quelque courbes de chauffe pour évaluer suivant quel modèle cette carte s’échauffait. Dans un premier temps, j’ai pris des mesure, à  pleine charge mais en basse fréquence (700MHz avec calculs dnetc en tà¢che de fond) et à  différentes vitesses de ventilation (cpu seul). La courbe ci-dessous représente cet échauffement.

Outre la courbe de ventilation pour une valeur de 100/255, on peut remarquer un courbe logarithmique, se stabilisant vers les 53°C, de fait, réguler dans la zone des 40°C où les pentes sont les plus fortes entraîne un effet de yoyo (arret-relance des ventilateurs) sans grand intérêt. Par ailleurs, le gain entre de refroidissement entre 250 et 200 est faible pour un bruit bien supérieur.

Je dirai qu’en basse fréquence, on peut ventiler à  une vitesse de 100 / 255 (environ 1900rpm) jusqu’à  42°C, au delà  il faut augmenter à  150 (3700RPM) puis passer à  200 (5300RPM) à  partir de 53°C.

Voyons les mêmes courbes mais à  pleine puissance (1.7 GHz) et toujours en pleine charge:

Premier constat, dans mon système à  pleine charge et en ventilation maximum, la température atteint rapidement les 61°C qui est la limite que je me suis fixé pour mes tests ne sachant pas trop quel est le maximum. Je peux d’or et déjà  en conclure qu’une extraction d’air de mon boîtier est inévitable. Cette situation me semble assez cohérente d’une part par la présence de mon “grille pain” ou carte vidéo trop proche du processeur (ce qui va changer avec la future carte) et d’autre part par l’alim fanless qui émet sa chaleur elle aussi du coté du processeur.

Ayant un ventilo de boîtier très silencieux lorsqu’il est configuré à  une vitesse de 50/255 ou 100/255, je vais voir quel effet positif cela peut avoir sur mon refroidissement à  pleine charge …

Le résultat est très intéressant car l’extraction effectuée par le ventilateur du boîtier permet de stabiliser la température autour de 57°C assez rapidement alors que l’on voit bien que lorsqu’il ne tourne par ou insuffisamment on rentre en surchauffe. Je dirait bien, par conséquent que le choix d’une alimentation fanless n’est pas vraiment judicieux s’il faut malgré tout ventiler … mais bon, restons positif ! il ne reste plus qu’à  trouver jusqu’où descendre la vitesse du ventilo du CPU pour limiter au maximum le bruit ! Voici le résultat, cette fois, c’est le ventilateur de boîtier qui est fixe à  100 et le ventilateur de la carte mère qui varie.

La valeur 100 (1900rpm) qui a l’avantage d’être vraiment silencieuse ne passe malheureusement pas ici. par contre 150 résiste bien ce qui est assez positif. Pour ce qui est de l’échauffement, ces informations sont assez complète, il me reste à  les synthétiser puis à  regarder les courbes, non pas de chauffe mais de raffraichissement de sorte à  trouver au mieux comment refroidir la bête sans pour autant tout mettre au max quand on arrive à  62°C …

Voyons maintenant comment se comporte la carte lorsque le charge CPU est presque nulle et que le CPU est en fréquence max:

On constate que le ventilateur de boîtier et une aide importante et qu’une vitesse de 100 est suffisante pour rafraîchir ; on constate surtout que couper le ventilateur de processeur, même sans charge CPU n’est pas envisageable, une vitesse de 100, acceptable au niveau bruit est elle possible ; le couple 100 / 100, non testé ici, devrait être une bonne solution assez silencieuse.

Enfin pour terminer, voyons quel couple permet de raffraîchir un système en charge :
Pour ce dernier cas, il semble qu’une vitesse de fan cpu à  200 soit vraiment recommandée, 250 n’apportant rien ; par contre la ventilation boîtier n’apporte pas beaucoup au dessus de 100.

Me voila donc prêt pour la seconde partie : écrire le script de régulation !

Bon, après 1 mois de labeur pour la mise au point de cette machine, j’ai enfin monté l’ensemble dans le boîtier, l’occasion de bonnes surprises mais aussi de nouvelles déconvenues. Les photos sont à  venir…

Donc coté silence, il faudra repasser, bien que j’ai mis au point le programme de régulation et que mon PC tourne en partie en basse fréquence, le CPU chauffe tout de même et il est vraiment pas évident de couper la ventilation sans passer au dessus des 45°C au CPU. J’ajoute que le ventilateur de 40mm de via est un mauvais choix de leur part. Il est pour commencer bruyant, j’espérais qu’une fois enfermé dans sa boîte on ne l’entendrait plus, mais on contraire, il semble qu’il y trouve une bonne caisse de résonance. Ainsi, au delà  de 50% de son régime max, il siffle ce qui est plutôt désagréable. Le pilotage du ventilateur de boîtier est lui un bonheur.

Coté alimentation une bonne surprise, je ne comprenais pas comment ne pas couvrir le dessus alors que les boîtier n’ont généralement pas de place au dessus de alim… et bien en fait, le dessus est le dessous … lol … du coup, pas de problème, la chaleur se dissipe vers l’intérieur du boîtier. J’ai par contre rencontré un soucis plus gênant avec l’alim Fortron Zen 300 : lorsque je branche le cable IDE de mon lecteur/graveur impossible alors de démarrer la carte mère… Etrange, car ce lecteur n’avait pas posé de problèmes jusqu’alors.. Par ailleurs, avec un autre lecteur j’ai aussi eu ce type de soucis, mais c’etait durant mes premiers tests est moins fréquent.

Coté carte vidéo… le bug qui tue ! après tout le mal que j’ai pu pensé de ce grille pain, voila en plus qu’on y ajoute les bug des drivers ATI : impossible de faire un CTRL+ALT+Fx pour changer de console, et plus ennuyeux, impossible alors d’avoir deux sessions ouvertes en simultané !! S’en est trop pour cette fois et je vais donc changer de carte graphique.

En résumé, suite à  cette installation, me revoilà  passant à  la caisse pour :

• Un lecteur / graveur cd en serial ATA
• Un ventillo 40mm silencieux
• Une carte Video fanless, MSI GeForce 3700GS, avec dual-head, mais pas dual-dvi (on ne peut pas tout avoir)

La carte vidéo a été retenu pour les critères suivant:

• Basé sur Nvidia et pas Ati !
• Confirmée comme fonctionnant sous Linux
• Fanless
• avec radiateur situé coté opposé au processeur pour limiter la surchauffe
• avec radiateur de taille raisonnable

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”

Tout commence par une question posée sur le forum de lm_sensors par quelqu’un de plus malin que moi qui a repéré que lm_sensors voyait quelque chose sans pour autant le détecter. (voir ce lien) Le chip de monitoring de la carte sn18000 est un SCH3112 dont le support est assuré par le module dme1737. Ce module est inséré dans le noyau 2.6.23 ou 2.6.24, pas de chance, la suse 10.3 est basée sur un noyau 2.6.22 (ndr: pourquoi j’ai comme une impression de dejà  vu sur ce coup encore ?!?) Bref … va faloir bricoler !

Normalement, si vous avez suivi la première étape de configuration de la frequence du cpu, vous avez vos sources du noyau installées et tout ce qu’il faut pour compiler. Il nous faut donc nous préoccuper, simplement, de la partie module hmon.
Pour se faire il faut recupérer le fichier qui va bien depuis une version plus recente du noyau. Pour ma part je suis parti d’une 2.6.24 récupérée sur kernel.org et j’en ai extrait le fichier dme1737.c présent dans /drivers/hwmon pour le copier dans mes sources “/usr/src/linux/hwmon/”. Ce fichier doit être modifié comme suit:
– if (dme1737_i2c_get_features(0x2e, data) && /* lignes sources à  remplacer */
– dme1737_i2c_get_features(0x4e, data)) {
—
+ if (dme1737_i2c_get_features(0x162e, data) && /* lignes après remplacement */
+ dme1737_i2c_get_features(0x164e, data)) {

et

– if (dme1737_isa_detect(0x2e, &addr) && /* lignes sources à  remplacer */
– dme1737_isa_detect(0x4e, &addr)) {
—
+ if (dme1737_isa_detect(0x162e, &addr) && /* lignes après remplacement */
+ dme1737_isa_detect(0x164e, &addr)) {

Ces modifications servent à  ce que lm_sensors détecte correctement le chip car il semble que VIA ne l’ai pas mis à  l’adresse normale pour ce composant et que ce choix empeche une détection correcte, du coup, il faut mettre en dur la nouvelle adresse. Ainsi, même si vous voulez vous baser sur un kernel 2.6.24 directement pour éviter mon bricolage douteux, il faudra tout de même réaliser cette petite rustine.

Ces petites modifications faites il faudra rajouter ce fichier à  la chaine de compilation. Pour se faire, éditer le fichier Makefile du répertoire “/usr/src/linux/drivers/hwmon” et ajouter la ligne suivante:

obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
obj-m += dme1737.o

Avant la compilation, j’ai aussi edité le fichier /usr/src/linux/.config pour modifier la ligne suivante comme suit:
CONFIG_LOCALVERSION=”-custom”
Ainsi, le noyau et les modules auront cette extension plutot que -default et il sera possible de faire cohabiter le noyau d’origine avec le noyau nouvellement compilé.

Ensuite, on va compiler avec le classique make; make modules_install ; make install Il faut enfin ajouter l’entrée e ce nouveau noyau dans le menu de grub ; quoi qu’il a déjà  été mis à  jour par le make install 😉

S’en suit un petit reboot et le chargement du module modprobe dme1737. Mais avant d’en finir, il est nécessaire d’utiliser la version 3 ou supérieur de lm_sensors qui se trouve ici. Une fois compilée et installé, le résultat est le suivant:
epia:/usr/local/bin # ./sensors
sch311x-isa-0a70
Adapter: ISA adapter
in0: +0.00 V (min = +0.00 V, max = +6.64 V) ALARM
in1: +1.75 V (min = +0.00 V, max = +2.99 V)
in2: +3.29 V (min = +0.00 V, max = +4.38 V)
in3: +4.91 V (min = +0.00 V, max = +6.64 V)
…
fan1: 0 RPM (min = 0 RPM)
fan2: 5070 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
temp1: +42.6°C (low = -127.0°C, high = +127.0°C)
temp2: +43.0°C (low = -127.0°C, high = +127.0°C)
temp3: +41.4°C (low = -127.0°C, high = +127.0°C)

Le controle du PWM se fait alors en modifiant les registres accessible dans le répertoire suivant: “/sys/bus/platform/drivers/dme1737/dme1737.2672” on trouve l’accès à  tous les indicateurs de température et le controle des pwm.
Pour ces dernier, c’est le pwm2 qui est utilisé pour le ventillateur du CPU. Un des fichiers permet de modifier le mode de fonctionnement qui par defaut est en automatique. Dans ce cas, il n’est pas possible de piloter le ventilateur directement. Le chamgement de mode en manuel se fait de la façon suivante :
echo 1 > pwm2_enable
Ensuite, il est possible de couper le ventilateur:
echo 10 > pwm2 /!\ Attention, ça peut vite chauffer !
Puis de le relancer:
echo 255 > pwm2

Voila plus précisemment ce que dit la doc :

Name                            Perm    Description
176 	                                ---
177 	cpu0_vid                        RO      CPU core reference voltage in
178 	                                        millivolts.
179 	vrm                             RW      Voltage regulator module version
180 	                                        number.
181 	
182 	in0-6_input                   RO      Measured voltage in millivolts.
183 	in0-6_min                     RW      Low limit for voltage input.
184 	in0-6_max                     RW      High limit for voltage input.
185 	in0-6_alarm                   RO      Voltage input alarm. Returns 1 if
186 	                                        voltage input is or went outside the
187 	                                        associated min-max range, 0 otherwise.
188 	
189 	temp1-3_input                 RO      Measured temperature in millidegree
190 	                                        Celsius.
191 	temp1-3_min                   RW      Low limit for temp input.
192 	temp1-3_max                   RW      High limit for temp input.
193 	temp1-3_offset                RW      Offset for temp input. This value will
194 	                                        be added by the chip to the measured
195 	                                        temperature.
196 	temp1-3_alarm                 RO      Alarm for temp input. Returns 1 if temp
197 	                                        input is or went outside the associated
198 	                                        min-max range, 0 otherwise.
199 	temp1-3_fault                 RO      Temp input fault. Returns 1 if the chip
200 	                                        detects a faulty thermal diode or an
201 	                                        unconnected temp input, 0 otherwise.
202 	
203 	zone1-3_auto_channels_temp    RO      Temperature zone to temperature input
204 	                                        mapping. This attribute is a bitfield
205 	                                        and supports the following values:
206 	                                                1: temp1
207 	                                                2: temp2
208 	                                                4: temp3
209 	zone1-3_auto_point1_temp_hyst RW      Auto PWM temp point1 hysteresis. The
210 	                                        output of the corresponding PWM is set
211 	                                        to the pwm_auto_min value if the temp
212 	                                        falls below the auto_point1_temp_hyst
213 	                                        value.
214 	zone1-3_auto_point1-3_temp  RW      Auto PWM temp points. Auto_point1 is
215 	                                        the low-speed temp, auto_point2 is the
216 	                                        full-speed temp, and auto_point3 is the
217 	                                        temp at which all PWM outputs are set
218 	                                        to full-speed (100% duty-cycle).
219 	
220 	fan1-6_input                  RO      Measured fan speed in RPM.
221 	fan1-6_min                    RW      Low limit for fan input.
222 	fan1-6_alarm                  RO      Alarm for fan input. Returns 1 if fan
223 	                                        input is or went below the associated
224 	                                        min value, 0 otherwise.
225 	fan1-4_type                   RW      Type of attached fan. Expressed in
226 	                                        number of pulses per revolution that
227 	                                        the fan generates. Supported values are
228 	                                        1, 2, and 4.
229 	fan5-6_max                    RW      Max attainable RPM at 100% duty-cycle.
230 	                                        Required for chip to adjust the
231 	                                        sampling rate accordingly.
232 	
233 	pmw1-3,5-6                    RO/RW   Duty-cycle of PWM output. Supported
234 	                                        values are 0-255 (0%-100%). Only
235 	                                        writeable if the associated PWM is in
236 	                                        manual mode.
237 	pwm1-3_enable                 RW      Enable of PWM outputs 1-3. Supported
238 	                                        values are:
239 	                                                 0: turned off (output @ 100%)
240 	                                                 1: manual mode
241 	                                                 2: automatic mode
242 	pwm5-6_enable                 RO      Enable of PWM outputs 5-6. Always
243 	                                        returns 1 since these 2 outputs are
244 	                                        hard-wired to manual mode.
245 	pmw1-3,5-6_freq               RW      Frequency of PWM output. Supported
246 	                                        values are in the range 11Hz-30000Hz
247 	                                        (default is 25000Hz).
248 	pmw1-3_ramp_rate              RW      Ramp rate of PWM output. Determines how
249 	                                        fast the PWM duty-cycle will change
250 	                                        when the PWM is in automatic mode.
251 	                                        Expressed in ms per PWM step. Supported
252 	                                        values are in the range 0ms-206ms
253 	                                        (default is 0, which means the duty-
254 	                                        cycle changes instantly).
255 	pwm1-3_auto_channels_zone     RW      PWM output to temperature zone mapping.
256 	                                        This attribute is a bitfield and
257 	                                        supports the following values:
258 	                                                1: zone1
259 	                                                2: zone2
260 	                                                4: zone3
261 	                                                6: highest of zone2-3
262 	                                                7: highest of zone1-3
263 	pwm1-3_auto_pwm_min           RW      Auto PWM min pwm. Minimum PWM duty-
264 	                                        cycle. Supported values are 0 or
265 	                                        auto_point1_pwm.
266 	pwm1-3_auto_point1_pwm        RW      Auto PWM pwm point. Auto_point1 is the
267 	                                        low-speed duty-cycle.
268 	pwm1-3_auto_point2_pwm        RO      Auto PWM pwm point. Auto_point2 is the
269 	                                        full-speed duty-cycle which is hard-
270 	                                        wired to 255 (100% duty-cycle).

Un sacré moment que je l’attendais cette carte, entre pénurie sur l’ancien modèle et délai de livraison d’une semaine … enfin, elle est arrivé et mon pc silencieux va pouvoir prendre forme !
J’ai ainsi opté pour un disque dur de type SSD du pauvre, à  savoir une carte compact flash …. enfin, du pauvre, 8G pour 190€ ça m’a quand même ramené quelques années en arrière coté tarif. Hors mis ce point, pas de regret, il n’y a pas plus silencieux ni moins gourmand en énergie. La bête est estampillée x300, il faudra comprendre que le débit est de 300 * 150Kb/s soit 45Mb si l’on fait ce calcul, mais seulement 40 selon le constructeur … allez comprendre ! Ça, c’est pour la fiche technique du vendeur. Pour la photo, voyez ci-dessous … mais ça n’a rien de bien hors du commun !

A noter que sur eBay, j’ai trouvé des carte de 8Go autour de 30€, mais aucune informations sur le débit n’était indiqué ; dommage, car ça aurait pu être un très bon plan.

Coté installation dans la machine, aucun soucis, la détection par mon Linux s’est très bien passé, y compris avec un noyau de plus d’un an, j’ai un petit pincement au coeur depuis qu’un collègue m’a dit avoir eu des soucis de compatibilité entre Linux et des compactFlash, mais là , nickel. J’ai donc pu procéder à  quelques tests, rapides, pour voir la performance.
Les 40Mo/s y sont presque puisqu’en pic, la carte atteint 39Mo/s, (mesuré avec un hdparm -t) Le niveau d’un disque dur standard est donc atteint ce qui présente un point très positif dans le cadre d’un remplacement où l’on ne souhaite pas forcement régresser en performance, lorsque l’on vise à  gagner en silence. Là  où le composant se distingue vraiment du lot, c’est en temps d’accès ! L’outil seeker révèle un temps moyen de 0,56ms … à  coté des 15ms d’un disque classique, c’est 30 fois plus rapide !! impressionnant ! et par rapport à  un modèle de compact Flash plus ancien, c’est encore pas loin de 3 fois mieux. Bref, là  dessus, il me semble difficile de faire beaucoup mieux. Du coup, la performance lors d’accès classiques à  des fichiers (et pas en vitesse maxi comme testé avec hdparm -t) est bien meilleur que celle d’un disque classique. Seeker donne un résultat de l’ordre de 8.1Mo/s, loin devant les quelques 500Ko/s d’un disque classique.
En bref, pour la perf, il n’y a rien à  redire à  cette carte. Je me souciai de l’aspect marketing de la chose, on vous annonce x300, vous obtenez bien vos 40Mo ou pas loin avec hdparm et vous tomberiez dans les 100Ko/s lors d’un utilisation normale… et bien NON, ca fonctionne ! 8.1 Mo/s dans les pires conditions… c’est top !
Maintenant, que dire vraiment des x300 … voyons … si l’on considère ma vielle carte 40Mo qui sortait 1.8Mo/s en burst par rapport à  celle-ci, on peut dire que la carte 8G est 21 fois plus rapide alors que sur un accès aléatoire, le gain n’est que de 3.24, mais bon .. franchement … je suis vraiment satisfait

Il ne reste donc qu’une seule inconnue … combien de temps va-t-elle tenir ? La durée de vie d’une compact flash est vraiment moindre de celle d’un disque magnétique classique, les écritures multiples finissent par détruire la carte (le retour des bon vieux secteur défectueux…). C’est particulièrement le cas lorsque le swap d’un Unix est utilisé, j’ai donc choisi une configuration avec pas mal de mémoire RAM pour limiter l’usage du cache ; de même mettre /tmp dans un ram disque pourrait aider à  préserver la flash. Enfin, le /home est particulièrement accédé lui aussi, pour ma part, il est sur un disque réseau, donc pour ce point c’est réglé. A ce sujet, voir un article complémentaire ici.

Autre petit soucis à  corriger avec cette carte, ou plutôt avec les derniers noyau Linux, 2.6.23 et 2.6.24 qui visiblement ne détectent pas correctement la carte et qui par conséquent limite son utilisation à  du simple DMA impliquant des perf pourries (14M au lieu de 40M)… Heureusement, par hasard j’ai trouvé ici (merci whirleyes) la solution. Je vous résume cela en gros :

1. editer le fichier du noyau …/drivers/ata/libata-core.c

2. ajouter vers la ligne 113, après MODULE_PARM_DESC(noacpi,… les lignes suivantes :
int libata_force_cbl = 80;
module_param_named(force_cbl, libata_force_cbl, int, 0644);
MODULE_PARM_DESC(force_cbl, “force PATA cable type (0=keep, 40=40c, 80=80c)”);

Ces lignes permettent d’ajouter un paramètre qui pourra être passé au noyau pour forcer ou non la détection complète de la carte. Ici, le fait de mettre ”libata_force_cbl à  80 force la détection en 80c, il est possible de mettre 40 ou 0 pour une détection automatique 40/80 dans ce cas (solution initiale)

3. Ensuite, vers la ligne 4063, on trouve if (xfer_mask & (0xF8 << ATA_SHIFT_UDMA)) { … tout le bloc if va etre remplacé de :

if (xfer_mask & (0xF8 << ATA_SHIFT_UDMA))
// UDMA/44 or higher would be available
if((ap->cbl == ATA_CBL_PATA40) ||
(ata_drive_40wire(dev->id) &&
(ap->cbl == ATA_CBL_PATA_UNK ||
ap->cbl == ATA_CBL_PATA80))) {
ata_dev_printk(dev, KERN_WARNING,
“limited to UDMA/33 due to 40-wire cable\n”);
xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
}

à

if (xfer_mask & (0xF8 << ATA_SHIFT_UDMA)) {
switch (libata_force_cbl) {
case 40:
/* limit to UDMA/33 */
ata_dev_printk(dev, KERN_INFO, “forcing 40c\n”);
xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
break;
case 80:
/* ignore cable checks */
ata_dev_printk(dev, KERN_INFO, “forcing 80c\n”);
break;
default:
/* UDMA/44 or higher would be available */
if ((ap->cbl == ATA_CBL_PATA40) ||
(ata_drive_40wire(dev->id) &&
(ap->cbl == ATA_CBL_PATA_UNK ||
ap->cbl == ATA_CBL_PATA80))) {
ata_dev_printk(dev, KERN_WARNING,
“limited to UDMA/33 due to 40-wire cable\n”);
xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
}
}
}

4. Il faut ensuite modifier le fichier drivers/ata/libata-eh.c comme suit :
remplacer

(ehc->i.flags & ATA_EHI_DID_RESET))

par

(ehc->i.flags & ATA_EHI_DID_RESET)) { ap->cbl = ap->ops->cable_detect(ap); if (!(ap->flags & ATA_FLAG_SATA) && libata_force_cbl) { switch (libata_force_cbl) { case 40: ata_port_printk(ap, KERN_INFO, “forcing 40c\n”); ap->cbl = ATA_CBL_PATA40; break; case 80: ata_port_printk(ap, KERN_INFO, “forcing 80c\n”); ap->cbl = ATA_CBL_PATA80; break; default: ata_port_printk(ap, KERN_WARNING, “invalid force_cbl value %d\n”, libata_force_cbl); } } }

5. Puis editer libata.h
et après extern int libata_noacpi; ajouter extern int libata_force_cbl;

Il reste enfin à  recompiler, installer le nouveau noyau, nouveau module et reinstaller ce noyau puis rebooter … Le résultat est consultable après le boot en tapant la commande dmesg et en lançant un hdparl -t /dev/sda par exemple qui devrait vous ravir !

Commentaire de Ulhume

Une solution pour augmenter la durée de vie de votre carte flash est celle que l’on utilise pour le Zaurus, à  savoir utiliser un RAMDISK pour les dossiers /var et /tmp, en gros les seuls endroits où les données bougent beaucoup.

Une autre idée, est d’utiliser JFFS2, qui est un filesystem journalisé optimisé pour les flashs, et qui a un algorithme  spécial pour “randomiser” les écritures.

En espérant que cela puisse aider à  faire vivre plus vieille votre carte 🙂