Performances synthétiques

• Objectif

Le but de cette section est d’isoler les performances de chaque disque sur des situations typiques, et qui dépendent directement de l’architecture du disque que nous avons vu plus tôt. Ceci nous permettra plus loin de comprendre les performances observées en situations réelles, puisqu’au final ce qui différencie la manière dont deux logiciels distincts vont utiliser un disque dur, c’est l’importance relative de chacune de ces situations typiques.

Un mot sur IOMeter : originellement développé par Intel et passé ensuite sous licence GNU GPL, ce logiciel est un puissant outil de création et de mesure d’entrées/sorties. Correctement paramétré, il est capable de simuler a peu près n’importe quel charge pour le disque dur. Nous l’utilisons donc à la fois comme test synthétique et pratique.

On commence bien sûr avec le temps d’accès en lecture sur les 50 premiers Go, mesuré via le test Webserver sur IOMeter (voir plus loin).

Logiquement, la vitesse de rotation des plateaux est le facteur le plus important dans ce test, puisqu’elle seule permet de diminuer la latence de rotation. Le Raptor est donc nettement en tête, suivi du 7K400 qui bénéficie ici de la répartition sur 5 plateaux malgré la restriction sur 50 Go. Les deux disques Seagate ont logiquement des performances équivalentes puisque la densité par plateau ne change en rien le temps d’accès. Le DiamondMax Plus 9 est largué, alors que son remplaçant le DiamondMax Plus 10 reste assez décevant.

Observons maintenant ce qu’il en est sur l’ensemble du disque. Pour ce faire nous avons utilisé Ipeak.

Ce qui est à observer ici, c’est l’écart entre ce temps d’accès et le temps d’accès mesuré sur 50 Go. Sur le Raptor 74 Go, 50 Go représente 68 % de la surface totale, de sorte que les deux temps d’accès sont très proches. Cela dit, cette explication n'est peut-être pas complète, et à la vue de ces résultats nous soupçonnons le Raptor de n'utiliser qu'une partie de la surface des plateaux qu'il utilise (les pistes extérieures). Par contre, le 7K400 voit ici son avantage diminuer par rapport aux autres disques, vu qu’il dispose d’une capacité totale de 400 Go. Notez que le SP1614C obtient ici les mêmes performances que le WD1200JD, ce qui n'est pas du tout le cas sur le graphe du haut. Cela prouve bien l'avantage que procure un nombre de faces/plateaux plus élevé pour la répartition d'une quantitée donnée. Si vous le pouvez, optez donc pour de grosses capacités afin de bénéficier de meilleures performances, d'autant que l'écart de prix entre les différentes capacités ne sont, en général, pas énormes au sein d'une même gamme.

Globalement, on voit bien que les performances des 7200 rpm restent cependant du même ordre. En retirant la latence de rotation, le temps d'accès sur ces mêmes disques varie entre 8,5 ms (7K400) et 10,3 ms (Maxline III). Cet écart reste intéressant et uniquement dépendant de la qualité de la mécanique, même si au final les résultats sont plus ou moins lissés.

Un mot sur la contre-performance du 7200.7 200 Go : elle provient d’un pic anormalement élevé où le temps d’accès est supérieur à… 50 ms ! Ceci semble être un défaut spécifique à notre disque de test, et le fait que le temps d’accès sur les premiers 50 Go soit similaire à celui du 7200.7 160 Go prouve que ce problème se situe vers la fin du disque. Voila une autre raison qui a poussé à restreindre la capacité utilisée par les benchmarks.

Poursuivons avec les temps d’accès en écriture. Pour les relever, nous avons utilisé le test Database d’IOMeter, le test Webserver n’exécutant que des accès en lecture.

Notez que la valeur absolue de ces temps d’accès est complètement fausse, mais il nous a semblé autrement plus intéressant de présenter ici les temps observés dans une situation « réelle », car les vrais temps d’accès en écriture sont proportionnels aux temps d’accès en lecture. Première chose : le Maxline III et le DiamondMax 10. Leur temps d’accès quasi-nul est une conséquence du cache de 16 Mo, qui leur permettent dans ce test Database d’effectuer « gratuitement » ce type d’accès. Le Raptor qui possède un cache de 8 Mo comme les autres, bénéficie quand à lui de sa vitesse de rotation. La bonne surprise provient ici du WD1200JD, particulièrement véloce. Plus loin, se trouvent les autres disques, avec un 7K400 assez lent en écriture puisqu’il repasse derrière le 7200.7 160 Go. La contre-performance du 7200.7 200 Go n’a aucune explication logique.

