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)