Chapitre 5 Étalonnage de Windows et de Linux
5.3 Résultats de DBench-OS-Postmark
5.3.2 Raffinement des mesures de l’étalon
Dans ce paragraphe, les trois mesures présentées dans le paragraphe précédent sont raffinées par rapport aux différentes issues de l’OS et à l’état final de l’activité. Ce raffinement a pour but de fournir d’éventuelles explications et de favoriser une meilleure compréhension des valeurs obtenues.
Mesures de robustesse
Comme nous l’avons précédemment mentionné, nous n’avons aucune information sur l’état du système dans les cas de non signalement. Pour cela, il est conseillé de raffiner ces cas en les combinant avec les différents états de l’activité pour mieux constater l’effet de la corruption des appels système. Nous rappelons que les issues de non signalement correspondent à 56% des expériences réalisées sur Windows alors que ce pourcentage varie entre 25% et 31% des expériences réalisées sur Linux.
Les mesures de robustesse conjointes aux différentes issues de l’activité montrent que l’activité finit son exécution dans 91% des cas de non signalement de Windows. Ce pourcentage augmente dans les cas des systèmes Linux pour atteindre les 96%. De plus, si nous classons l’ensemble des expériences menées sur les systèmes d’exploitation selon l’état final de l’activité, nous constatons que dans 94% des cas l’activité finit son exécution sur les systèmes d’exploitation Windows alors que pour les systèmes Linux, l’activité finit son exécution dans 73% à 76% des cas seulement.
Dans le cas d’utilisation de Postmark pour activer le système cible, nous avons la possibilité de détecter la terminaison correcte et incorrecte de l’activité. Le raffinement détaillé des mesures de robustesse par rapport aux différents états de l’activité est présenté dans l’Annexe 2. Nous notons enfin que nous avons réalisé une étude de sensibilité des résultats obtenus pour la technique de corruption des paramètres des appels systèmes. Les résultats détaillés de cette étude de sensibilité sont présentés dans l’annexe 3.
Temps de réaction de l’OS
Nous présentons dans le Tableau 5-4 le temps de réaction détaillé des OSs par rapport aux différentes issues de l’OS après l’exécution d’un appel système corrompu (Code d’erreur, Exception et Non Signalement). Par conséquent, trois moyennes s’ajoutent à la moyenne générale Texec présenté dans le paragraphe précédent. Nous notons également que les moyennes présentées dans ce tableau, relatives aux OSs de la famille Linux, ne prennent pas en compte la durée d’exécution de l’appel système execve qui a doublé le
τ
exec de Linux 2.6.6 par rapport aux autres versions ciblées de Linux.Pour les systèmes Windows, nous remarquons que Texec est toujours inférieur à τexec. Par contre, Texec est supérieur à la moyenne en absence de fautes dans les cas des systèmes Linux. Le Texec le plus faible est enregistré pour Windows 2003. En ne considérant que les trois systèmes Windows ciblés dans le chapitre précédent, nous trouvons que Windows XP détient le Texec le plus petit. Cependant, nous avons vu dans le chapitre précédent que Windows XP avait le temps de réaction le plus rapide par rapport à Windows 2000 et Windows NT4, en présence et en absence de fautes. Dans le cas de Postmark, nous
5.3 Résultats de DBench-OS-Postmark
101
constatons que Windows XP a un temps de réaction, en absence de fautes, plus grand que ceux des deux autres systèmes. En fait, Postmark active 27 appels système dont la moitié fait partie du composant fonctionnel « systèmes de fichiers » ; le
τ
exec relatif à ces appels système est de 574 µs pour Windows XP alors qu’il ne dépasse pas 250 µs pour Windows 2000 et 380 µs pour Windows NT4. Par conséquent, la grande valeur de τexec de Windows XP est due aux temps d’exécution des appels systèmes appartenant au composant fonctionnel « système de fichiers » qui semble être un point de faiblesse dans Windows XP.Tableau 5-4 : Temps détaillé de réaction de l’OS Famille Windows
Windows NT4 Windows 2000 Windows XP Moyenne Ecart Type Moyenne Ecart Type Moyenne Ecart Type τexec 248 µs 136 µs 315 µs
Texec 148 µs 219 µs 118 µs 289 µs 114 µs 218 µs
TEr 45 µs 107 µs 34 µs 61 µs 45 µs 118 µs
TXp 40 µs 15 µs 37 µs 15 µs 50 µs 96 µs
TNS 234 µs 437 µs 186 µs 375 µs 168 µs 265 µs Windows NT4 Server Windows 2000 Server Windows 2003 Server Moyenne Ecart Type Moyenne Ecart Type Moyenne Ecart Type
τexec 125 µs 175 µs 173 µs Texec 110 µs 221 µs 131 µs 289 µs 102 µs 198 µs TEr 41 µs 66 µs 29 µs 33 µs 25 µs 61 µs TXp 35 µs 15 µs 37 µs 15 µs 48 µs 20 µs TNS 166 µs 280 µs 210 µs 396 µs 156 µs 252 µs Famille Linux
Linux 2.2.26 Linux 2.4.5 Linux 2.4.26 Linux 2.6.6 Moyenne Ecart Type Moyenne Ecart Type Moyenne Ecart Type Moyenne Ecart Type τexec 156 µs 73 µs 73 µs 74 µs Texec 167 µs 300 µs 466 µs 2276 µs 425 µs 2055µs 93 µs 12 µs TEr 208 µs 361 µs 92 µs 105 µs 84 µs 6 µs 91 µs 10 µs TXp 88 µs 5 µs 91 µs 8 µs 91 µs 8 µs 106 µs 13 µs TNS 85 µs 5 µs 1545 µs 4332 µs 1405 µs 3912µs 91 µs 11 µs
5.3 Résultats de DBench-OS-Postmark
102
Dans le cas de systèmes Windows, et à l’exception des deux OSs Windows NT4 et Windows
NT4 Server, le temps nécessaire pour retourner un code d’erreur est inférieur au temps
nécessaire pour notifier une exception, ce qui confirme les résultats présentés dans le chapitre précédent. D’autre part, la supériorité des TEr de Windows NT4 et Windows NT4
server par rapport aux correspondantes TXp est due à l’appel système GetCPInfo : la corruption de son premier paramètre entraîne une durée d’exécution assez élevée avant de retourner un code d’erreur.
Dans les cas des systèmes Linux, nous remarquons que les temps de réaction des deux révisions de la versions 2.4 dans le cas de non signalement (TNS) sont très grands par rapport à ceux des deux autres systèmes ciblés. En plus, les très grandes valeurs des écarts types correspondants suggèrent une grande variation des valeurs autour de cette moyenne. La Figure 5-2 illustre les temps d’exécution des différents appels système des OSs Linux dont les paramètres corrompus n’ont pas entraîné une réaction de la part de l’OS. Nous constatons clairement que les TNS des deux révisions de la versions 2.4 ont une grande valeur par rapport aux autres versions à cause du temps d’exécution de l’appel système mkdir. Son temps d’exécution est approximativement 120 fois plus grand que dans les autres cas.
Un autre point à signaler correspond au TEr de Linux 2.2.26 qui a une très grande valeur par rapport aux TEr des autres versions. Son écart type est également grand. A l’exception de cette révision, tous les autres systèmes Linux ont un TEr plus petit ou égal au temps nécessaire pour retourner une exception. La Figure 5-3 illustre tous les temps de réaction des appels système qui ont retourné des codes d’erreur après la corruption de leurs paramètres. Cette figure montre que les temps d’exécution des appels système sont similaires, à l’exception du temps correspondant à l’appel système unlink qui a une grande valeur dans le cas de Linux 2.2.26, ce qui explique la grande valeur de TEr de Linux 2.2.26 par rapport aux autres versions.
0 40 80 120 160 200 _llseek brk close mkdir munm ap old_m
map open read write
2.2.26 2.4.5 2.4.26 2.6.6 b
a
a=14070 b=12739
5.3 Résultats de DBench-OS-Postmark
103
0 40 80 120 160 200_llseek access close fstat64 mkdir munmap
old_mmap
open read rmdir uname unlink write
2.2.26 2.4.5 2.4.26 2.6.6
a=863
a
Figure 5-3 : Temps de réaction de Linux, cas de retour de code d’erreur
Notons enfin que nous avons refait le calcul des différentes moyennes en excluant cette fois les appels systèmes qui ont eu des valeurs exceptionnelles (execve, mkdir et unlink). Ce nouveau calcul a conduit à des temps d’exécution Texec équivalents pour les quatre systèmes d’exploitation Linux ciblés.
Temps de redémarrage du système
Malgré la ressemblance entre les temps de redémarrage pour chacun des systèmes en présence et en absence de fautes (avec un avantage pour les systèmes d’exploitation de la famille Linux), plusieurs points restent encore à explorer. Plus particulièrement, nous avons montré dans le chapitre précédent que le temps de redémarrage de Windows est influencé par l’état de terminaison de l’activité.
Dans la Figure 5-4, nous présentons les temps détaillés de redémarrage de deux systèmes d’exploitation chacun appartenant à une des deux familles : Windows NT4 et Linux 2.2.26. Sur cette figure, nous constatons que la distribution des valeurs de temps de redémarrage est très différente pour les deux systèmes.
50 100 150 200 250 0 50 100 150 200 250 300 350 400 450 Expérience secondes Windows NT4 50 100 150 200 250 0 50 100 150 200 Expérience secondes Linux 2.2.26