Les tests ont été refaits avec de nouveaux noyaux. 
La première série de tests a été réalisée avec l'utilitaire "hdparm" dont l'option "-t" permet de mesurer un débit IO en lecture. 
Pour les machines que j'ai utilisées il s'agit des disques sda,sdb,sdc,sdd. L'une de ces machines est munie de disques en miroir, il a donc été nécessaire d'agir sur deux disques simultanément pour changer de scheduler. 
Premier test. 
Les résultats sont les suivants (valeurs en MO/seconde, le plus fort est le mieux !) : 

Constatation 1 : 
Les résultats sont très serrés, les différences sont peu marquantes et ne font en général que quelques pourcents. 
Constatation 2 : 
Les résultats sont différents sur la même machine avec des noyaux différents. 
Constatation 3 : 
Les résultats SSD sont meilleurs sur le Dualcore ... c'est normal, il ne s'agit pas du même SSD mais  d'un modèle vendu comme plus performant (et cela a l'air vrai) ... mais malheureusement nettement plus cher. 
Les résultats obtenus avec un noyau  > 2.6.32 sont un peu bizarres, à partir du 2.6.33 un des schedulers a disparu, je n'ai pas trouvé trace du "anticipatory scheduler", il ne reste que NOOP, CFQ et DEADLINE, les résultats sont comme pour le 2.6.32 très bizarres sur la partie SSD et se tiennent bien sur la partie SATA. J'ai oté toutes référence au scheduler "anticipatory" pour avoir des tableaux comparables sur toutes les versions. 

Le SSD présente des anomalies importantes de vitesse sur les noyaux récents :

• Noyau 2.6.32 
  • Mini de 61,33
  • Maxi de 102,37 soit un écart de plus de 60% !
  • Alors que la partie SATA présente un écart inférieur à 3%.
• Noyau 2.6.33
  • Mini de 59,73
  • Maxi de 92,32 soit un écart de près de 60%
  • Alors que la partie SATA présente un écart inférieur à 5%.

Les tests "hdparm" semblent complètement dépassés pour les dernières versions du noyau. Les indications relatives de ce test ne sont valables que pour les noyaux < 2.6.32. D'autre part les améliorations apportées par les noyaux >= 2.6.32 sont bel et bien ressenties à l'utilisation, voir les tests de compilation. 
Voir aussi la page sur les nouveaux tests "hdparm" éxécutés avec l'option " --direct" permettant d'utiliser plus directement le hardware. 
 

La première version des tests présentait des anomalies de performance et une grande irrégularité. J'ai "découvert" une option complémentaire de cet utilitaire ( --direct ) permettant d'atteindre plus directement le hardware en évitant le passage par les buffers système. Ce type d'option (utilisant le flag "O_DIRECT" du noyau) est d'ailleurs recommandé pour les bases de données afin d'éviter de multiples recopies en mémoire sources de perte de performance.

• Sans "O_DIRECT" les données effectuent le transit suivant : HARDWARE --> page cache --> programme utilisateur.
• Avec "O_DIRECT" le transit est plus direct : HARDWARE --> programme utilisateur

Cela se voit d'ailleurs dans les résultats qui représentent ainsi mieux les performances "brutes" du hardware (les valeurs indiquées sont en MO/seconde). 
Dualcore (SSD rapide) : 

Quadcore (SSD "lent") : 

Les résultats sont un peu irréguliers pour le SSD ce qui "baisse" la moyenne à 123MO/seconde en 2.6.31 et 133MO/seconde pour le noyau 2.6.33. 
Autre machine (ATOM N330) : 
J'ai fait faire les tests sur un nouveau "petit" serveur (ATOM N330) avec lequel on obtient les résultats suivants : 

Ce qui n'est pas mal du tout pour une petite machine. 
Il a juste fallu ajouter un disque SATA de 160Go (8Mo cache) dans la belle boîte pour faire ces tests.

