3. Le Linux Benchmarking Toolkit (LBT)

Je propose ici un ensemble d'outils pour l'�valuation de performances sous Linux. C'est la version pr�liminaire d'un vaste environnement d'�valuation de performances pour Linux, il est destin� � �tre am�lior� et � voir ses fonctionnalit�s �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 s�rs que je serai heureux d'int�grer les changements que vous aurez sugg�r� dans la mesure du possible. Avant d'entamer une pol�mique, lisez ce HOWTO et les documents cit�s en r�f�rence : les critiques inform�s sont les bienvenus, les critiques st�riles ne le sont pas.

3.1 Motivations

Elles sont dict�es par le bon sens, tout simplement :

1. Cette suite ne doit pas n�cessiter plus d'une journ�e de dur�e d'ex�cution. En mati�re de benchmarks comparatifs (diverses ex�cutions), personne ne veut passer des jours � essayer de trouver la configuration mat�rielle le plus rapide pour un syst�me donn�. Id�alement, 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 refl�tant la performance mesur�e.
4. Il devait y avoir un m�lange de benchmarks synth�tiques et de benchmarks applicatifs.
5. Chacun des benchmarks synth�tiques devrait pousser un sous-syst�me particulier � ses limites.
6. Les r�sultats des benchmarks synth�tiques ne devraient pas �tre combin�s par le biais d'une moyenne afin d'en extraire un facteur de m�rite global (cela va � l'encontre du principe fondateur des benchmarks synth�tiques et conduit � une perte d'information consid�rable).
7. Les benchmarks applicatifs devraient �tre repr�sentatifs de t�ches couramment ex�cut�es sur des syst�mes Linux.

3.2 S�lection des benchmarks

J'ai s�lectionn� 5 suites des benchmarks diff�rentes en �vitant autant que possible les recouvrements dans les tests :