En ce qui concerne l’AAM, son activation n’entraîne une latence supplémentaire que pour certains disques, les plus lents en général.

Passons maintenant au débit, relevé via une lecture séquentielle sur h2bench.

Premier de la classe, encore une fois le Raptor, toujours pour les mêmes raisons. Ici, le deuxième est le 7200.7 200 Go, et pour cause : ce disque est le seul de l’ancienne génération à avoir une densité de 100 Go par plateau. Il est cependant talonné par le DiamondMax 10, lui aussi à 100Go/plateau. Plus étonnante, la performance du SP1614C (80 Go/plateau) qui bénéficie ici du formatage adaptatif qui lui permet une plus grande densité de données par piste, donc un meilleur débit. Notez cependant que ce phénomène est aléatoire, et que tous les SP1614C ne produiront pas un si bon résultat sur ce test. Le 7200.7 160 Go, doté de la même densité théorique, est en retrait. Contrairement à ce que nous a affirmé Maxtor, ce test prouve sans aucun équivoque que le Maxline III 250 Go possède bien des plateaux de 83,3 Go, et non de 100 Go comme le Maxline III 300 Go. Son débit reste du même niveau que le Seagate 7200.7 Go, ce qui est un peu décevant surtout compte tenu de sa densité et du fait qu’il embarque un plateau de plus.

La surprise nous vient du WD1200JD. Son débit prouve qu'il possède des plateaux d'une densité de... 60 Go ! Et cela, sur un disque issu du commerce en août 2004 (date de fabrication : février 2004) ! Bref, Western Digital se fout clairement de nous, même si le constructeur ne précise pas officiellement cette densité dans ses fiches techniques. Plus surprenant encore, l'activation de l'AAM provoque une perte de débit sur ce même disque. Difficile de croire que le déplacement plus lent des têtes de lecture puisse expliquer ce phénomène sur ce test de nature séquentielle, même avec les temps d'accès mesurés. On peut émettre l'hypothèse que l'activation de l'AAM réduit la vitesse de rotation des plateaux sur ce disque, ou bien que la latence de transfert des données explose. A noter le phénomène inverse mesuré sur le Caviar RE, avec un débit un peu meilleur lors de l'activation de l'AAM. Il est plausible que ce phénomène soit lié à la réduction de l'accélération de la tête de lecture, qui vibre moins et est donc plus rapidement operationnelle sur ce disque après chaque mini-déplacement.

Considérons maintenant un test qui nous permettra de distinguer les disques exploitant pleinement les ressources de l’interface. Il s’agit du débit du cache, mesuré via le « core-test » de h2bench.

Ici, le Maxline III tient le haut du pavé, même si ceci n’a a priori rien à voir avec son cache plus grand. Le Caviar et les 7200.7 font preuve d’une faiblesse qui nous fait dire que ces disques n’ont de « Serial ATA » que leur nom et leur connecteur, car en fait ces disques n’atteignent qu’à peine les limites de l’interface P-ATA 100. Notez que ceci n’a rien à voir avec la gestion native ou non du Serial ATA, puisque le 7K400 qui utilise lui aussi un pont, dispose d’un débit largement supérieur. Rappel : le Serial ATA 1 offre un débit théorique de 150 Mo/s…

On remarque qu’il s’agit du premier test mettant en avant une grosse différence de performance entre les différents paramètres utilisés sur le Maxline III. La marge d’erreur de ce test étant de 5 %, l’écart de performance est donc réel. Il tendrait à prouver que l’activation de l’AHCI dans le bios nécessite l’adjonction des drivers IAA afin que la gestion du NCQ soit correctement réalisée et ne pénalise pas les performances. Mais même dans ce cas, les performances sont légèrement en retrait par rapport à l’absence d’AHCI et d’IAA, ce qui devient logique si l’on suppose que l’activation et la bonne gestion du NCQ entraîne néanmoins une latence au niveau du cache…

