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 🙂

Bon, je vous en ai parlé par ailleurs, mais cette alimentation Fortron Zen 300W mérite bien un petit billet. Il s’agit une alimentation de 300W SILENCIEUSE !! Une fan-less comme on dit aussi … donc 0db de bruit émis, le pied !
Cette alim offre un look agréable avec sa couleur bleue, on ne peut que lui reconnaître une finition de qualité. Par rapport à  bon nombre d’autres alimentation fanless, elle a l’avantage de ne pas avoir d’énorme radiateur sur l’arrière, qui, sortant du boîtier pourrait poser des soucis d’intégration. L’alim Fortron Zen offre 2 connecteur d’alim SATA, 6 connecteur cd/hd et 1 connecteur DD. En outre vous avez le connecteur carte vidéo et l’alimentation carte mère en deux parties (24+4). La connectique répond donc aux normes en vigueur.

Cette alimentation est refroidie par de gros radiateurs internes et par une carcasse bien aérée, reste qu’une fois le boîtier fermé, les échanges ne se font plus que par la façade arrière, elle moins ouverte:

En tout cas, comme vous pouvez le constaté, le design est soigné, comme la qualité des connecteurs ; le prix, autour de 100€ n’est pas usurpé semble-t-il, d’autant que cela reste une des moins chère du marché en fan-less. Reste que le silence se paie assez chère, il est vrai.
Du point de vue performance, l’alim est annoncée comme ayant un rendement de 89% pleine charge, ce qui signifie que si l’on tire 300W au niveau du 220V elle devrait restituer 267W utiles pour la carte mère et donc dissiper le reste. Je n’ai pas fait ce test, toujours est-il que suivant les mesures que j’ai effectué, avec la charge de ma carte mère epia, l’alim consomme 68W sur le 220V, ce qui n’est pas meilleurs que mon autre alim Fortron elle avec ventilateur.

Du point de vue de la puissance délivrée, d’après la documentation :

• Le 5V délivre entre 0,3 et 20A (soit 0,15 et 100W)
• Le 12V est divisé en 2 sources indépendantes délivrant de:
  • 1 à  8A (soit 12W et 96W)
  • 1 à  14A (soit 12W à  168W)
• Le 3.3V délivre entre 0,5 et 20A (soit 1,6W et 66W)

En combiné, les 5V et 3.3V peuvent délivrer 120W max et au global, l’alim délivrera au max 300W.

La surprise parmi mes mesure aura été la consommation à  vide, c’est à  dire lorsque l’ordinateur est en arrête mais l’alimentation branchée et même lorsque l’alimentation est branchée, sans charge. La consommation est alors de 22W. Pour ma part, la machine étant allumée 24/24 ça n’a pas d’impact, mais cette consommation peut sinon représenter dans les 20€ d’électricité.
J’ai par ailleurs pu remarqué que la consommation oscillait beaucoup fortement que sur les autres alimentations lorsque je sollicitais le système. Mon interprétation (mais c’est assez personnel) est que cette alimentation n’intègre pas les gros condensateurs de filtrage habituels, sans doute par manque de place autour des gros radiateurs. Ces condos servent de réserve d’énergie et absorbent les pic de consommation. Leur absence fait que l’alim tire ces pics sur le 220W. Ceci n’est en aucun cas un soucis à  mon avis, il s’agit juste d’une particularité remarquable.

Du point de vue de la température, après 1h de fonctionnement à  75W le boîtier est tiède (34 degrés C)… Il n’y a rien d’anormal. Il est toutefois indiqué que le coté supérieur du capot ne doit pas être couvert, il faudra donc veiller à  ce que l’alim ne touche pas le sommet du boîtier, sans quoi cette contrainte sera difficile à  respecter. Je ne serai dire quel doit être l’espace minium à  laisser, pour ma part, il ne pourra dépasser le centimètre … espérons que ça suffise.
(LOL … Je ne l’ai compris qu’une fois dans le boitier, mais la capot est en fait en bas et non en haut … du coup, une fois dans la boite, pas de problèmes….la chaleur se dissipe du coté de la carte mère)

Dernière remarque, comme cette alimentation n’a pas de ventilateur, elle ne pourra servir d’extraction de chaleur pour le boîtier (normal, et c’est le but), par conséquent, il faut bien s’assurer que la chaleur du boîtier reste acceptable au risque d’avoir une surchauffe… Mon point de vue personnel, et que pour un système 100% fanless comme celui que je monte, il faudra bien faire usage des sondes de températures et des capacités PWM permettant de piloter un ventilateur d’extraction de secourt, principalement en été…

Enfin une dernière photo pour la route.

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