
                           Benchmarking HOWTO Linux

par Andr D. Balsa, andrewbalsa@usa.net
traduit par Franois Laagel, f.laagel@ieee.org

   v0.12, 15 Aot 1997 (v.f. : 2 du 28 Novembre 1997)
     _________________________________________________________________

   _Le benchmarking HOWTO Linux traite de certains problmes relatifs 
   l'valuation de performances de systmes Linux et prsente un ensemble
   d'outils ainsi qu'un formulaire associ qui permettent de produire des
   mesures de performances significatives en quelques heures. Peut-tre
   ce document contribuera-t-il  une diminution du nombre d'articles
   inutiles dans comp.os.linux.hardware..._
     _________________________________________________________________

1. Introduction

   _"Ce dont on ne peut parler doit tre pass sous silence."_

     _Ludwig Wittgenstein (1889-1951), philosophe Autrichien_

   L'valuation de performances (benchmarking) consiste  _mesurer_ la
   vitesse  laquelle un ordinateur excute une tche calculatoire, et ce
   de faon  pouvoir comparer diffrentes configurations
   logicielles/matrielles. Ceci n'a _aucun_ rapport avec la facilit
   d'utilisation, l'esthtique, les considrations d'ergonomie ou toute
   autre apprciation subjective.

   L'valuation de performances est une tche fastidieuse et rptitive.
   Elle ncssite que l'on prte une grande attention aux dtails. Trs
   souvent les rsultats obtenus ne sont pas ceux auxquels on s'attendait
   et sont sujet  interprtation (ce qui peut trs bien tre le but
   d'une procdure d'valuation de performances).

   Enfin, l'valuation de performances trate de faits et de chiffres et
   non pas d'opinion ou d'approximation.

1.1 Pourquoi l'valuation de performances est-elle si importante ?

   Hormis les raisons mentionnes dans le BogoMips Mini-HOWTO (section 7,
   paragraphe 2), il arrive, lorsque l'on se constitue une machine Linux,
   que l'on soit confront  un budget limit et/ou  des besoins en
   performances minimales garanties.

   En d'autres termes, lorsque l'on se pose les questions suivantes :

     * Comment maximiser la performance avec un budget donn ?
     * Comment minimiser le cot ncssaire pour obtenir un niveau de
       performance donn ?
     * Comment obtenir le meilleur rapport performance/cot (tant donn
       un budget ou des besoins en performances minimales garanties) ?

   il faudra examiner, comparer et/ou produire des benchmarks (ndt : un
   benchmark est un programme ou un ensemble de programmes - on parle
   alors de suite - servant  valuer les performances d'un systme
   informatique).

   Minimiser les cots sans contraintes de performance implique
   d'ordinaire la constitution d'une machine  partir de composants de
   rcupration (ce vieux 386SX-16 qui trane dans le garage sera
   parfait), et ne ncssite pas de benchmarks. Maximiser la performance
   sans cot plafond n'est pas une situation raliste ( moins que l'on
   souhaite mettre un Cray dans son salon - la banquette recouverte de
   cuir qui se trouve au dessus des alimentations lectriques est du
   meilleur got, n'est-t-il pas ?).

   L'valuation de performances sans contrainte de cot ni de performance
   minimale garantie n'a pas de sens: c'est une perte de temps et
   d'argent. L'valuation de performances n'a de sens que dans le cadre
   d'une prise de dcision, c'est  dire si l'on a le choix entre deux
   alternatives ou plus.

   D'ordinaire des critres autres que le _cot_ interviennent dans le
   processus dcisionnel. Il peut s'agir de la disponibilit, du service,
   de la fiabilit, de considrations stratgiques ou de toute autre
   caractristique rationnelle et mesurable d'un systme informatique.
   Par exemple, lorsque l'on compare la performance de diffrentes
   versions du noyau Linux, la _stabilit_ est toujours plus importante
   que la vitesse d'excution.

1.2 Non-critres en matire d'valuation de performances

   Malheureusement et trs souvent dans les newsgroups (forums) et les
   mailing lists (listes de diffusion par courrier lectronique), sont
   cits :

    1. La rputation du fabriquant (non-mesurable et sans signification).
    2. Les parts de march du fabriquant (sans signification et
       non-pertinent).
    3. Des paramtres irrationnels (superstition ou a-priori par exemple
       acheteriez-vous un processeur tiquet 131313ZAP et peint en rose
       ?).
    4. La valeur perue (non-significative, non-mesurable et
       irrationnelle).
    5. L'ampleur du tapage marketing (ndt : mercatique pour les
       intgristes :) est ce qu'il y a de pire, je crois.
       Personnellement, j'en ai marre des logos "XXX inside" ou "kkkkkws
       compatible" (maintenant "aaaaaPowered" est de la partie, et puis
       quoi encore ?). AMHA, les milliards de dollards dpenss durant de
       telles campagnes seraient bien mieux utiliss par de quipes de
       recherche pour la conception de nouveaux processeurs, plus rapides
       (moins chers :-) et moins buggs. Aucune campagne publicitaire, si
       ambitieuse soit-elle, n'est en mesure de supprimer une bug de la
       FPU en calcul flottant sur le tout nouveau processeur que vous
       venez tout juste d'enficher sur votre carte-mre, alors qu'un
       change au profit d'un processeur re-conu le fera.
    6. Les opinions du type "Vous avez ce pour quoi vous avez pay" ne
       sont prcisment que a : des opinions. Donnez-moi des faits, s'il
       vous plait.

2. Procdures d'valuation de performances et interprtation des rsultats

   Quelques recommendations semi-videntes :

    1. Premirement et avant tout, _identifiez vos objectifs d'valuation
       de performances_. Qu'essayez vous exactement d'valuer ? En quoi
       un processus d'valuation de performances va-t-il vous aider 
       prendre une dcision ultrieure ? Combien de temps et quelles
       ressources voulez-vous consacrer  cet effort ?
    2. _Utilisez des outils standard_. Utilisez une version  jour et
       stable du noyau, des versions standard et  jour de gcc et de la
       libc, et un benchmark standard. En bref, utilisez le LBT (voir
       plus loin).
    3. Donnez une _description complte_ de votre configuration
       matrielle (voir le formulaire de compte-rendu plus loin).
    4. Essayez d'_isoler une variable unique_. L'valuation de
       performances comparative est plus informative que l'valuation de
       performances "absolue". _Je n'insisterai jamais assez l-dessus_.
    5. _Vrifiez vos rsultats_. Faites tourner vos benchmarks plusieurs
       fois et vrifiez les variations des rsultats obtenus, si
       variation il y a. Des variations inexpliques invalideront vos
       rsultats.
    6. Si vous pensez que votre effort d'valuation de performances a
       produit de l'information significative, _partagez-la_ avec la
       communaut Linux de faon _prcise_ et _concise_.
    7. _Oubliez les BogoMips_ s'il vous plait. Je me promets
       d'implmenter un jour un ASIC (ndt : un acronyme pour Application
       Specific Integrated Circuit, c'est un circuit intgr ddi  une
       application donne) dans lequel les BogoMips seront cabls. Et
       alors on verra ce qu'on verra !