Enfin, nous avons établi des tests sous IOMeter afin de mesurer les performances lors d’accès séquentiels et aléatoires. Pour les accès séquentiels, nous avons défini une taille de fichiers transférés variant de 512 octets à 256 Ko, avec un poids équivalent pour chaque intervalle (10 %). Nous avons accordé beaucoup d’importance aux accès en écriture, c'est-à-dire un cœfficient équivalent aux accès en lecture (50 %).

Au niveau des résultats, ils sont exprimés en nombre total d’entrées/sorties par seconde, ce qui représente simplement le nombre moyen de requêtes complétées à chaque seconde. Pour être bien clair sur la signification des termes utilisés, une « requête » désigne ici le processus complet de positionnement de la tête sur la piste demandée, puis la lecture ou l’écriture du bloc d’information (dont la taille varie ici entre 512 octets et 256 Ko).

Commençons par le dernier, et c’est une surprise : le 7K400. Il semble payer ici un temps d’accès en écriture moyen, mais cela ne suffit pas pour expliquer le fait qu’il se retrouve derrière tout le monde et notamment les deux 7200.7. Concernant ces derniers, on retrouve encore une fois le 7200.7 200 Go légèrement derrière son petit frère, ce qui démontre que le débit des disques n’a pas grande influence sur ce test. Le Raptor est bien positionné, mais c’est surtout le Maxline III qui met tout le monde d’accord. Ici, nous avons déjà vu l’explication dans la section dédiée à ce disque : la taille du cache est déterminante pour les accès séquentiels. Cependant, le DiamondMax 10 ne parvient pas à atteindre le même niveau, pourtant doté de la même quantité de cache.

Phénomène intéressant, on note un léger gain de performances en activant l'AAM sur certain disques, notamment le Western Digital, où le gain (presque 8 %) est supérieur à la marge d'erreur. On peut re-émettre l'hypothèse précédente selon laquelle la réduction des vibrations résiduelles qu'entraîne l'activation de l'AAM, améliore le temps de positionnement de la tête dans le cas d'accès séquentiels (c'est à dire de très courts déplacements de la tête).

Considérons maintenant les accès aléatoires. Le test est similaire au test précédent, à la différence près que nous avons changé les accès séquentiels en accès… aléatoires ! Ok, il y en a encore quelques uns qui suivent…

Accéder aléatoirement à des données pouvant être situées n’importe où sur le plateau, cela s’apparente à de multiples mouvements de la tête de lecture. Fort logiquement, la hiérarchie est donc assez proche de celle des temps d’accès en lecture, ce qui nous fait comprendre l’importance de ce facteur. En conséquence, le Raptor s’envole grâce à sa vitesse de rotation, l’Hitachi est un peu favorisé par ses 5 plateaux mais aussi par son architecture robuste, et les autres suivent derrière. La seule surprise provient des performances du Raptor une fois l’AAM activé, qui restent tout simplement inchangées.

Certains d’entre vous se demandent sans doute pourquoi le NCQ ne semble pas entrer en jeu sur ce test pourtant intitulé « Accès aléatoires ». En fait, d’autres paramètres sont à prendre en compte avec précaution lors de l’utilisation d’IOMeter, comme par exemple le nombre d’entrées/sorties exceptionnelles (‘Outstanding I/O’). Ces opérations sont utilisées quand une application demande la confirmation pour une entrée/sortie avant d’exécuter la suivante. L’utilisation d’entrées/sorties exceptionnelles permet de minimiser le temps perdu lors d’une erreur de transfert, mais réduit quelque peu les performances.

En exécutant le moniteur système sous de Windows 2000/XP, on peut observer le nombre d’entrées/sorties réalisées sur le disque. On s’aperçoit que le chargement d’un logiciel peut facilement faire dépasser les 50 entrées/sorties, alors que seules les applications très gourmandes en accès disques comme une défragmentation pour dépasser les 100 entrées/sorties simultanées. Pour les tests synthétiques, nous sommes restés sur le paramétrage par défaut qui représente une charge très linéaire.

