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.