Deuxième test. 
Devant ces résultats un peu théoriques j'ai essayé de faire d'autres mesures peut-être plus représentatives. J'ai donc mesuré le temps de "dézipper" et de "rezipper" les sources du noyau "linux-2.6.31.6.tar.gz" soit à peu près 79Mo zippés et # 380Mo dézippés. 
Les commandes exécutées sont : 
sync 
cd $REP 
gzip -d linux-2.6.31.6.tar.gz 
sync 
gzip linux-2.6.31.6.tar 
sync 

Et la durée "ellapsed" de l'ensemble est mesurée par la commande "time" dont le résultat "real" est repris dans les tableaux. 
Trois séries de tests ont été exécutées pour chacun des schedulers disponibles.  

Les résultats montrent que les SSD ne gagnent pas toujours ! Curieusement tous les tests sur le disque SSD sont très nettement moins bons, presque deux fois moins rapides !

Devant les différents points d'interrogation posés par les tests précédents j'ai décidé de faire d'autres tests encore plus près de "la vie réelle" en réalisant un petit exercice de compilation. 
J'ai pris comme "cobaye" le logiciel IPERF dans sa version 2.0.4 et réalisé les opérations suivantes :

• Création d'un répertoire de compilation sur le SSD /var/tmp/iperf-2.0.4
• Création d'un répertoire de compilation sur le disque SATA /RAIDZZZ/tempo/iperf-2.0.4

Chacun de ces répertoires comporte bien entendu l'arbre des sources de IPERF et une compilation a été réalisée "à la main". Les opérations réalisées par le script (mesurées par la commande "time" ) seront : 
sync 
cd $REP 
make clean 
rm -f config.status 
./configure 
make -j 2 
sync 
Les temps "real" figurent dans le tableau suivant ( valeurs en secondes, le plus faible est le mieux) :

Par ailleurs les différences entre les différents scheduler d'IO ne sont pas significatives sur ces tests car elles restent inférieures à 1%.Les temps sont meilleurs pour les deux types de disques dans les montées de version du noyau Linux. 
Le temps total (9 exécutions) passe de #92 secondes pour le noyau 2.6.33 à #95 pour le 2.6.32 à #130 secondes pour le 2.6.30. Visiblement les développeurs du noyau ont bien travaillé et les progrès sont nettement visibles. 
Cette série de tests montre un léger avantage au SSD par apport au disque "classique" une différence de 4 à 6% se manifeste en sa faveur.

La construction des tests progresse, les groupes de valeurs ont été choisis :

• Taille des fichiers testés : 4, 8, 16, 32, 64, 128, 256, 512 et 1024 MégaOctets
• Taille des enregistrements : 16, 32, 64, 128, 256 et 512 octets

 Cela devrait donner des chiffres significatifs. Pour pouvoir effectuer ces tests pour plusieurs noyaux sur SSD et SATA classique un petit ensemble de scripts a été réalisé et pour présenter de jolis graphiques je me suis replongé dans "GNUPLOT" et après quelques scripts de traitement des données il me sera possible de présenter de jolis dessins. 
Par contre l'acquisition des tests est très longue et se chiffre en heures pour un seul passage complet de tests. 
Devant le peu de différences entre les différents schedulers les tests ne seront faits que pour le scheduler "noop", a priori le moins compliqué, qui devrait mieux représenter la performance "brute" des disques. 
Les petits dessins et quelques commentaires sous peu ... dès que l'ensemble des tests aura "tourné" et que quelques commentaires seront disponibles ... 
La commande utilisée ( ici fichier de 1024Mo, enregistrements de 32 caractères sur un disque SATA ) : 

iozone -s 1048576 -r 32 -f /tempo/testio -I -o -M

• -s Taille du fichier en KO
• -r taille de l'enregistrement en cacartères
• -f fichier de travail (sur disque SATA ou SSD)
• -I  Use VxFS VX_DIRECT, O_DIRECT,or O_DIRECTIO for all file operation
• -o  Writes are synch (O_SYNC)
• -M Report uname -a output

8

Les tests sont réalisés sur deux machines possédant chacune des disques SSD et des SATA classiques :