2.1 Comprendre les choix en matire de benchmarks

  Benchmarks synthtiques vs. benchmarks applicatifs

   Avant de consacrer le moindre temps aux travaux d'valuation de
   performances, il importe de faire un choix de base entre benchmarks
   synthtiques et benchmarks applicatifs.

   Les benchmarks synthtiques sont spcifiquement conus pour mesurer la
   performance des composants individuels d'un ordinateur, d'habitude en
   poussant l'un desdits composants jusqu' sa limite. Un exemple de
   benchmark synthtique clebre est la suite _Whetstone_, initialement
   programme en 1972 par Harold Curnow en FORTRAN (ou tait-ce en ALGOL
   ?), et dont l'usage est toujours trs rpandu de nos jours. La suite
   Whetstone produira une mesure de la performance d'une CPU en matire
   de calcul flottant.

   La principale critique que l'on puisse faire aux benchmarks
   synthtiques est qu'ils ne reprsentent pas la performance d'un
   ordinateur, en tant que systme complexe, dans des conditions
   d'utilisation relles. Prenons par exemple la suite Whetstone, dont la
   boucle principale est trs courte, et qui donc peut aisment tenir
   dans le cache primaire d'une CPU, cette suite maintient le pipeline de
   la FPU aliment en permanence de faon  pousser celle-ci  sa vitesse
   maximale. On ne peut pas vraiment critiquer la suite Whetstone si l'on
   se souvient qu'elle a t programme il y a 25 ans (sa conception est
   mme plus ancienne que a !), mais il nous faut nous assurer que nous
   interprtons ses rsultats avec prudence quand nous nous proccupons
   d'valuer les performances de micro-processeurs modernes.

   Un autre aspect trs important qu'il nous faut avoir en tte  propos
   des benchmarks synthtiques est qu'idalement, ils devraient pouvoir
   nous dire quelque chose en ce qui concerne un aspect _spcifique_ du
   systme que l'on est en train de tester, et ce indpendamment des
   autres aspects dudit sysme : un benchmark synthtique d'une carte
   D'E/S Ethernet devrait produire les mmes rsultats (ou des rsultats
   comparables) que ce soit sur un 386SX-16 avec 4 MB de RAM ou sur un
   Pentium 200 MMX avec 64 MB de RAM. Si tel n'tait pas le cas, le test
   mesurerait la performance globale de l'association
   CPU/carte-mre/bus/carte Ethernet/sous-systme mmoire/DMA, ce qui
   n'est pas trs utile puisque la diffrence au niveau des CPUs aura un
   impact plus important que la diffrence au niveau des cartes Ethernet
   (ceci suppose bien sr que nous utilisions la mme combinaison
   noyau/driver (pilote de priphrique)). Dans le cas contraire la
   diffrence de performances pourrait tre encore plus grande) !

   Enfin, une erreur frquemment commise est de calculer la moyenne de
   divers benchmarks synthtiques et de prtendre qu'une telle moyenne
   est une bonne reprsentation de la performance globale d'un systme
   donn pour une utilisation dans la vie relle.

   Voici un commentaire sur les benchmarks FPU (cit avec la permission
   du site Web de Cyrix Corp.) :

     _"Une unit de calcul flottant acclre le logiciel conu pour
     l'utilisation de l'arithmtique flottante : typiquement il s'agit
     de programmes de CAO, de tableurs, de jeux en 3D et d'applications
     de conception. Cependant, la plupart des applications PC populaires
     d'aujourd'hui utilisent  la fois des instructions flottantes et
     l'arithmtique entire. C'est pourquoi Cyrix a choisi de mettre
     l'accent sur le paralllisme lors de la conception du processeur
     6x86 et ce dans le but d'acclrer les programmes qui entremlent
     ces 2 types d'instructions. _

     _Le modle de traitement des exceptions flottantes de
     l'architecture x86 permet aux instructions entires d'tre mises
     et de se terminer pendant qu'une instruction flottante est en cours
     d'excution. A l'oppos, une seconde opration flottante ne pourra
     pas tre excute alors qu'une prcedente instruction flottante est
     en cours d'excution. Pour supprimer cette limitation de
     performance cree par le modle de traitement des exceptions
     flottantes, le 6x86, peut mettre spculativement jusqu' 4
     instructions flottantes vers la FPU intgre sur le circuit. Par
     exemple, dans une squence de code constitue de 2 instructions
     flottantes (FLTs) suivies de 6 instructions entires (INTs),
     elles-mmes suivies de 2 FLTs, le 6x86 peut mettre toutes ces 10
     instructions vers les units d'excution appropries avant que
     l'excution de la premire FLT ne se soit termine. Si aucune de
     ces instructions ne provoque d'exception (ce qui est typique),
     l'excution continue, les units flottantes et entires terminant
     l'excution de ces instructions en parallle. Si l'une des FLTs
     gnre une exception (le cas atypique), les possibilits
     d'excution spculatives du 6x86 permettent que l'tat du
     processeur soit restitu de faon  ce que celui-ci soit compatible
     avec le modle de traitement des exceptions flottantes. _

     _L'examen de code de benchmarks synthtiques flottants rvle que
     ceux-ci utilisent des squences d'instructions purement flottantes
     que l'on ne trouve pas dans les applications du monde rel. Ce type
     de benchmarks ne tire pas profit des possibilits d'excution
     spculative du processeur 6x86. Cyrix pense que les benchmarks
     non-synthtiques bass sur des applications du monde rel refltent
     mieux la performance que les utilisateurs vont effectivement
     obtenir. Les applications du monde rel contiennent des
     instructions entires et flottantes entremles et pour cette
     raison tireront un meilleur parti des possibilits d'excution
     spculative du 6x86." _

   La tendance rcente en matire d'valuation de performances consiste
   donc  choisir des applications usuelles et  les utiliser pour
   mesurer la performance d'ordinateurs en tant que systmes complexes.
   Par exemple _SPEC_, l'entreprise  but non-lucratif qui a conu les
   clbres suites de benchmarks synthtiques SPECINT et SPECFP, a lanc
   un projet pour dvelopper une nouvelle suite de benchmarks
   applicatifs. Mais, l encore, il est trs improbable qu'une telle
   suite de benchmarks commerciale comporte du code Linux un jour.

   En rsum, les benchmarks synthtiques sont valables  condition
   d'avoir compris leurs objectifs et leurs limites. Les benchmarks
   applicatifs reflteront mieux la performance d'un systme
   informatique, mais aucun d'entre eux n'est disponible pour Linux.

  Benchmarks de haut-niveau vs. de bas-niveau

   Les benchmarks de bas-niveau ont pour ambition la mesure de la
   performance du matriel : la frquence de l'horloge du processeur, les
   temps de cycle de la DRAM (ndt : acronyme pour Dynamic Random Access
   Memory) et de la SRAM (ndt : acronyme pour Static Random Access
   Memory) cache, temps d'accs moyen d'un disque dur, temps d'accs
   piste  piste, etc...

   Cette approche peut tre utile si vous avez achet un systme et que
   vous vous demandez  partir de quels composants il a t construit,
   bien qu'une meilleure faon de rpondre  cette question soit d'ouvrir
   le botier, de dresser l'inventaire des composants que vous trouverez
    l'intrieur, et d'obtenir les spcifications techniques pour chacun
   d'entre eux (elles sont la plupart du temps disponibles sur le Web).

   Une autre utilisation possible des benchmarks de bas-niveau consiste 
   s'en servir pour vrifier qu'un driver du noyau a t correctement
   configur pour un composant matriel donn : si vous disposez des
   spcifications techniques de ce composant vous pourrez comparer les
   rsultats d'un benchmark de bas-niveau aux valeurs thoriques figurant
   dans les specs.

   Les benchmarks de haut-niveau ont plutt pour objectif la mesure de la
   performance de l'association matriel/driver/systme d'exploitation en
   ce qui concerne un aspect spcifique d'un systme informatique (par
   exemple la performance des entres-sorties), ou mme une association
   spcifique matriel/driver/systme d'exploitation/application (par
   exemple un benchmark Apache sur diffrents ordinateurs).

   Bien sr, tous les benchmarks de bas-niveau sont synthtiques. Les
   benchmarks de haut-niveau peuvent tre synthtiques ou applicatifs.