Toutefois, il nous restait ici à évaluer la capacité de chaque disque à optimiser l’agencement des requêtes de lecture, tâche que nous détaillions lors de l’explication du NCQ. Pour ce faire nous avons eut recours au test ‘Read Queuing Optimizations’ d’Ipeak qui consiste à générer une multitude de threads, chaque thread générant à son tour des lectures aléatoires mais limitées à un seul secteur. Pour mémoire, un secteur est un quartier de pistes sur lequel on peut généralement stocker 512 octets. Le test commence avec un seul thread, mais ce nombre augmente au fur et à mesure jusqu’à devenir très important. Ce qui est mesuré dans ce test, c’est donc la répartition du temps d’accès en lecture en fonction du nombre de requêtes exceptionnelles.

Sur un disque incapable d’optimiser ces requêtes, le temps d’accès va croître linéairement avec l’augmentation de threads.

Au contraire, un disque avec une bonne gestion de la file d’attente des requêtes va au fur et à mesure être capable de maintenir des temps assez faibles avec le réagencement des requêtes.

Commençons par le fameux Maxline III. On observe ici que dès lors que l’on active l’AHCI, la trace est identique indépendamment de la présence ou non des drivers IAA. Par contre, celle obtenue sans activation de l’AHCI n’a rien à voir. Nous trouvons donc ici la réponse à notre interrogation initiale : ce n’est pas l’installation des drivers IAA qui activent le support du NCQ sur le Maxline III, mais bien l’activation de l’AHCI !

La lecture de ces graphes n’est pas forcément évidente la première fois, mais plusieurs indices permettent de comprendre que les traces obtenues avec l’AHCI sont meilleures que sans. Ainsi, lorsque le nombre de ‘child processes’ reste inférieur à deux, l’activation de l’AHCI permet de maintenir environ 80 % des temps d’accès entre 0 ms et 20 ms. Lorsque l’AHCI n’est pas activé, cette proportion ne dépasse pas 70 %, les 30 % restants correspondant à des temps d’accès plus longs.
Si l’on compare les traces de manière plus globale, c’est la présence d’une bosse en diagonale qui trahit l’absence du NCQ. Regardons par exemple ce qui se passe avec dix ‘child processes’ : en l’absence d’AHCI, le pic se situe entre 100 ms et 200 ms de temps d’accès. Avec l’AHCI, cette bosse se situe entre 0 ms et 50 ms. Un élément reste trompeur toutefois : sans AHCI et toujours en restant avec dix ‘child processes’, aucune requête ne dépasse les 200 ms, alors qu’avec AHCI on peut atteindre 250 ms. Cependant la proportion (c'est-à-dire le relief) située entre 200 ms et 250 ms reste anecdotique.

A noter la similitude de la trace du Maxline III avec celle du DiamondMax 10, qui paraît presque meilleure :

Poursuivons avec le Raptor. Sa gestion de la file d’attente est excellente puisqu’on se rapproche du cas idéal où indépendamment du nombre de threads, les temps d’accès ne dépasseraient pas les 100 ms. Le répartition « bave » beaucoup moins, bref, c’est ce qu’on fait de mieux en matière de disques S-ATA (SCSI exclu donc…).

Quand aux autres, ceux qui sont dépourvus d’optimisations de la file d’attente des requêtes, leurs traces sont similaires à celle du Maxline III sans AHCI. Voici donc dans l'ordre, les traces du 7K400, 7200.7 160 Go, 7200.7 200 Go, Samsung SP1614C, Caviar SE, DiamondMax 9, Caviar RE :

On remarquera une bavure inhabituelle avec le 7200.7 200 Go, au niveau des temps d’accès supérieurs à 200 ms entre 5 et 12 ‘child processes’ : il s’agit vraisemblablement du même problème qui nous a fait mesurer une temps d’accès en lecture de 21 ms sur l’ensemble de ce disque.

Envoyer le lien de cette page par email :

Votre adresse *

Votre nom *

Adresse du destinataire *

Envoyer

* Les adresses email récoltées via ce formulaire ne sont pas enregistrées sur notre serveur et ne servent qu'à l'envoi demandé