• Amd dualcore 4400+ à 2.20 Ghz, 8 Go RAM, contrôleur SATA nvidia CK804, avec un SSD très rapide et deux disques SATA 1To en RAID1 (miroir).
• Amd quadcore 905e à 2,5Ghz, 8Go Ram, contrôleur ATI SB700/SB800, avec un SSD plus standard et deux disques SATA assez anciens de 160Go en RAID1 (miroir).

Cà y est enfin, j'ai toutes les données nécessaires, le processus est très long ... deux à quatre heures pour chaque noyau. Et en plus il ne faut pas toucher la machine pendant la prise de données pour ne pas fausser les résultats. 
Les scripts préparés pour Gnuplot sont OK, ils génèrent bien les graphes escomptés, maintenant il faut essayer d'en extraire la quintessence pour la présenter. On peut déjà dire que certains résultats sont un peu curieux et n'ont pas d'explication immédiate, d'autres sont plus évidents et vont dans le sens prévu. Il semble toutefois que les disques SSD ne soient pas la panacée malgré un certain nombre d'avantages. 
Il semble par ailleurs que "iozone" soit partiellement inadapté aux disques modernes munis de cache très importants. Les disques SATA ont 8Mo de cache sur la machine quadcore et 32Mo sur la machine dualcore. Les caches des disques SSD sont encore plus volumineux : 64 Mo. 
Très bientôt les premiers résultats, la structure d'accueil est prête ...

Résultats en lecture, tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33. 
Dualcore

De grosses différences se manifestent, d'une part dans les "petits" fichiers où la taille du cache du disque semble prépondérante, le noyau 2.6.33 donne de superbes résultats sur le disque "classique" pour les petites tailles de fichiers, le SSD l'emporte dès que la taille des fichiers augmente. Le noyau 2.6.33 semble "brider" la performance du SSD. 
Remarque : le SSD semble plus beaucoup plus sensible à la taille des enregistrements, il prend l'avantage dès que la taille des enregistrements dépasse 128 octets. 

Quadcore :

La forme des courbes est beaucoup plus régulière que sur le dualcore, le SSD prends l'avantage dès les petites valeurs d'enregistrements et accentue son avance lorsque l'enregistrement s'allonge. 
La vitesse maxi du SSD est moindre que pour le dualcore, ce qui semble normal au vu des types de disques. La courbe des disques SATA est plus régulière et plus "pentue" que pour le dualcore, est-ce une influence de la taille de cache beaucoup plus réduite. 

Conclusion : avantage au SSD dès que la longueur des enregistrements dépasse 32, l'avantage s’accroît avec la taille des fichiers et celle des enregistrements.

Résultats en lecture "random", tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33. 
Dualcore

Les résultats sont bien ceux attendus, le SSD gagne haut la main. Le fait de ne pas avoir de délai rotationnel ni de temps de déplacement des têtes permet au SSD de dominer très largement dès que l'on sort un peu des caches (au delà de 32Mo). Le noyau 2.6.33 semble exploiter mieux les caches du disque "classique" pour les petits fichiers ( < taille du cache) où la vitesse atteint des sommets impressionnants. 

Quadcore :

Les caches plus petits des disques classiques donnent un aspect beaucoup plus "lisse" aux graphes, le SSD gagne là aussi haut la main quel que soit le noyau. Les résultats sont équivalents pour les deux noyaux testés. 

Conclusion : les disques SSD gagnent logiquement ce match, les délais (rotationnels et piste à piste) sont ici très défavorables qux disques "classiques".

Résultats en écriture, tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33. 
Dualcore

Des résultats curieux, l'avantage reste au SSD mais le noyau 2.6.33 donne de très bonnes performances au disque "classique" en exploitant beaucoup mieux les caches (très visible sur les petites tailles de fichiers) alors qu'avec le 2.6.31 les résultats sont très faibles pour le disque "classique" sans aucune explication évidente. 

Quadcore :