2.2 Benchmarks standard disponibles pour Linux

   AMHA, un test simple que tout le monde peut effectuer  l'occasion
   d'une mise  jour de la configuration de sa machine Linux est de
   lancer une compilation du noyau avant et aprs cette mise  jour
   matrielle/logicielle, et de comparer les dures de compilation. Si
   tous les autres paramtres sont les mmes, alors ce test est valable
   en tant que mesure de la performance en matire de compilation, et
   l'on peut affirmer en toute confiance que :

     "Le remplacement de A par B a conduit  une amlioration de x % de
     la dure de compilation du noyau Linux dans telles et telles
     conditions".

   Ni plus, ni moins !

   Parce que la compilation du noyau est une tche trs courante sous
   Linux, et parce qu'elle met en oeuvre la plupart des fonctionnalits
   impliques dans les benchmarks usuels (sauf le calcul flottant), elle
   constitue un test _isol_ plutt bon. Cependant, dans la majeure
   partie des cas, les rsultats de ce test ne peuvent pas tre
   reproduits par d'autres utilisateurs de Linux  cause des diffrences
   de configurations matrielles/logicielles. Ce test ne constitue donc
   en aucun cas une mtrique permettant de comparer des systmes
   dissemblables ( moins que nous ne nous mettions tous d'accord sur la
   compilation d'un noyau standard - voir plus loin).

   Malheureusement, il n'y a pas d'outils d'valuation de performances
   ciblant spcifiquement Linux, sauf peut-tre les Byte Linux
   Benchmarks. Ceux-ci sont une version lgerement modifie des Byte Unix
   Benchmarks qui datent de 1991 (modifications Linux par Jon Tombs,
   auteurs originels : Ben Smith, Rick Grehan et Tom Yager).

   Il existe un site Web central pour les Byte Linux Benchmarks.

   Une version amliore et mise  jour des Byte Unix Benchmarks a t
   synthtise par David C. Niemi. Elle s'appelle UnixBench 4.01 pour
   viter une confusion possible avec des versions antrieures. Voici ce
   que David a crit au sujet de ses modifications :

     "Les BYTE Unix benchmarks originels et lgerement modifis sont
     nases  bien des gards ce qui fait d'eux un indicateur
     inhabituellement non-fiable de la performance d'un systme. J'ai
     dlibrment fait en sorte que mes indices de performance soient
     trs diffrents pour viter la confusion avec les vieux
     benchmarks."

   David a mis en place une liste majordomo de diffusion par courrier
   lectronique pour les discussions relatives  l'valuation de
   performances sous Linux et sous les systmes d'exploitation
   concurrents. Vous pouvez vous joindre  ces discussions en envoyant un
   e-mail dont le corps contiendra "subscribe bench"  l'adresse
   majordomo@wauug.erols.com. Les groupe des utilisateurs de la rgion de
   Washington est aussi en train de mettre en place un site Web
   concernant les benchmarks sous Linux.

   Rcemment, Uwe F. Mayer, mayer@math.vanderbilt.edu a galement port
   la suite Bytemark de BYTE sous Linux. Il s'agit d'une suite moderne et
   compile trs habilement par Rick Grehan du magazine BYTE. Bytemark
   teste les performances de la CPU, de la FPU et du sous-systme mmoire
   des micro-ordinateurs modernes (ces benchmarks sont strictement
   orients vers la performance du processeur, les E/S ou la performance
   globale du systme ne sont pas pris en compte).

   Uwe a aussi mis en place un site Web, site o l'on peut accder  une
   base de donnes contenant les rsultats de sa version des benchmarks
   BYTEmark pour Linux.

   Si vous tes  la recherche de benchmarks synthtiques pour Linux,
   vous remarquerez assez vite que sunsite.unc.edu ne propose que peu
   d'outils d'valuation de performances. Pour mesurer les performances
   relatives de serveurs X, la suite xbench-0.2 de Claus Gittinger est
   disponible sur sunsite.unc.edu, ftp.x.org et d'autres sites (ndt :
   notamment ftp.lip6.fr qui est l'un des mirroirs de sunsite). Dans son
   immense sagesse, Xfree86.org refuse de promouvoir ou de recommender le
   moindre benchmark.

   XFree86-benchmarks Survey est un site Web comprenant une base de
   donnes de rsultats relatifs  x-bench.

   En ce qui concerne les E/S purement disque, l'utilitaire hdparm (qui
   fait partie de la plupart des distributions, mais est aussi disponible
   sur sunsite.unc.edu) permet de mesurer les taux de transfert grce aux
   options -t et -T.

   Il existe plein d'autres outils disponibles librement (sous license
   GPL) sur Internet pour tester divers aspects de la performance de
   votre machine Linux.

