Un test de performance EPIA 1.8G vs Athlon 1.5G

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.

Quelques tests de débits sur les suports de stockage de masse

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

Causons puissance

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

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

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

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

Essayons quelques tests dynamiques:

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

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

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

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

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

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

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

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

Petit retour sur les classement watt/bogomips:

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

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

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

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

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

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

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

Configuration de la gestion dynamique de la rotation du ventilateur et sondes de température

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

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

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

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

Configuration de la gestion dynamique de la rotation du ventilateur et sondes de température

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

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

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

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

Configuration de la gestion dynamique de la fréquence du processeur dans le noyau

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

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

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

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

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

Test OpenSuse 10.3

L’open suse 10.3 est distribué sous la forme de CD (deux en fait) et non d’un DVD comme par le passé. Pour ma part, n’étant pas très branché DVD j’en suis très content. Par contre, pas d’installation réseau pour cette nouvelle version, du moins pas directement distribuée sur le site
Seul le premier CD est vraiment nécessaire à l’installation et il est ainsi possible d’avoir une Linux suffisamment complet à partir de cela. Toutefois le support du français sera partiel, ce qui est plutôt dommage. Dès le début de l’installation on vous proposera donc de vous connecter aux repositories réseau pour récupérer l’ensemble des packages. En effet, il ne faudra par exemple pas compter sur les CD fournis pour obtenir les sources des packages. Autre nouveauté, on trouvera directement les repositories tiers comme packman, cela simplifie la donne.

L’installation est classique avec moins d’étapes que précédemment, c’est rapide avec peu de questions posées mais toujours l’accès au mode expert. J’ai pu réalisé l’installation sur une disque externe USB sans soucis, mon matériel plutot atypique (via epia) a été correctement détecté et tout fonctionne.

Je regrette un point qui me fait peur, ayant souhaité compiler les différents modules de type MTD du noyau, je me suis rendu compte que ceux intégrant du code sujet à brevets logiciels (non applicable en Europe) avaient été purement et simplement retirés des sources. Je comprends qu’ils ne soient pas cochés par défaut pour respecter les lois de chaque pays, mais doit-on pour autant les enlever alors qu’ils font parti du noyau d’origine et qu’en France j’ai légalement le droit de m’en servir ? Pour rappel, les nouvelles lois françaises (DADVSI) rendent l’utilisation des services de P2P illégaux, ceux-ci doivent il pour autant être retiré des distributions ?

Installation de la suse 10.3 sur un VIA EPIA SN 18000

Je ne connais pas encore la suse 10.3, c’est l’occasion de l’installer pour test avant la mise en place définitive prévue plus tard …. Cliquez sur “lire la suite” pour avoir tous les détails….

En général j’installe mes Suse depuis le réseau, mais la 10.3 n’est plus disponible que sous forme de CD d’installation dirait-on …. Je vais tenter un truc un peu particulier du fait que je souhaite utiliser une Compact-Flash comme disque dur et que quelques tests préliminaires s’imposent. La carte ne disposant que d’un seul connecteur PATA, n’ayant pas en rab de disque SATA, je vais donc installer la suse 10.3 sur un disque USB, ce qui ne semble pas poser de problèmes.
J’ai choisi une configuration plutôt par défaut en retirant les jeux et appArmor histoire de gagner un peu de place puisque les perf d’installation sur USB sont pas vraiment le top du top…. estimation 1h15 … Ah ! quand même ! ouf … passé les premiers packages 30 minutes suffisent … L’installation est l’occasion de jeter un oeil à  la monté en température de la carte mère lors de la décompression des RPM…. RAS ! température ambiante …
L’installation des rpm terminée, le système reboot tout seul, installation de GRUB faite, par défaut sur le HD principal (ma compact flash) ; la configuration du système peut commencer. Premier écran : choix du mot de passe root, avec la bonne idée d’avoir ajouté une zone pour tester le layout du clavier ! Le reste de la configuration est classique …
Les deux cartes réseaux sont reconnues en 100M et 1G … tout va bien jusqu’à  la configuration du hardware … après 2 minutes sur l’écran de YAST, celui-ci disparait et me renvoie sur la console… 2 minutes de plus et retour sous Yast !! ouf, il devait s’agit d’un test de configuration de la carte graphique ! Visiblement la partie graphique est correctement reconnue tout comme le chipset audio et le bluetooth meme si cette carte n’en a pas (lol)
Voilà  ! installation terminée et a première vue, tout semble fonctionner, c’est plutôt une très bonne nouvelle.
… sauf que …

Ben impossible d’atteindre le runlevel 5 et de lancer X … c’est balo ! allez, un petit coup de Yast pour se tenter une configuration plus light… Sax2 m’en proposant une qui n’a pas l’air mal (1024×768 – 16b au lieu de 24), c’est parti …. et me voila sous KDE. ouf !

Coté post-config, par défaut sensors-detect ne trouve rien sur cette carte et cpu. Par ailleurs, sans le cd d’add-on beaucoup de chose restent en anglais bien que le fraçais ait été sélectionné, mais pas de mauvaise surprise ce point était mentionné dès le début de l’installation.
Coté puissance (approche de base), parmi mes machines, le classement est le suivant:

  • mon Core 2 Duo 1,7G 2×4660 bogomips
  • mon P4 1,7G 4200 bogomips
  • la carte via epai SN 18000, 3593 bogomips pour 1795MHz
  • mon Athlon 1800+ @ 1.5G 3032 bogomips
  • mon Sempron @ 1.4G 2800 bogomips environ

Je vous ferai une série de tests comparatifs plus poussés sur ces machines très bientôt dans un futur article… je vais maintenant essayer de régler mon problème de Checksum CMOS …