Là c'est spécial, le SSD est très lent (!), alors que le SATA se comporte beaucoup mieux. Aucune explication évidente à part les contrôleurs disques et les drivers associés ou encore ce disque SSD pas bon en écriture ? 

Conclusion : sur ce test une des deux machines donne un résultat contraire à la logique et franchement surprenant sans explication évidente. A ce sujet voir l'article sur le TRIM.

Résultats en écriture "random", tous les résultats sont donnés pour les deux versions de noyau choisies 2.6.31 et 2.6.33. 
Dualcore :

Les résultats sont "logiques" et montrent un net avantage au SSD qui tire avantage de sa structure "statique". Les caches permettent qu disque "classique" de faire illusion sur les fichiers de petite taille ( < taille du cache). 

Quadcore :

Même résultats "illogiques", le disque "classique" l'emporte sur le SSD dans la plupart des configurations sans aucune explication évidente. 

Conclusion : sur le dualcore le SSD l'emporte de manière évidente, sur le quadcore il se passe quelque chose de très défavorable au SSD et les résultats du disque "classique" ne sont même pas bons. Une vérification s'impose au niveau du paramétrage de chaque système. Voir à ce sujet l'article sur le TRIM.

Ayant passé quelques heures à rechercher les "bons" paramètres pour gnuplot je ne résiste pas et vous livre le script qui permet de réaliser ces beaux dessins :

set terminal png size 600,800 
# Paramètres 
# X = COL 1 (taille fichier) 
set xrange [4096:1200000] 
set logscale x 
set xtics ("4M" 4096,"8M" 8192,"16M" 16384,"32M" 32768,"64M" 65536,"128M" 131072,"256M" 262144,"512M" 524288,"1G" 1048576," " 1200000) 

# Y = COL 2 (taille record) 
set yrange [16:512]; 
set logscale y 
set ytics  (16,32,64,128,256,512) 

# Z = valeur (affichée en "vertical") 
set zrange [1000:45000] 
set ztics 4500 

set grid xtics ytics ztics 

set title "Graphe pour write  QUAD 2.6.33" 

# rotation de l'image 
# Paramètres  1 = haut bas, 2 = rotation "verticale", 3 = scale x, 4 = scale Y 
set view 82,30,1,1 
show view; 

# paramètres des graphes 
# pas toujours beau de cacher 
# set hidden3d 

set ticslevel 0 

# Dessin de la courbe 
set output './GR3D_write.png' 

# Les valeurs sont 1      2      3 
#                  Horiz  Prof   Vert 
# --> seule la colonne 3 change 

splot './GR3D_SATA.data' using 1:2:3 with linespoints title "Sata" ,\ 
      './GR3D_SSD.data' using 1:2:3 with linespoints title "SSD" 

Les données issues de IOZONE se présentent sous la forme suivante : 
4096      16    5186   16680    14973    16750   43991   19815   17172    35960    16189   271512   637599 
41750  1252212 
8192      16    1434    9323    28470    30851   49824   11009   12213    22726    23055   261390   647544 
1321294  1332670 
16384      16    2342    8505    34228    44150   49955    5517   23756    28867    29089   266250   645243 1329232  1349806 
32768      16    1910    7892    46899    52612   49608    5493   31623    48795    40638   262227   637958 1308162  1318313 
65536      16    1901   15269    57790    59384   50686    5318   38498    38474    45373   262871   636297 1325699  1338611 
131072      16    2056   13492    50604    63858   50527    5627   46133    40310    48394   259907   629282 
1303419  1313993 
262144      16    2109   15342    56704    68718   48837    6939   49306    30937    49158   261380   648884 1312499  1319461 
524288      16    2210   14232    67886    68860   49550    6104   49283    48960    49798   249599   626107  423431  1334324 

Pour chaque longueur d'enregistrement. L'association du script et des données (pour toutes les longueurs d'enregistrement donne les jolis dessins suivants:

• En "horizontal" la taille de fichier (4M à 1024M)
• En "profondeur" la taille d'enregistrement (16 à 512)
• En "hauteur" la valeur de la donnée en KO/seconde

C'est y pas beau ?