2.3 Liens et rfrences

   La FAQ du newsgroup comp.benchmarks par Dave Sill est la rfrence
   standard en matire d'valuation de performances. Elle n'est pas
   particulirement oriente Linux, mais elle n'en reste pas moins une
   lecture recommende pour tous ceux qui font preuve d'un minimum de
   srieux envers le sujet. Elle est disponible sur nombre de sites FTP
   et de sites Web et recense _56 benchmarks diffrents_ avec des liens
   vers des sites FTP permettant de les tlcharger. Cependant, certains
   des benchmarks recenss sont des produits commerciaux.

   Je n'entrerai pas dans la description dtaille des benchmarks
   mentionns dans la FAQ de comp.benchmarks, mais il y a au moins une
   suite de bas-niveau au sujet de laquelle j'aimerai faire quelques
   commentaires : la suite lmbench de Larry McVoy. Je cite David C. Niemi
   :

     _"Linus et David Miller s'en servent beaucoup parce qu'elle permet
     des mesures de bas-niveau utiles et peut aussi quantifier la bande
     passante et la latence d'un rseau si vous avez deux machines 
     votre disposition pour le faire tourner. Mais lmbench n'essaie pas
     de produire un indice de performance global..."_

   Un site FTP assez complet en matire de benchmarks disponibles
   _librement_ a t mis en place par Alfred Aburto. La suite Whetstone
   utilise dans le LBT est disponible sur ce site.

   Une _FAQ multi-fichier par Eugene Miya_ est galement poste sur
   comp.benchmarks; c'est une excellente rfrence.

