URL: https://linuxfr.org/users/khivapia/journaux/que-vaut-vraiment-lamd-geode-lx-800 Title: Que vaut vraiment l'AMD Geode LX 800 ? Authors: khivapia Date: 2008年10月15日T17:19:45+02:00 Tags: debian Score: 26 Bonjour à tous, Heureux possesseur d'un Fit-PC slim (www.fit-pc.com) tout neuf, je vous fais part de quelques tests et ordres de grandeur sur la puissance de calcul de la bête. Matériel : AMD Geode LX 800 (500MHz), disque dur IDE 5400 tpm. Processeur x586 (686 est possible mais émulé, donc non recommandé), chiffrement AES-128 et générateur aléatoire matériel. Distribution : Debian lenny (etch initialement, passée en lenny vu l'imminence de sa parution). Je passe sur l'installation à partir d'une clef USB via une console série, tout se passe bien quand on se décide à prendre l'image toute faite (qui nécessite une clef de 256MB) au lieu de tenter d'utiliser une clef 128 en copiant a minima les fichiers (image ISO businesscard), je vous laisse consulter [http://www.debian.org/releases/stable/i386/ch04s04.html.fr](http://www.debian.org/releases/stable/i386/ch04s04.html.fr) ). Ne pas oublier de préciser la console dans syslinux.cfg. ** 1) Modules matériels crypto & random. ** Le module de chiffrement AES et le générateur aléatoire matériel sont bien reconnus sous Linux depuis les versions 2.6.2x. Il est donc naturel d'essayer de quantifier leur apport dans le cadre d'une utilisation pratique. ** 1.1) AES ** L'application première d'un tel module sous Debian est bien évidemment le chiffrement des partitions (LVM pour /, /boot excepté). Bien sélectionner chiffrement AES-128-CBC à l'installation, le mode CBC étant (avec le mode ECB qui n'est pas recommandé) le seul supporté par le module matériel. On ajoute un ESSIV sha256 pour plus de sécurité (ça aura un impact comme vous le verrez). On évite par contre le remplissage du disque avec de l'aléas vu la puissance du processeur (le module matériel n'étant pas utilisable faute de module compilé dans l'image d'installation), à faire ensuite. On ajoute _geode-aes _ au fichier _/etc/initramfs-tools/modules _ pour qu'il soit chargé et utilisable par l'API crypto du noyau dès le démarrage. Exemple de résultat significatif (refaits plusieurs fois, aucun service ne tournant à part sshd): hdparm -t /dev/hda /dev/hda: £spaces£ £/spaces£Timing buffered disk reads: 90,6 MB in 3.05 seconds = 29,7 MB/sec hdparm -t /dev/mapper/ma_partition_chiffrée /dev/hda: £spaces£ £/spaces£Timing buffered disk reads: 41,6 MB in 3.05 seconds = 13,7 MB/sec ce qui est très correct. À noter que sha256 en logiciel fait tourner le processeur à plein, c'est donc lui qui nous limite. Ce ne serait sans doutes pas le cas avec un module matériel crypto un peu plus développé (par exemple via padlock). Si on retire le module _ geode-aes _ de l'initrd, les performances chutent drastiquement: hdparm -t /dev/mapper/ma_partition_chiffrée /dev/hda: £spaces£ £/spaces£Timing buffered disk reads: 17.4 MB in 3.05 seconds = 5,7 MB/sec ce qui n'est pas vivable. ** 1.2) Module d'aléas ** on charge le module _ geode-rng _ par la commande _ modprobe geode-rng _, il faut installer le paquet _ rng-tools _ pour qu'il soit utilisé. Ce paquet installe le démon rngd, qui est chargé de récupérer l'aléas du générateur matériel 20000 octets par 20000 octets, d'effectuer des tests cryptographiques (FIPS) dessus pour en vérifier la qualité, et ensuite de l'ajouter au pool d'entropie du noyau. On peut ensuite lire _ /dev/random _ (oui ami lecteur, tu as bien vu ! random et non urandom ou autres !) à plus ou moins 70ko/s (vérifier avec la commande _ dd if=/dev/random of=/dev/null _). Le démon rngd occupe environ 30% du processeur, le reste pour dd. ** 2) Le processeur en lui-même ** Je voulais profiter d'une des innovations de la dernière version de gcc, à savoir l'apparition d'une option de compilation spécifiquement dédiée au geode LX. ** 2.1) Le noyau ** Les sources du noyau Linux ne prennent pas encore en compte cette possibilité, il faut modifier (légèrement) un des Makefile pour que l'architecture soit la bonne # Geode LX support cflags-$(CONFIG_MGEODE_LX) += -march=geode au fichier _ arch/x86/Makefile_32.cpu_ donnent l'option demandée (vérifiable avec _ ps aux |grep geode _durant la compilation du noyau par exemple). 3 heures de compilation avec _ make-kpkg _ plus tard (noyau allégé de beaucoup de modules et de pilotes inutiles... je peux fournir mon .config si quelqu'un est intéressé), reboot, pas d'amélioration significative propre à l'architecture à mesurer (j'ai également modifié d'autres paramètres, la préemption et la fréquence de base) sauf peut-être un temps de démarrage plus rapide au niveau de l'initrd et de la détection du matériel, et une légère amélioration de la vitesse de lecture sur disque (de l'ordre de 3 à 4 % peut-être ? mais les mesures fluctuant déjà pas mal, je n'ai pas fait de stats détaillées. L'ordre de grandeur reste le même de toutes façons :-) ** 2.2) Benchmark nbench ([http://www.tux.org/~mayer/linux/](http://www.tux.org/~mayer/linux/) ) avec différentes options de compilation. ** Les différentes sources sur internet précisent qu'en général, vu le faible cache du geode LX (64kB = 32kB instructions, 32 kB données pour le L1, 128 kB pour le L2) il vaut mieux compiler avec l'option -Os (réduit la taille du code) plutôt que -O3) je voulais voir un peu ce qu'il en était et jouer avec les différentes options d'optimisation de gcc. Notamment, prendre un -Os mais en ajoutant certaines optimisation (précisées comme pouvant avoir un impact au niveau Il devient possible de mesurer l'impact du choix de l'architecture face à un x86 générique, on obtient des gains de temps allant de 20 à 50% suivant les options !! À noter que comparé à la liste des processeurs présentés ici [http://www.tux.org/~mayer/linux/results2.html](http://www.tux.org/~mayer/linux/results2.html) , le geode se sort très honorablement des tests faisant appel à la mémoire et au calcul sur les entiers, par contre est très lent en ce qui concerne les flottants - peu étonnant, la fiche technique détaillée disponible à [http://www.amd.com/files/connectivitysolutions/geode/geode_l(...)](http://www.amd.com/files/connectivitysolutions/geode/geode_lx/33234G_LX_databook.pdf) précise en effet page 202 que les opérations sur les _double _ sont émulées et prennent beaucoup plus de temps que les opérations sur des float). Les résultats sont les suivants, idem je peux fournir les résultats détaillés (différents tests sont exécutés, par exemple transformée de Fourier, chiffrement IDEA, tri, etc. les résultats varient suivant les options) : kernel : 2.6.26-geode C compiler : gcc version 4.3.2 (Debian 4.3.2-1) libc : libc-2.7.so NATIVE -s -static -Wall -O3 MEMORY INDEX : 11.665 INTEGER INDEX : 12.023 FLOATING-POINT INDEX: 10.855 GEODE (arch, O3 plus some optimizations) -s -static -O3 -fomit-frame-pointer -Wall -march=geode -fforce-addr -falign-loop s=2 -falign-functions=2 -falign-jumps=2 -funroll-loops MEMORY INDEX : 15.813 INTEGER INDEX : 13.508 FLOATING-POINT INDEX: 10.766 OPTIMIZE FOR SIZE (same options, except O3 is replaced by Os) -s -static -fomit-frame-pointer -Wall -march=geode -fforce-addr -falign-loops=2 -falign-functions=2 -falign-jumps=2 -funroll-loops -Os MEMORY INDEX : 15.680 INTEGER INDEX : 13.271 FLOATING-POINT INDEX: 10.642 OPTIMIZE FOR SIZE, PLUS SOME O3 & OTHER OPTIMIZATIONS: -s -static -fomit-frame-pointer -Wall -march=geode -fforce-addr -falign-loops=2 -falign-functions=2 -falign-jumps=2 -funroll-loops -fsee -ftree-vectorize -ffast-math -finline-functions -funswitch-loops -fpredictive-commoning -fgcse-after-reload -Os MEMORY INDEX : 16.333 INTEGER INDEX : 13.335 FLOATING-POINT INDEX: 10.774 **3) Compléments ** Les impressions générales sont bonnes, le processeur n'est pas très rapide mais il fonctionne très bien et il y a de la place pour bons nombres de services sur une telle configuration. J'avais vraiment peur pour des applications java, mais il s'en sort très bien. À ce sujet, il vaut mieux les lancer avec l'option java -server :-) pour un gain de performances sensible même si là encore non quantifié avec précision vu les variations de charge de l'application. Les capteurs de température fonctionnent très bien, pour fixer un ordre de grandeur à pleine charge le processeur monte à 47°C (pour une température recommandée inférieure à 70°C, critique à 85°C, le CPU chauffe un peu plus (70°C, max recommandé 86°C, critique 126°C). Pendant ce temps, le disque beaucoup sollicité monte à 43°C (c'est un seagate momentus). Le boîtier chauffe pas mal, mais on peut en général laisser la main dessus, d'ailleurs c'est amusant ce faisant on voit tout de suite la température baisser ! ben oui, la main au contact du boîtier évacue mieux la chaleur que l'air ambiant sans ventilation ni radiateur !). Enfin, la machine est aussi silencieuse que le disque dur, c'est-à-dire qu'on n'entend quasiment rien. À suivre : recompilation d'autres packages laissant espérer des gains appréciables quant aux optimisations liées à l'architecture (comme la libc...), apt-build semble être mon ami. Le flag -O3 (ou d'autres flags d'optimisation de la compilation) sont-ils réellement vecteurs d'instabilité ? [http://gentoo-wiki.com/CFLAGS_matrix](http://gentoo-wiki.com/CFLAGS_matrix) dit qu'il est considéré risqué, mais sans plus... Des retours d'expérience sur apt-build et -O3 ? Le plus impressionnant est selon moi les perfs du module matériel AES, openssl dispose d'un _ engine _ lui permettant d'utiliser le padlock de via, à quand un patch pour le geode ? Sinon il y a un projet qui cherche à proposer l'API crypto du noyau comme engine openssl (ocf framework for linux, [http://ocf-linux.sourceforge.net/](http://ocf-linux.sourceforge.net/) mais je n'ai pas vu grand-chose d'utilisable pour le moment. Dommage, si j'avais le temps et les compétences j'essaierais de contribuer, car certains trucs seraient très intéressant : utiliser ssh en précisant le mode de chiffrement AES-128-CBC, et éviter une grosse montée en charge, bien visible avec top, lors de transferts de fichiers un peu gros à haut débit (même sans compression. Avec _ssh -C_, c'est pire !)). PS (je profite de ce journal pour poser une question qui aurait plutôt sa place dans les forums, pardonnez-moi svp :) : si quelqu'un a acheté le même PC, peut-il me dire si le wi-fi est désactivé par défaut dans le BIOS ou non ? impossible de le faire fonctionner (j'ai tout essayé, chargé les modules rt73usb & co, installé les firmware du site de ralink dans /lib/firmware, rien n'y fait pas de nouvelle interface réseau !), et je n'ai pas d'écran facilement accessible pour vérifier (d'où l'installation par une console série).

AltStyle によって変換されたページ (->オリジナル) /