Comparatif SSD 2012-2013 : 37 SSD SATA 6G 120 et 128 Go

SandForce et compression : attention !

Les contrôleurs SandForce sont les seuls à intégrer un algorithme de compression en temps réel. Basique, il permet de minimiser l'impact de certaines écritures sur la Flash, SandForce mettant par exemple en avant que les installations de Windows Vista et d'Office nécessitent 25 Go d'écritures sur le SSD qui sont réduites à 11 Go seulement par leur algorithme.

L'intérêt est double, puisque d'une part on "use" moins la Flash, bien que ceci ne soit pas encore un problème vu les endurances actuelles des puces, mais d'autre part on dispose forcément d'un volume de cellules vierges plus importante que sur un autre SSD, ce qui n'est pas négligeable comme vous pourrez le voir en page suivante.


Les "spécifications" du Corsair Force 3 sont illusoires côté débit
Le gros défaut de cette technologie et qu'elle complètement détournée par le marketing. En effet la plupart des benchmarks pour disques se contentent d'écrire des suites de 0 ou de 1, ce qui permet à l'algorithme d'être dans un cas optimal et d'afficher des taux de compression de l'ordre de 7 pour 1 alors que quand tout va bien comme dans l'exemple de SandForce on est plutôt à 2 pour 1 et qu'avec des fichiers déjà compressés un minimum (fichiers JPEG, MPEG3 ou MPEG4 par exemple) l'algorithme n'est tout simplement plus fonctionnel.


Même chose chez Kingston pour le V+200
Cela ne fait pas peur aux fabricants de SSD qui mettent fortement en avant les valeurs obtenues dans ces cas irréalistes ou la compression atteint son paroxysme. On peut par exemple voir des SSD tel que le Corsair Force 3 60 Go annoncés à des débits de 540 Mo /s en lecture et 490 Mo /s en écriture. Seul problème, en pratique on en est bien loin et OCZ qui dispose d'un modèle similaire, l'Agility 3, annonce pour sa part 525/475 Mo /s dans ce cas mais aussi 180 Mo /s en lecture et 65 Mo /s en écriture lorsque l'algorithme n'est pas fonctionnel. Plus réalistes, ces chiffres sont clairement moins vendeurs et peu souvent mis en avant, ne vous fiez donc pas forcément aux fiches techniques !




OCZ est plus honnête, mais il faut passer par le datasheet, la fiche produit initial ne fait pas mention du grand écart !
Il est assez simple de calculer le taux de compression réel obtenu par une puce SandForce puisque les informations SMART permettent d'avoir accès au volume d'écriture demandé par l'OS et à celui réellement écrit sur la Flash. On peut en déduire ce qu'on appelle l'amplification d'écriture, c'est-à-dire le ratio entre ce qui est écrit en NAND et ce qui est demandé par le système hôte, un phénomène que tous les contrôleurs cherchent à rapprocher de 1. SandForce avec son algorithme de compression est le seul qui peut amener ce ratio en dessous de 1 dans certains cas :

- Benchmark d'écriture séquentielle incompressible : 1.09
- Benchmark d'écriture séquentielle compressible : 0.15
- Copie d'une image de Windows 7 + 3d Studio Max 2011 + Visual Studio 2011 + Bibble 5 Pro + BattleField 3 : 0.76

En écriture séquentielle incompressible, on obtient une amplification d'écriture légèrement supérieure à 1, ce qui est parfaitement normal puisque la compression ne fonctionne pas. Avec un benchmark compressible, là c'est carrément un facteur de 0.15 qui est obtenu (1.5 Go écrits en Flash pour 10 Go d'écritures demandées par le système hôte), ce qui est complètement irréaliste ! Si on copie notre image système de test, les 42 Go n'occupent que 32 Go, une économie de flash de 10 Go qui n'est pas négligeable. Il faut toutefois préciser que sur ses 42 Go, 1 Go sont en fait réservés par pagefile.sys qui est vide et donc très fortement compressible. L'image intègre également 1.55 Go pour le code source pour Visual Studio 2011 et 1.25 Go de photos JPEG pour Bibble 5 Pro.

Du coup, entre les mesures compressibles et incompressibles, c'est le grand écart en écriture mais aussi en lecture sur certains SSD. Voyons ce qui se passe sur quelques SSD lorsqu'on lit les données. On distingue trois zones sur ces screenshots :

- A : correspond à l'image système précédemment décrite
- B : correspond à un fichier de 4 Go très compressible puis un fichier de 4 Go incompressible crées via IOMeter
- C : correspond à la zone vierge de donnée du SSD

[ Corsair Force 3 ]  [ Corsair Force GT ]  [ Crucial M4 ]

Sur la zone vierge du Corsair Force 3, un SSD SandForce associé à de la mémoire asynchrone, on est maximum théorique avec près de 510 Mo /s. Mais en pratique sur la partition de données on en est loin puisqu'on atteint seulement 272.5 Mo /s en moyenne sur cette zone, avec un minimum à 187 Mo /s et un maximum à 509 Mo /s qui correspond entre autre à la zone occupée par pagefile.sys. Sur le fichier de test compressible on est à 425 Mo /s environ, et à 190 Mo /s sur le fichier incompressible.

Sur un Corsair Force GT qui est cette fois associé à de la mémoire synchrone l'impact est bien plus faible dans le domaine de la lecture puisque la moyenne sur la partition de données est de 445,2 Mo /s, avec des variations entre 411 et 512 Mo /s. Enfin sur le Crucial M4 qui n'utilise pas d'algorithme de compression les débits ne varient quasiment pas : 490,6 Mo /s en moyenne sur la partition de données, contre 511.8 Mo /s au maximum sur la zone vierge.

Afin de ne pas de ne pas rentrer dans le jeu du marketing des constructeurs de SSD utilisant un contrôleur SandForce, tous les tests de performances synthétiques effectués sur les SSD intégrés à ce comparatif seront effectués avec des données incompressibles.