3. Le Linux Benchmarking Toolkit (LBT)

   Je propose ici un ensemble d'outils pour l'valuation de performances
   sous Linux. C'est la version prliminaire d'un vaste environnement
   d'valuation de performances pour Linux, il est destin  tre
   amlior et  voir ses fonctionnalits tendues. Prenez le pour ce
   qu'il vaut, c'est--dire une proposition. Si vous pensez que cette
   suite de test n'est pas valable, prenez la libert de m'envoyer (ndt :
    l'auteur et non au traducteur, merci :-) vos critiques par e-mail et
   soyez srs que je serai heureux d'intgrer les changements que vous
   aurez suggr dans la mesure du possible. Avant d'entamer une
   polmique, lisez ce HOWTO et les documents cits en rfrence : les
   critiques informs sont les bienvenus, les critiques striles ne le
   sont pas.

3.1 Motivations

   Elles sont dictes par le bon sens, tout simplement :

    1. Cette suite ne doit pas ncessiter plus d'une journe de dure
       d'excution. En matire de benchmarks comparatifs (diverses
       excutions), personne ne veut passer des jours  essayer de
       trouver la configuration matrielle le plus rapide pour un systme
       donn. Idalement, l'ensemble de la suite devrait pouvoir tourner
       en 15 minutes sur une machine moyenne.
    2. Tout le code source doit tre disponible librement sur le Net,
       pour des raisons videntes.
    3. Les benchmarks devraient fournir des chiffres simples et refltant
       la performance mesure.
    4. Il devait y avoir un mlange de benchmarks synthtiques et de
       benchmarks applicatifs.
    5. Chacun des benchmarks _synthtiques_ devrait pousser un
       sous-systme particulier  ses limites.
    6. Les rsultats des benchmarks _synthtiques_ ne devraient _pas_
       tre combins par le biais d'une moyenne afin d'en extraire un
       facteur de mrite global (cela va  l'encontre du principe
       fondateur des benchmarks synthtiques et conduit  une perte
       d'information considrable).
    7. Les benchmarks applicatifs devraient tre reprsentatifs de tches
       couramment excutes sur des systmes Linux.

3.2 Slection des benchmarks

   J'ai slectionn 5 suites des benchmarks diffrentes en vitant autant
   que possible les recouvrements dans les tests :

    1. Compilation du noyau 2.0.0 (configuration par dfaut) avec gcc.
    2. Whetstone version 10/03/97 (la version la plus rcente de Roy
       Longbottom).
    3. xbench-0.2 (avec les paramtres d'excution rapide).
    4. Les benchmarks UnixBench version 4.01 (rsultats partiels).
    5. Les benchmarks de la suite BYTEmark du magazine BYTE beta release
       2 (rsultats partiels).

   Pour les tests 4 et 5, "(rsultats partiels)" signifie qu'une partie
   seulement des rsultats produits est prise en compte.

3.3 Dure des tests

    1. Compilation du noyau 2.0.0 : 5 - 30 minutes, selon la performance
       _relle_ de votre machine.
    2. Whetstone : 100 secondes.
    3. Xbench-0.2 : < 1 heure.
    4. Les benchmarks d'UnixBench version 4.01 : environs 15 minutes.
    5. Les benchmarks de la suite BYTEmark du magazine BYTE : environs 10
       minutes.

3.4 Commentaires

  Compilation du noyau 2.0.0

     * _Quoi :_ c'est le seul benchmark applicatif de la LBT.
     * Le code est largement disponible (cd que j'ai finalement trouv
       une utilisation pour mes vieux CD-ROMs Linux).
     * La plupart des linuxiens recompilent leur noyau assez souvent,
       c'est donc une mesure significative de la performance globale.
     * Le noyau est gros et gcc utilise une bonne partie de la mmoire
       (ndt : surtout  l'dition de liens) : ceci contribue  attnuer
       le biais induit par le cache L2 lorsque l'on se contente de passer
       de petits tests.
     * Les E/S vers le disque sont frquentes.
     * Procdure de test : trouvez une antique arborescence source de
       2.0.0, compilez la avec les options par dfaut (make config,
       appuyez sur Enter autant de fois que ncssaire). Le temps affich
       doit correspondre  la dure passe sur la compilation cd aprs
       que vous ayez tap make zImage (sans prendre en compte le make dep
       clean). Notez que l'architecture cible par dfaut est i386, donc
       si vous compilez sur une autre architecture, gcc devrait tre en
       mesure de cross-compiler en utilisant i386 en tant qu'architecture
       cible.
     * _Rsultats :_ la dure de compilation en minutes et secondes (s'il
       vous plait, ne rapportez pas les fractions de secondes).

  La suite Whetstone

     * _Quoi :_ mesure la performance en calcul flottant pur 
       l'intrieur d'une courte (et dense) boucle. Le code source (en C)
       est assez lisible et il est trs facile de voir quelles sont les
       oprations flottantes impliques.
     * C'est le plus court des tests de la LBT :-).
     * C'est un "Vieux Classique" : des chiffres sont disponibles pour
       comparaison, ses dfauts et ses faiblesses sont bien connues.
     * Procdure de test : le code source le plus rcent devrait tre
       tlcharg depuis le site d'Aburto. Compilez le et excutez le en
       mode double prcision. Spcifiez gcc et -O2 en tant que
       pr-processeur et option du compilateur respectivement. Dfinissez
       aussi la variable du pr-processur POSIX  1 pour prciser le type
       de machine.
     * _Rsultats :_ un indice de performance en calcul flottant exprim
       en MWIPS.

  Xbench-0.2

     * _Quoi :_ mesure la performance de serveurs X.
     * La mesure en xStones fournie par xbench est une moyenne pondre
       de quelques tests rapports aux performances obtenues sur une
       vieille station Sun ne disposant que d'un display d'un seul bit de
       profondeur (ndt : en clair, c'est du monochrome pur et dur).
       Mouais... on peut lgitimement se demander si xbench est
       vritablement adquat en tant que test pour des serveurs X
       modernes. Nanmoins, c'est le meilleur outil que j'ai trouv.
     * Procdure de test : compilez avec -O2. On spcifiera aussi
       quelques options pour une excution courte : ./xbench -timegoal 3
       > results/name_of_your_linux_box.out. Pour gnrer l'indice
       xStones, il nous faudra encore lancer un script awk; la faon la
       plus simple de le faire tant de taper make summary.ms. Jetez un
       coup d'oeuil au fichier summary.ms : l'indice xStone de votre
       systme est dans la dernire colonne de la ligne contenant le nom
       de votre machine -- nom que vous aurez spcifi pendant le test.
     * _Rsultats :_ un indice de performances exprim en xStones.
     * Note : ce test, en l'tat, est dpass. Il devrait tre r-crit.

  UnixBench version 4.01

     * _Quoi_ : mesure la performance globale d'un systme UNIX. Ce test
       met en oeuvre vidence la performance des E/S fichier et de la
       gestion du multi-tches par le noyau.
     * J'ai supprim tous les rsultats de tests arithmtiques et je n'ai
       conserv que les tests orients systme.
     * Procdure de test : make avec -O2. Excution avec ./Run -1
       (tournez chacun des tests une fois). Vous trouverez les rsultats
       dans le fichier ./results/report. Calculez la moyenne gomtrique
       des indices de EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE
       THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL
       SCRIPTS et SYSTEM CALL OVERHEAD.
     * _Rsultats :_ un indice de performance du systme.

   (ndt : la moyenne gomtrique se dfinit comme la racine n-ime du
   produit des n termes considrs)

  Les benchmarks Bytemark du magazine BYTE

     * Quoi : fournit une bonne mesure de la performance CPU. Voici un
       extrait de la documentation : _"Ces benchmarks ont ts conu de
       faon  mettre en vidence la limite suprieure de la CPU, de la
       FPU et de l'architecture mmoire d'un systme. Ils ne peuvent
       mesurer la performance du sous-systme graphique, des accs disque
       ou du dbit rseau (ce sont l le domaine d'un ensemble diffrent
       de benchmarks). C'est pourquoi, il est souhaitable que vous
       n'utilisiez les rsultats de ces tests qu'en tant qu'lment
       d'apprciation partielle, et non pas totale, lors de l'valuation
       de la performance d'un systme."_
     * J'ai supprim tous les rsultats de test FPU puisque la suite
       Whetstone est tout aussi reprsentative des performances  cet
       gard.
     * J'ai dcompos les tests entiers en deux groupes : ceux qui sont
       plus reprsentatifs de la performance cache mmoire/CPU, et ceux
       qui utilisent l'arithmtique entire de la CPU.
     * Procdure de test : make avec -O2. Excutez le test avec ./nbench
       >myresults.dat ou quelque chose d'approchant. Puis,  partir de
       myresults.dat, calculez la moyenne gomtrique des indices des
       tests STRING SORT, ASSIGNMENT et BITFIELD. Ceci vous donnera
       l'_indice mmoire_. Calculez la moyenne gomtrique des indices des
       tests NUMERIC SORT, IDEA, HUFFMAN et FP EMULATION: c'est l'_indice
       entier_.
     * _Rsultats :_ un indice mmoire et un indice entier calculs comme
       expliqu ci-dessus.

3.5 Amliorations possibles

   La suite de benchmarks idale tournerait en quelques minutes,
   comprendrait des benchmarks synthtiques testant chaque sous-systme
   sparment et des benchmarks applicatifs fournissant des rsultats
   pour diffrentes applications. Elle produirait aussi automatiquement
   un rapport complet et ventuellement l'enverrait par e-mail  une base
   de donnes centrale sur le Web.

   La portabilit n'est pas vraiment notre souci premier dans cette
   affaire. Pourtant, une telle suite devrait tourner au moins sur toutes
   les versions (> 2.0.0) du noyau Linux, et ce dans toutes leurs
   dclinaisons possibles (i386, Alpha, Sparc...).

   Si quelqu'un a la moindre ide concernant l'valuation de performances
   rseau au moyen d'un test  la fois simple, facile d'emploi, fiable,
   et dont la mise en oeuvre prendrait moins de 30 minutes (configuration
   et excution), s'il vous plait contactez-moi.

3.6 Formulaire de rapport LBT

   Au-del des tests, la procdure d'valuation de performances n'aurait
   pas t complte sans un formulaire dcrivant la configuration
   matrielle utilise lors de leur excution. Le voici donc : (il se
   conforme aux directives prescrites dans la FAQ de comp.benchmarks) :

   (ndt : le formulaire en question n'a dlibrment pas t traduit, de
   faon  ce que l'auteur de ce HOWTO puisse automatiser leur traitement
   en vue de maintenir une base de donnes de rsultats. Voir la section
   4 pour un exemple de formulaire correctement rempli).

______________________________________________________________________
LINUX BENCHMARKING TOOLKIT REPORT FORM
______________________________________________________________________

______________________________________________________________________
CPU
==
Vendor:
Model:
Core clock:
Motherboard vendor:
Mbd. model:
Mbd. chipset:
Bus type:
Bus clock:
Cache total:
Cache type/speed:
SMP (number of processors):
______________________________________________________________________

______________________________________________________________________
RAM
====
Total:
Type:
Speed:
______________________________________________________________________

______________________________________________________________________
Disk
====
Vendor:
Model:
Size:
Interface:
Driver/Settings:
______________________________________________________________________

______________________________________________________________________
Video board
===========
Vendor:
Model:
Bus:
Video RAM type:
Video RAM total:
X server vendor:
X server version:
X server chipset choice:
Resolution/vert. refresh rate:
Color depth:
______________________________________________________________________

______________________________________________________________________
Kernel
=====
Version:
Swap size:
______________________________________________________________________

______________________________________________________________________
gcc
===
Version:
Options:
libc version:
______________________________________________________________________

______________________________________________________________________
Test notes
==========
______________________________________________________________________

______________________________________________________________________
RESULTS
========
Linux kernel 2.0.0 Compilation Time: (minutes and seconds)
Whetstones: results are in MWIPS.
Xbench: results are in xstones.
Unixbench Benchmarks 4.01 system INDEX:
BYTEmark integer INDEX:
BYTEmark memory INDEX:
______________________________________________________________________

______________________________________________________________________
Comments*
=========
* Ce champ n'est prsent dans ce formulaire que pour de possibles
interprtations des rsultats, et tant que tel, il est optionnel.
Il pourrait cependant constituer la partie la plus importante de votre
compte-rendu, tout particulirement si vous faites de l'valuation
de performances comparative.
______________________________________________________________________

3.7 Test de performances rseau

   Le test des performances rseau est un vritable dfi en soi puisqu'il
   implique au moins deux machines: un serveur et une machine cliente.
   Pour cette raison ce genre de test ncessite deux fois plus de temps
   pour tre mis en place, il y a plus de variables  contrler, etc...
   Sur un rseau Ethernet, il me semble votre meilleure option est le
   paquetage ttcp. ( developper)

3.8 Les tests SMP

   Les tests SMP sont un autre dfi, et tout test conu spcifiquement
   pour un environnement SMP aura des difficults  s'avrer valide dans
   des conditions d'utilisation relles parce que les algorithmes qui
   tirent parti du SMP sont difficiles  dvelopper. Il semble que les
   versions du noyau Linux les plus rcentes (> 2.1.30 ou pas loin)
   feront du scheduling (ndt : ordonnancement de thread ou de processus)
    grain fin ; je n'ai pas plus d'information que a pour le moment.

   Selon David Niemi, _"... shell8_ de la suite Unixbench 4.01 _fait du
   bon travail en matire de comparaison de matriel/SE similaires en
   mode SMP et en mode UP."_

   (ndt : SMP = Symetric Multi-Processing, UP = Uni-Processor)

4. Une excution type et les rsultats

   Le LBT a t lanc sur ma machine perso., une machine de classe
   Pentium tournant Linux que j'ai assemble moi-mme et que j'utilise
   pour crire ce HOWTO. Voici le compte-rendu LBT pour ce systme :

LINUX BENCHMARKING TOOLKIT REPORT FORM

CPU
==

Vendor: Cyrix/IBM

Model: 6x86L P166+

Core clock: 133 MHz

Motherboard vendor: Elite Computer Systems (ECS)

Mbd. model: P5VX-Be

Mbd. chipset: Intel VX

Bus type: PCI

Bus clock: 33 MHz

Cache total: 256 KB

Cache type/speed: Pipeline burst 6 ns

SMP (number of processors): 1

RAM
====

Total: 32 MB

Type: EDO SIMMs

Speed: 60 ns

Disk
====

Vendor: IBM

Model: IBM-DAQA-33240

Size: 3.2 GB

Interface: EIDE

Driver/Settings: Bus Master DMA mode 2

Video board
===========

Vendor: Generic S3

Model: Trio64-V2

Bus: PCI

Video RAM type: EDO DRAM

Video RAM total: 2 MB

X server vendor: XFree86

X server version: 3.3

X server chipset choice: S3 accelerated

Resolution/vert. refresh rate: 1152x864 @ 70 Hz

Color depth: 16 bits

Kernel
=====

Version: 2.0.29

Swap size: 64 MB

gcc
===

Version: 2.7.2.1

Options: -O2

libc version: 5.4.23

Test notes
==========

Une charge trs faible. Les tests ci-dessus ont t excuts
avec quelques unes des options spcifiques du Cyrix/IBM 6x86 actives
grce au programme setx86. Il s'agit de : fast ADS, fast IORT, Enable DTE,
fast LOOP, fast Lin. VidMem.

RESULTS
========

Linux kernel 2.0.0 Compilation Time: 7m12s

Whetstones: 38.169 MWIPS.

Xbench: 97243 xStones.

BYTE Unix Benchmarks 4.01 system INDEX: 58.43

BYTEmark integer INDEX: 1.50

BYTEmark memory INDEX: 2.50

Comments
=========

Il s'agit l d'une configuration trs stable et dote de performances
homognes, idale pour une utilisation individuelle et/ou dvelopper
sous Linux. Je rendrai compte des rsultats obtenus avec un 6x86MX ds
que j'aurai russi  mettre la main sur l'un d'entre eux !

5. Piges et mises en garde en matire d'valuation de performances

   Aprs avoir compil ce HOWTO, j'ai commenc  comprendre pourquoi les
   mots de "pige" et de "mise en garde" sont si souvent associs 
   l'valuation de performances.

5.1 Comparer des pommes et des oranges

   Ou devrais-je dire des Apples et des PCs ? (ndt : pour goter
   pleinement toute la finesse de ce jeu de mots, il faut quand mme
   savoir que pomme se dit apple en anglais :-) C'est tellement vident
   et c'est une controverse tellement cule que je ne rentrerai pas dans
   les dtails. Je doute que le temps ncessaire pour booter un Mac
   compar  celui d'un Pentium moyen soit une vritable mesure de quoi
   que ce soit. De faon similaire on pourrait parler du boot de Linux
   vs. Windows NT, etc... Essayez autant que possible de comparer des
   machines identiques  une seule diffrence prs.

5.2 Information incomplte

   Un seul exemple suffira  l'illustration de cette erreur trs
   courante. On lit souvent dans comp.os.linux.hardware l'affirmation
   suivante : "Je viens tout juste d'enficher le processeur XYZ qui
   tourne  nnn MHz et la compilation du noyau prend maintenant i minutes
   (ajustez XYZ, nnn et i selon vos besoins). C'est nervant parce
   qu'aucune autre information n'est fournie: on ne connait mme pas la
   quantit de RAM, la taille du swap, les autres tches qui tournaient 
   ce moment l, la version du noyau, les modules slectionns, le type
   de disque dur, la version de gcc, etc...

   Je vous recommende d'utiliser le formulaire de compte-rendu LBT,
   lequel fournit au moins un cadre informationnel standard.

5.3 Matriel/logiciel propritaire

   Un fabriquant de micro-processeurs bien connu a publi nagure des
   rsultats de benchmarks produits avec une version spciale et
   personnalise de gcc. Considrations thiques mises  part, ces
   rsultats sont dnus de toute signification, en effet, la totalit de
   la communaut Linux aurait utilis la version standard de gcc. Le mme
   genre de considration vaut aussi pour le matriel propritaire.
   L'valuation de performances est beaucoup plus utile quand elle va de
   pair avec du matriel sur tagre et du logiciel gratuit (au sens
   GNU/GPL).

5.4 Pertinence

   On parle de Linux, non ? On devrait donc faire abstraction des
   benchmarks produits sous d'autres systmes d'exploitation (ceci est
   une instance particulire de la comparaison des pommes et des oranges
   mentionne plus haut). Si l'on se propose d'valuer la performance
   d'un serveur Web, on pourra aussi se dispenser de citer la performance
   FPU et toute autre information non-pertinente. Dans de tels cas, moins
   c'est plus. Enfin, vous n'avez pas non plus besoin de parler de l'age
   de votre chat, de votre humeur pendant que vous procdez  une
   valuation de performances, etc...

6. FAQ

   _Q1._
          Existe-t-il un indice de performances spcifique aux machines
          Linux ?

   _A._
          Non, Dieu merci personne n'a encore invent de mesure du type
          Lhinuxstone (tm). Mme si c'tait le cas, a n'aurait pas
          beaucoup de sens : les machines Linux sont utilises pour des
          tches tellement diffrentes allant des serveurs Web lourdement
          chargs aux stations graphiques pour utilisation individelle.
          Aucun facteur de mrite ne peut dcrire les performances d'une
          machine Linux dans des situations si diffrentes.

   _Q2._
          Alors, pourquoi ne pas choisir une douzaine de mtriques pour
          rsumer la performance de diverses machines Linux ?

   _A._
          a serait une situation idale. J'aimerai voir a devenir une
          ralit. Y-a-t-il des volontaires pour un _projet d'valuation
          de performances sous Linux_ ? Avec un site Web et une base de
          donnes de rapports bien conus, complte et en ligne ?

   _Q3._
          ... BogoMips ...

   _A._
          Les BogoMips n'ont strictement rien  voir avec la performance
          de votre machine. Voir le BogoMips Mini-HOWTO.

   _Q4._
          Quel est le "meilleur" benchmark pour Linux ?

   _A._
          a dpend compltement de quel aspect des performances d'une
          machine Linux on souhaite mesurer. Il y a des benchmarks
          diffrents pour faire des mesures rseau (taux de transfert
          soutenu sous Ethernet), des mesures de serveur de fichiers
          (NFS), de bande passante, de performance CAO, de temps de
          transaction, de performance SQL, de performances de serveur
          Web, de performance temps-rel, de performance CD-ROM, de
          performance sous Quake (!), etc ... Pour autant que je sache,
          aucune suite de benchmarks supportant tous ces tests n'existe
          pour Linux.

   _Q5._
          Quel est le processeur le plus rapide pour Linux ?

   _A._
          Le plus rapide pourquoi faire ? Si on est plutt orient calcul
          intensif, alors un Alpha  frquence d'horloge leve (600 MHz
          et a continue  grimper) devrait tre plus rapide que
          n'importe quoi d'autre, du fait que les Alphas ont t conus
          dans cette optique. D'un autre ct, si vous voulez vous
          constituer un serveur de news trs rapide, il est probable que
          le choix d'un sous-systme disque rapide et de beaucoup de RAM
          vous menera  de meilleures amliorations de performances qu'un
          changement de processeur ( prix constant).

   _Q6._
          Laissez-moi reformuler la dernire question, alors : y-a-t-il
          un processeur qui soit le plus rapide dans les applications
          d'usage gnral ?

   _A._
          C'est une question dlicate mais la rponse est simple : NON.
          On peut toujours concevoir un systme plus rapide mme pour des
          applications d'usage gnral indpendamment du processeur.
          D'ordinaire, en conservant tous les autres paramtres  leur
          valeur nominale, des frquences d'horloge plus leves
          permettent d'obtenir de meilleures performances (ndt : surtout
          si on parle de systmes synchrones :-) et aussi plus de maux de
          tte. Si vous retirez un vieux Pentium  100 MHz d'une
          carte-mre (laquelle n'est pas souvent) upgradable, et que vous
          le remplaciez par un Pentium 200 MHz MMX vous devriez sentir
          une diffrence de performances notable. Bien sr, pourquoi se
          contenter de 16 MB de RAM ? Le mme investissement aurait t
          fait de faon encore plus avise au profit de quelques SIMMs
          supplmentaires...

   _Q7._
          Donc la frquence d'horloge du processeur a une influence sur
          la performance d'un systme ?

   _A._
          La plupart des tches sauf les boucles de NOP (qui sont
          d'ailleurs supprimes  la compilation par les compilateurs
          modernes) une augmentation de la frquence d'horloge permettra
          d'obtenir une augmentation linaire de la performance. Des
          applications gourmandes en ressources CPU et trs petites
          (pouvant donc tenir dans le cache L1 : 8 ou 16KB) verront leur
          performances augmenter dans la mme proportion que
          l'augmentation de la frquence d'horloge. Cependant les "vrais"
          programmes comportent des boucles qui ne tiennent pas dans le
          cache primaire, doivent partager le cache secondaire (externe)
          avec d'autres processus et dpendent de composants externes
          (ndt : pour les E/S) bnficieront d'un gain de performance
          beaucoup moins important. Tout ceci parce que le cache L1
          fonctionne  la mme frquence d'horloge que le processeur,
          alors que la plupart des caches L2 et des autres sous-systmes
          (DRAM par exemple) tournent en asynchrone  des frquences plus
          basses.

   _Q8._
          D'accord, dans ce cas, une dernire question sur le sujet :
          quel est le processeur prsentant le meilleur rapport
          prix/performance pour une utilisation d'usage gnral sous
          Linux ?

   _A._
          Dfinir une "utilisation d'usage gnral sous Linux" n'est pas
          chose facile ! Etant donne une application quelconque, il y a
          toujours moyen de dterminer quel processeur du moment dtient
          le meilleur rapport prix/performance pour ladite application.
          Mais les choses changent si rapidement  mesure que les
          fabriquants diffusent de nouveaux processeurs, que dire "le
          processeur XYZ  n MHz est le choix du moment" serait forcment
          rducteur. Cependant, le prix du processeur n'est pas
          significatif dans le cot d'un systme complet que l'on
          assemble soi-mme. Donc, la question devrait plutt tre
          "comment maximize-t-on le rapport performance/cot d'une
          machine donne ?" Et la rponse  cette question dpend en
          grande partie des besoins en performance minimale garantie
          et/ou du cot maximal de la configuration que l'on considre.
          Il arrive parfois que le matriel sur tagre ne permette pas
          d'atteindre les besoins en performance minimale garantie que
          l'on souhaite obtenir et que des systmes RISC coteux soient
          la seule alternative viable. Pour une utilisation personnelle,
          je recommende une configuration quilibre et homogne du point
          de vue de la performance globale (et maintenant dbrouillez
          vous pour deviner ce que j'entends par quilibr et homogne
          :-); le choix d'un processeur est une dcision importante, mais
          pas plus que celle du disque dur et de sa capacit, celle de la
          quantit de RAM, celle de la carte graphique, etc...

   _Q9._
          Qu'est-ce qu'une amlioration significative des performances ?

   _A._
          Je dirais que tout ce qui est sous 1% n'est pas significatif
          (pourrait tre dcrit comme marginal). Nous autres, simples
          mortels, avons du mal  percevoir la diffrence entre 2
          systmes dont les temps de rponses sont distants de moins de
          5% . Bien sr, certains valuateurs de performances - plutt de
          la tendance intgriste - ne sont aucunement humains et vous
          raconteront, en comparant 2 systmes dont les indices de
          performances sont de 65.9 et de 66.5, que ce dernier est
          indubitablement plus rapide.

   _Q10._
          Comment puis-je obtenir une amlioration significative de
          performance  moindre cot ?

   _A._
          Puisque le code source complet de Linux est disponible, un
          examen attentif et une re-conception algorithmique de
          procdures cls peuvent, dans certains cas, dboucher sur des
          amliorations jusqu' un facteur 10 en terme de performance. Si
          l'on est sur un projet commercial et qu'on ne souhaite pas
          plonger dans les trfonds du code source du systme,
          _l'implication d'un consultant Linux est ncssaire_. Cf. le
          Consultants-HOWTO.

7. Copyright, remerciements et divers

7.1 Comment ce document a-t-il t produit

   La premire tape a consist en la lecture de la section 4 "Writing
   and submitting a HOWTO" de l'index des HOWTOs crit par Greg Hankins.

   Je ne savais absolument rien au sujet de SGML ou de LaTeX mais, aprs
   avoir lu divers commentaires  propos de SGML-Tools, j'tais tent
   d'utiliser un paquetage de gnration de documentation automatique.
   Cependant l'insertion manuelle de directives de formattage me
   rappelait l'poque o j'assemblais  la main un moniteur 512 octets
   pour un processeur 8 bits aujourd'hui disparu. J'ai donc fini par
   rcuprer les sources de LyX, les compiler et je m'en suis servi dans
   son mode LinuxDoc. Une association chaudement recommende : _LyX et
   SGML-Tools_.

7.2 Copyright

   Le Linux Benchmarking HOWTO est plac sous le rgime du copyright (C)
   1997 par Andr D. Balsa. Les HOWTO Linux peuvent tre reproduits en
   totalit ou en partie et distribus en totalit ou partiellement sur
   n'importe quel support physique ou lectronique,  condition que ce
   message de copyright soit conserv dans toutes les copies. La
   redistribution commerciale est permise et encourage; cependant
   l'auteur aimerait tre prvenu de l'existence de telles distributions.

   Toute traduction (ndt : dont acte :-), tout travail driv ou
   priphrique incorporant un HOWTO Linux doit tre couvert par ce
   message de copyright.

   C'est--dire qu'il ne vous est pas possible de produire un travail
   driv  partir d'un HOWTO et d'imposer des restrictions
   supplmentaires sur sa distribution. Des exceptions  cette rgle
   pourront tre accordes sous certaines conditions; veuillez contacter
   le coordinateur des HOWTO Linux  l'adresse spcifie ci-aprs.

   Pour tre bref, nous souhaitons promouvoir la dissmination de cette
   information par autant de canaux que possible. Cependant, nous
   souhaitons garder un droit de copyright sur les HOWTOs et aimerions
   tre averti de tout projet de redistribution les concernant.

   Si vous avez des questions, veuillez contacter Greg Hankins, le
   coordinateur des HOWTOs Linux,  gregh@sunsite.unc.edu par e-mail ou
   au +1 404 853 9989 par tlphone.

   (ndt : pour cette version franaise du document original, il semble
   plus appropri de contacter Eric Dumas, coordinateur des traductions
   de HOWTOs dans la langue de Molire par e-mail  l'adresse
   dumas@freenix.EU.org).

7.3 Nouvelles version de ce document

   De nouvelles version du Benchmarking-HOWTO Linux seront mises 
   disposition sur sunsite.unc.edu et sur les sites mirroir (ndt : citons
   ftp.lip6.fr pour nous autres francophones). Ce document existe aussi
   sous d'autres formats tels que PostScript et dvi, et sont disponibles
   dans le rpertoire other-formats. Le Benchmarking-HOWTO Linux est
   galement disponible pour des clients WWW comme Grail, un butineur Web
   crit en Python. Il sera aussi post rgulirement sur
   comp.os.linux.answers.

7.4 Retour

   Les suggestions, corrections, et ajouts sont dsirs. Les
   contributeurs sont les bienvenus et en seront remercis. Les incendies
   (ndt : est-ce une traduction acceptable de flame ?) sont  rediriger
   sur /dev/null.

   Je serai toujours joignable  andrewbalsa@usa.net.

7.5 Remerciements

   David Niemi, l'auteur de la suite Unixbench, s'est aver tre une
   source inpuisable d'informations et de critiques (fondes).

   Je veux aussi remercier Greg Hankins, le coordinateur des HOWTO Linux
   et l'un des principaux contributeurs au paquetage SGML-tools, Linus
   Torvalds et toute la communaut Linux. Ce HOWTO est ma faon de
   renvoyer l'ascenseur.

7.6 Paravent

   Votre kilomtrage peut varier et variera sans doutes. Soyez conscients
   que l'valuation de performances est un sujet trs sensible et une
   activit qui consomme normment de temps et d'nergie.

7.7 Marques dposes

   Pentium et Windows NT sont des marques dposes d'Intel et de
   Microsoft Corporations respectivement.

   BYTE et BYTEmark sont des marques dposes de McGraw-Hill, Inc.

   Cyrix et 6x86 sont des marques dposes de Cyrix Corporation.

   Linux n'est pas une marque dpose, et esprons qu'elle ne le sera
   jamais.