1. Compilation du noyau 2.0.0 (configuration par d�faut) avec gcc.
2. Whetstone version 10/03/97 (la version la plus r�cente de Roy Longbottom).
3. xbench-0.2 (avec les param�tres d'ex�cution rapide).
4. Les benchmarks UnixBench version 4.01 (r�sultats partiels).
5. Les benchmarks de la suite BYTEmark du magazine BYTE beta release 2 (r�sultats partiels).

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

3.3 Dur�e des tests

1. Compilation du noyau 2.0.0 : 5 - 30 minutes, selon la performance r�elle 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 (c�d 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 m�moire (ndt : surtout � l'�dition de liens) : ceci contribue � att�nuer le biais induit par le cache L2 lorsque l'on se contente de passer de petits tests.
• Les E/S vers le disque sont fr�quentes.
• Proc�dure de test : trouvez une antique arborescence source de 2.0.0, compilez la avec les options par d�faut (make config, appuyez sur Enter autant de fois que n�c�ssaire). Le temps affich� doit correspondre � la dur�e pass�e sur la compilation c�d apr�s que vous ayez tap� make zImage (sans prendre en compte le make dep clean). Notez que l'architecture cible par d�faut 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.
• R�sultats : la dur�e 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'int�rieur d'une courte (et dense) boucle. Le code source (en C) est assez lisible et il est tr�s facile de voir quelles sont les op�rations flottantes impliqu�es.
• C'est le plus court des tests de la LBT :-).
• C'est un "Vieux Classique" : des chiffres sont disponibles pour comparaison, ses d�fauts et ses faiblesses sont bien connues.
• Proc�dure de test : le code source le plus r�cent devrait �tre t�l�charg� depuis le site d'Aburto. Compilez le et ex�cutez le en mode double pr�cision. Sp�cifiez gcc et -O2 en tant que pr�-processeur et option du compilateur respectivement. D�finissez aussi la variable du pr�-processur POSIX � 1 pour pr�ciser le type de machine.
• R�sultats : 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 pond�r�e de quelques tests rapport�s 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 l�gitimement se demander si xbench est v�ritablement ad�quat en tant que test pour des serveurs X modernes. N�anmoins, c'est le meilleur outil que j'ai trouv�.
• Proc�dure de test : compilez avec -O2. On sp�cifiera aussi quelques options pour une ex�cution courte : ./xbench -timegoal 3> results/name_of_your_linux_box.out. Pour g�n�rer l'indice xStones, il nous faudra encore lancer un script awk; la fa�on 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 syst�me est dans la derni�re colonne de la ligne contenant le nom de votre machine -- nom que vous aurez sp�cifi� pendant le test.
• R�sultats : un indice de performances exprim� en xStones.
• Note : ce test, en l'�tat, est d�pass�. Il devrait �tre r�-�crit.

UnixBench version 4.01

• Quoi : mesure la performance globale d'un syst�me UNIX. Ce test met en oeuvre �vidence la performance des E/S fichier et de la gestion du multi-t�ches par le noyau.
• J'ai supprim� tous les r�sultats de tests arithm�tiques et je n'ai conserv� que les tests orient�s syst�me.
• Proc�dure de test : make avec -O2. Ex�cution avec ./Run -1 (tournez chacun des tests une fois). Vous trouverez les r�sultats dans le fichier ./results/report. Calculez la moyenne g�om�trique des indices de EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL SCRIPTS et SYSTEM CALL OVERHEAD.
• R�sultats : un indice de performance du syst�me.

(ndt : la moyenne g�om�trique se d�finit comme la racine n-i�me du produit des n termes consid�r�s)

Les benchmarks Bytemark du magazine BYTE

• Quoi : fournit une bonne mesure de la performance CPU. Voici un extrait de la documentation : "Ces benchmarks ont �t�s con�u de fa�on � mettre en �vidence la limite sup�rieure de la CPU, de la FPU et de l'architecture m�moire d'un syst�me. Ils ne peuvent mesurer la performance du sous-syst�me graphique, des acc�s disque ou du d�bit r�seau (ce sont l� le domaine d'un ensemble diff�rent de benchmarks). C'est pourquoi, il est souhaitable que vous n'utilisiez les r�sultats de ces tests qu'en tant qu'�l�ment d'appr�ciation partielle, et non pas totale, lors de l'�valuation de la performance d'un syst�me."
• J'ai supprim� tous les r�sultats de test FPU puisque la suite Whetstone est tout aussi repr�sentative des performances � cet �gard.
• J'ai d�compos� les tests entiers en deux groupes : ceux qui sont plus repr�sentatifs de la performance cache m�moire/CPU, et ceux qui utilisent l'arithm�tique enti�re de la CPU.
• Proc�dure de test : make avec -O2. Ex�cutez le test avec ./nbench >myresults.dat ou quelque chose d'approchant. Puis, � partir de myresults.dat, calculez la moyenne g�om�trique des indices des tests STRING SORT, ASSIGNMENT et BITFIELD. Ceci vous donnera l'indice m�moire. Calculez la moyenne g�om�trique des indices des tests NUMERIC SORT, IDEA, HUFFMAN et FP EMULATION: c'est l'indice entier.
• R�sultats : un indice m�moire et un indice entier calcul�s comme expliqu� ci-dessus.

3.5 Am�liorations possibles

La suite de benchmarks id�ale tournerait en quelques minutes, comprendrait des benchmarks synth�tiques testant chaque sous-syst�me s�par�ment et des benchmarks applicatifs fournissant des r�sultats pour diff�rentes applications. Elle produirait aussi automatiquement un rapport complet et �ventuellement l'enverrait par e-mail � une base de donn�es 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 d�clinaisons possibles (i386, Alpha, Sparc...).

Si quelqu'un a la moindre id�e concernant l'�valuation de performances r�seau 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 ex�cution), s'il vous plait contactez-moi.

3.6 Formulaire de rapport LBT

Au-del� des tests, la proc�dure d'�valuation de performances n'aurait pas �t� compl�te sans un formulaire d�crivant la configuration mat�rielle utilis�e lors de leur ex�cution. Le voici donc : (il se conforme aux directives prescrites dans la FAQ de comp.benchmarks) :

(ndt : le formulaire en question n'a d�lib�r�ment pas �t� traduit, de fa�on � ce que l'auteur de ce HOWTO puisse automatiser leur traitement en vue de maintenir une base de donn�es de r�sultats. 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 pr�sent dans ce formulaire que pour de possibles
interpr�tations des r�sultats, et tant que tel, il est optionnel.
Il pourrait cependant constituer la partie la plus importante de votre
compte-rendu, tout particuli�rement si vous faites de l'�valuation
de performances comparative.
______________________________________________________________________

3.7 Test de performances r�seau

Le test des performances r�seau est un v�ritable d�fi en soi puisqu'il implique au moins deux machines: un serveur et une machine cliente. Pour cette raison ce genre de test n�cessite deux fois plus de temps pour �tre mis en place, il y a plus de variables � contr�ler, etc... Sur un r�seau Ethernet, il me semble votre meilleure option est le paquetage ttcp. (� developper)

3.8 Les tests SMP

Les tests SMP sont un autre d�fi, et tout test con�u sp�cifiquement pour un environnement SMP aura des difficult�s � s'av�rer valide dans des conditions d'utilisation r�elles parce que les algorithmes qui tirent parti du SMP sont difficiles � d�velopper. Il semble que les versions du noyau Linux les plus r�centes (> 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 mati�re de comparaison de mat�riel/SE similaires en mode SMP et en mode UP."

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

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:25