|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T s
Length: 19994 (0x4e1a)
Types: TextFile
Names: »ssba.doc«
└─⟦db229ac7e⟧ Bits:30007240 EUUGD20: SSBA 1.2 / AFW Benchmarks
└─⟦this⟧ »EUUGD20/AFUU-ssba1.21/ssba1.21F/ssba/ssba.doc«
SUITE SYNTHETIQUE DE BENCHMARKS DE L'A.F.U.U. (S.S.B.A. 1.21F)
Association Francaise des Utilisateurs d'Unix
11, rue Carnot
94270 Le Kremlin-Bicetre, France
Tel: (1) 46 70 95 90+
"En toute chose, il n'y a qu'une maniere de commencer
quand on veut discuter convenablement : il faut bien
comprendre l'objet de la discussion."
Platon.
MANIFESTE
La SSBA est le fruit des reflexions du Groupe de travail
Benchmark de l'AFUU (Association Francaise des Utilisateurs
d'Unix). Ce groupe, constitue d'une vingtaine de membres
actifs, d'origines diverses (universite, recherche publique
et privee, constructeur, utilisateur final), s'est donne
pour but de reflechir sur le probleme de l'evaluation des
performances des systemes informatiques, de collecter un
maximum de tests existants de par le monde, d'en dissequer
le code et les resultats, d'en discuter l'utilite, d'en
figer des versions et de les fournir sous la forme d'une
bande magnetique avec commentaires et procedures diverses.
Cette bande est donc, a la fois, un outil simple et
coherent pour l'utilisateur final comme pour le specialiste,
permettant une premiere approximation claire et pertinente
de la performance et serait aussi susceptible de devenir un
standard dans le monde UNIX(tm). Ainsi est nee la SSBA
(Suite Synthetique de Benchmarks de l'AFUU) dont vous voyez
ici la version 1.21F (dite de la "Sainte-Honorine").
UNE DEFINITION
Programme Benchmark : "Un programme informatique standard
utilise pour tester la puissance de traitement d'un ordina-
teur par rapport aux autres". Un programme benchmark peut
etre concu pour evaluer des problemes generaux, appeles
problemes benchmark, comme le traitement des fichiers, le
tri ou les operations mathematiques, ou pour evaluer un
probleme plus specifique qui tiendra plus compte de
__________________________
(tm) UNIX est une marque deposee par AT&T aux Etats-
Unis et dans d'autres pays.
27 Fevrier 1989
SSBA 1.21F
l'utilisation de cet ordinateur. La performance, comme la
vitesse de traitement, peut etre evaluee et comparee a celle
des autres ordinateurs testes avec le meme programme. Ce
processus est appele un test benchmark et peut etre utilise
comme un outil d'aide a la decision lors de l'acquisition
d'un ordinateur.
AVERTISSEMENT
L'evaluation des performances est une necessite dans le
domaine informatique comme dans tout autre. C'est un prob-
leme d'autant plus delicat qu'il n'a pas de solution
mathematique exacte et on doit donc travailler par approxi-
mations. Cet etat de fait a conduit, malheureusement, a des
exces ou a considerer ce probleme comme de la cuisine ou de
la "bidouille". Un des moyens d'approche est la mise au
point de tests benchmarks.
Il est facile de critiquer les benchmarks et de dire
qu'ils ne signifient rien. Par experience, il s'avere que
ceci est generalement le fait de constructeurs dont les
machines n'obtiennent pas de bons resultats aux benchmarks.
Le tout est de savoir de quoi l'on parle. Il ne faut pas
reduire une machine a un seul chiffre comme cela a ete trop
souvent le cas (le mips par exemple), mais il faut essayer
d'en donner une image multidimensionnelle en utilisant
plusieurs tests specifiques. C'est l'approche qui nous a
guides ici.
La solution qui parait immediatement ideale pour
l'utilisateur final est de prendre son application et de la
faire executer, telle quelle, sur un ensemble de machines.
Le probleme est que des que l'application evolue, il faut
tout recommencer; d'ou la necessite de trouver des tests
caracterisant certains types de problemes qui vont apparai-
tre dans la plupart des applications finales. L'usage de
ces tests risquant d'etre perverti, il faudra en indiquer
soigneusement les limites mais aussi les qualites reelles.
Il n'y a jamais eu et il n'y aura jamais de benchmarks
capables de representer completement la charge de travail
d'un systeme informatique en environnement reel (de nom-
breuses etudes visent a l'approcher). Cela depend d'un nom-
bre important de facteurs et c'est une evidence de le sig-
naler. Partant de cette constatation on peut rester assis
en se disant que l'on n'arrivera jamais a rien... Nous
avons choisi d'agir (de toute facon quelqu'un d'autre
l'aurait fait) en fournissant, conscients de toutes les lim-
ites de notre approche, un outil pratique et aussi valable
que possible.
Il existe actuellement environ 200 tests references dans
le monde. On peut les classer en 3 grandes categories :
27 Fevrier 1989
SSBA 1.21F
1) Les benchmarks dits "standards" : Dhrystone, Whetstone,
Linpack, Doduc, Byte, Spice, Euug, Stanford, Musbus, Liver-
more, Los Alamos..., publies dans des revues ou sortis de
chez les gros utilisateurs (General Electric, Exxon...),
dont le code a ete largement diffuse et parfois modifie,
generalement admis par l'ensemble de la profession mais a
propos desquels il regne la plus grande confusion quant aux
versions, aux resultats, aux interpretations et a
l'utilisation que l'on peut en faire.
2) Les benchmarks dits "commerciaux" : AIM, Neal Nelson,
Uniprobe, Workstation Laboratories..., largement documentes,
soumis a des licences dont les tarifs sont generalement tres
eleves, fournissant un service professionnel, mais donnant,
en general, a peu pres le meme type d'informations que les
tests precedents, avec des connotations plus applicatives
(AIM: systeme, Neal Nelson: bureautique, Workstation Labs:
technique) et un emballage soigne pour le decideur. Ces
tests n'en sont pas moins faillibles.
3) Les benchmarks dits "internes" utilises par certains
constructeurs (IBM, DEC, HP, ATT, Olivetti, NCR, Texas, pour
ceux qui ont fait l'objet de presentations) pour simuler des
charges de travail (pseudo-utilisateurs effectuant des
taches classiques) et calibrer ainsi leurs systemes.
Nous avons recupere ou pris connaissance de la majorite de
ces benchmarks dans les 3 categories. Nous les avons exam-
ines sur le fond et la forme. Nous les avons executes sous
diverses conditions afin de les valider.
Les tests selectionnes ici l'ont ete apres mure reflexion
et donnent a notre avis une image d'ensemble de la machine
aussi complete que possible, dans un souci de rigueur et de
portabilite.
Il y aura des evolutions vers des domaines plus applica-
tifs : graphique, temps reel, transactionnel, SGBD, lan-
gages,... Il existe aussi une version 1.21E qui est simi-
laire a la version 1.21F mais en anglais. La version 1.5
verra l'apparition de l'indice AFUU. La version 2.0 verra
l'ajout de nouvelles fonctionnalites.
L'interet d'une telle demarche est qu'elle soit largement
diffusee et adoptee par le plus d'utilisateurs possible.
Envoyez-nous vos resultats, decouvertes de bugs, commen-
taires ou insultes a :
afuu_bench@inria.inria.fr
Les seuls resultats publies le seront sous le controle de
l'AFUU, pour eviter de tomber dans le travers des boites a
lettres electroniques ou tout le monde vient poster des
resultats parfois douteux.
27 Fevrier 1989
SSBA 1.21F
La SSBA version 1.21F caracterise dans un systeme infor-
matique sous UNIX ou ses derives :
o la puissance CPU, la vitesse de traitement, les
capacites de calcul;
o l'implantation du systeme Unix dans son ensemble,
le systeme de fichiers;
o les compilateurs C et Fortran, l'optimisation;
o les acces et la gestion de la memoire, la perfor-
mance des caches;
o les entrees-sorties du disque, le controleur;
o le comportement en multi-utilisateur vis a vis de
taches significatives;
o un ensemble de parametres inherents au systeme.
COPYRIGHT
La SSBA est copyright AFUU. C'est un logiciel "domaine
public". L'AFUU degage toute responsabilite quant aux conse-
quences du passage de la SSBA.
Les procedures, les commentaires, une partie du code,
ainsi que l'architecture de l'ensemble et la mise au point
ont ete concus et realises par Philippe Dax (ENST), Chris-
tophe Binot (LAIH) et Nhuan Doduc (Framentec).
Les resultats seront publies sous la seule responsabilite
du constructeur ou de l'organisme ayant effectue le test et
n'engagera pas la responsabilite de l'AFUU. Le nom de l'AFUU
ne pourra etre cite, le cas echeant, qu'au titre de fournis-
seur de la SSBA. Les constructeurs et organismes interesses
peuvent publier les resultats dans Tribunix a condition que
le protocole de passage ait ete certifie par l'AFUU.
STRUCTURE DE LA SSBA
La SSBA comprend 12 benchmarks selectionnes comme cela a
ete dit plus haut. Ces 12 benchmarks sont, en partie ou en
totalite, issus des benchmarks suivants : le mips/Joy, le
Dhrystone, le Whetstone, le Linpack, le Doduc, le Byte, le
Saxer, l'Utah, le Mips, le Test C, le Bsd et la Musbus.
La SSBA est organisee en 16 repertoires sur un meme
niveau. A chaque benchmark est associe un repertoire dont
les noms sont respectivement : mips, dhry, whet, linpack,
doduc, byte, saxer, utah, outils, testc, bsd, musbus. Deux
repertoires supplementaires ssba et config servent respec-
tivement a lancer la SSBA et a analyser la configuration de
la machine et du systeme. Ces 14 repertoires font partie de
la distribution initiale qui comprend aussi un COPYRIGHT,
une procedure de verification et un repertoire afuu avec
quelques goodies. Deux autres repertoires, install et re-
sults, sont construits durant la phase d'execution de
27 Fevrier 1989
SSBA 1.21F
la SSBA. Le repertoire install contient des fichiers
parametre qui refletent le type du systeme UNIX et le choix,
par la personne qui lance la SSBA, des compilateurs et des
chaines d'options de compilation. Le repertoire results
contiendra les resultats et l'historique (trace) des opera-
tions effectuees durant l'execution de la SSBA.
L'ensemble de la SSBA, a son etat initial, comprend 236
fichiers repartis dans les 14 repertoires. La SSBA utilise
99 programmes source. Elle genere 92 resultats bruts et une
description des principaux parametres systeme de la machine.
Le volume occupe est de l'ordre de 1.5 Mega-octets. Il est
conseille de disposer au moins de 15 Mega-octets sur un meme
systeme de fichiers ou sera implantee la SSBA et de prevoir
aussi un /tmp d'au moins 4 Mega-octets pour la faire tourner
correctement.
Il est egalement necessaire d'avoir un systeme UNIX ou
derive qui supporte imperativement les 41 commandes
suivantes :
awk, bc, cat, cc, cd, chmod, comm, cp, date, dc, df, diff,
echo, ed, expr, f77, grep, kill, lex, ls, make, mkdir, mv,
od, ps, pwd, rm, sed, sh, sleep, sort, spell, split, tail,
tee, test, time, touch, wc, who, yacc.
Commandes facultatives :
banner, hostname, logname, lp, more, pr, shar, tar, uname,
uuname.
Pour information, la SSBA 1.21F s'execute completement en
3h00 sur une machine "4 mips" non chargee (avec coprocesseur
arithmetique).
Le profil fonctionnel des differents programmes est le
suivant :
CPU SYSTEME CALCUL MEMOIRE DISQUE CHARGE
dhrystone outils doduc seq disktime multi.sh
mips forkes whetstone ran saxer work
bct.sh execs linpack gau iofile
testc contswit float iocall
signocsw fibo24 bytesort
syscall
pipeself
pipeback
pipedis
27 Fevrier 1989
SSBA 1.21F
Outre les fichiers de code et de donnees pour chacun des
benchmarks, dans chacun des 14 repertoires il existe un jeu
de 5 fichiers supplementaires. Si bench represente le nom
fictif de l'un des benchmarks, pour un repertoire donne on
aura :
bench.doc les commentaires relatifs a ce benchmark,
bench.files la liste des fichiers mis en oeuvre,
bench.mk le fichier Makefile,
bench.cf le script-shell de configuration,
bench.run le script-shell d'execution.
Au cours de l'execution de la SSBA d'autres fichiers peu-
vent etre crees :
bench.h header cree par bench.cf,
bench.jou trace des compilations,
bench.log trace des operations lors de l'execution,
bench.kill script-shell pour tuer le benchmark courant,
bench.tmp fichiers temporaires,
bench.res resultats locaux a ce benchmark.
Que l'on se place au niveau general (repertoire ssba) ou
au niveau local de chaque benchmark, les fichiers Makefile
(bench.mk) comportent tous les memes cibles :
conf configuration,
compile compilation,
run execution,
sizes taille des executables,
clean suppression des objets, executables, resultats,
readme visualisation des documentations,
print impression des Makefiles et des script-shell,
printall impression de la totalite des sources,
tar archivage format tar,
shar archivage format shell-archiver.
MISE EN OEUVRE GENERALE
1 - Se placer sous le repertoire ssba, etre de preference
sous sh.
2 - Editer le fichier ssba.def qui contient les commandes
par defaut. Chaque entree de ce fichier est constituee
de 2 champs separes par un `:' (deux points). A droite
du `:' placez-y la commande ou la chaine d'options
appropriee a votre systeme ou celle de votre choix.
Par exemple :
27 Fevrier 1989
SSBA 1.21F
Compilateur C :gcc (par defaut : cc)
Options d'optimisation C : (par defaut : -O)
Options flottante C : (par defaut : rien)
Compilateur Fortran :f77 (par defaut : f77)
Options d'optimisation For : (par defaut : -O)
Options flottante Fortran : (par defaut : rien)
Printer :laser (par defaut : lp)
Printer options :-l66 (par defaut : -l66)
Pager :pg (par defaut : more)
Si le second champ est vide, c'est la valeur par defaut
qui est prise (voir ci-dessus).
3 - Taper la commande de lancement de la SSBA :
fiche (pour remplir la fiche signaletique)
ou
ssba.run&
4 - Se placer dans le repertoire results pour verifier le
bon fonctionnement de la SSBA en visualisant le fichier
ssba.log, journal historique des operations.
5 - En cas de probleme il est possible de tuer l'ensemble de
la SSBA en tapant ssbakill (situe sous le repertoire
ssba), si cette commande est sans effet essayer
ssba.kill.
6 - Attendre la fin d'execution de la SSBA et analyser les
resultats dans le fichier ssba.res, dont un condense se
trouve dans le fichier synthese, situes tous les deux
dans le repertoire results.
7 - Imprimer les fichiers ssba.log, ssba.res et synthese du
repertoire results, puis les communiquer a l'AFUU.
MISE EN OEUVRE LOCALE
L'execution locale d'un benchmark est possible a condition
que les fichiers des repertoires install et config aient ete
crees au prealable, soit par ssba.run& soit par ssba.ini
(voir l'en-tete de ce fichier), suivi de unix.sh, suivi de
make conf, et enfin dans config de make compile -f
config.mk.
En effet, pour que tout benchmark puisse s'executer nor-
malement, il est necessaire d'avoir calcule le parametre de
granularite du temps `HZ', puis de l'avoir introduit dans
les outils de mesure du temps : config/chrono et
config/etime.o.
Cette phase de pre-initialisation construit des fichiers
qui seront utiles pour la plupart des benchmarks :
install/hz.h, install/signal.h, install/*.cmd et
27 Fevrier 1989
SSBA 1.21F
install/*.opt.
Une fois cette operation preliminaire effectuee, la marche
a suivre, pour executer localement un benchmark, est la
suivante :
make conf -f bench.mk configuration
make compile -f bench.mk compilation
make run -f bench.mk execution
make sizes -f bench.mk tailles
CONSEILS
o Ne pas chercher a modifier quoi que ce soit, la SSBA pour-
rait ne plus tourner et de toute maniere nous nous en
apercevrions a la sortie des resultats... Et puis c'est
vilain !
o Ne pas paniquer devant les temps d'execution ou certaines
erreurs.
o Si le "doduc" ne se compile pas il faut peut-etre aug-
menter la taille de la table des symboles : rajouter
-Nn4000 a la ligne FFLAGS du fichier doduc.mk.
o Vous pouvez executer sans crainte la SSBA sous root (con-
seille pour les systemes qui n'autorisent pas plus de 25
processus par utilisateur), mais il serait preferable de
l'executer en mode utilisateur normal, au total, en phase
de simulation 8 utilisateurs la SSBA genere 46 processus.
o Pour les audacieux, dans le repertoire musbus, le fichier
musbus.run, a la ligne nusers=8, il est tout a fait possi-
ble de mettre 16, 32 ou ce que vous voulez, il faut sim-
plement s'assurer que le noyau de la machine le suppor-
tera.
Dans le repertoire bsd, le fichier bsd.run, le parametre
1500 apres le "-p" de seq, ran, gau, peut etre modifie
en fonction de la memoire virtuelle disponible, par exem-
ple 10000 pour 10 Mega-octets.
D'autres parametres peuvent etre modifies tres simplement.
N'hesitez pas, la SSBA est votre outil.
o Pour vos achats, faites executer la SSBA sur une machine
fraiche chez le constructeur et examinez avec lui les
resultats obtenus.
o Et surtout :
PRENEZ BEAUCOUP DE PLAISIR
Que la force soit avec vous !
Christophe Binot, Philippe Dax, Nhuan Doduc
27 Fevrier 1989