Comparatif SSD 2012-2013 : 37 SSD SATA 6G 120 et 128 Go
Indilinx Everest 2 et débits : attention !Les contrôleurs SandForce ne sont pas les seuls SSD à avoir un comportement qui sort des clous. En effet, l'Indilinx Everest 2 avec ses derniers firmware et le Barefoot 3 intègrent un algorithme permettant dans certains cas de maximiser les performances en écriture.
Cette fois le phénomène n'a rien à voir avec le type de donnée que l'on écrit mais plutôt la manière dont le contrôleur va répartir les données au sein de chaque cellule Flash. OCZ est avare en détails sur cette technologie, nos questions s'approchant trop des limites de leur propriété intellectuelle. Soit ! Il ne nous reste plus que la méthode empirique pour essayer de comprendre ce qui se passe.
Voici comment réagissent quatre SSD à deux écritures complètes, successives et continues de l'espace disponible pour l'utilisateur, à savoir le Plextor M5P qui fait office ici d'étalon et qui se comporte comme un SSD classique ainsi que les OCZ Vector, Vector 150, Vertex 450, Vertex 4 et Agility 4.
1ère passe : [ Plextor M5P ] [ Vector ] [ Vector 150 ] [ Vertex 450 ] [ Vertex 4 ] [ Agility 4 ]
2ème passe : [ Plextor M5P ] [ Vector ] [ Vector 150 ] [ Vertex 450 ] [ Vertex 4 ] [ Agility 4 ]
Sur le M5P, le débit est stable tout au long de l'écriture, et équivalent entre la première et la seconde passe. Sur les SSD OCZ c'est loin d'être le cas puisque sur environ la moitié de l'espace disponible on obtient d'excellentes performances, de 400 Mo /s sur le Vector 150 à 260 Mo /s sur l'Agility 4, alors que sur l'autre moitié ces débits sont divisés par 4 ! Sur la seconde passe (sans TRIM dans l'intervalle) les débits sont assez stables, variant entre 157 Mo /s et 201 Mo /s selon le modèle. On notera que la vitesse d'écriture sur le Vertex 4 correspond à celle qui était obtenue avec les premiers firmware.
Quelle est donc la nouveauté qui a été introduite par OCZ ? Il convient avant toute chose de rappeler qu'une mémoire flash est composée de transistors possédant une grille flottante. Pour stocker un bit on piège plus ou moins d'électrons dans cette grille par effet de tunnel. Dans le cas d'une mémoire SLC on ne stocke qu'un bit par transistors, seuls deux niveaux de charge sont nécessaires et ils se programment assez rapidement. On stocke par contre deux bits par transistor au sein de la mémoire MLC, ce qui correspond à 4 niveaux de charge. La programmation du bon niveau de charge doit être plus précise et elle nécessite alors plus de passes, moins puissantes et plus longues, ce qui prend plus de temps.
Au sein d'une cellule MLC il sera donc plus rapide d'écrire le premier bit que le second, et comme expliqué dans l'article, Characterizing Flash Memory: Anomalies, Observations, and Applications , les fabricants de Flash organisent les pages de la Flash de manière à avoir des pages qui ne correspondent qu'au premier bit, et d'autres qu'au second bit. Les premières sont donc nettement plus rapides que les secondes.
L'astuce utilisée ici par OCZ sur les Vertex 4 et Agility 4 est d'utiliser prioritairement les pages les plus rapides au sein des cellules, ce qui correspond à ce servir de la MLC comme si il s'agissait de … SLC ! Mais après avoir écrit la moitié de la Flash disponible, il ne reste par contre plus que des pages Flash lentes correspond aux seconds bits à disposition, d'où l'effondrement du débit.
Il ne s'agit pas d'un point de non-retour puisque le firmware profitera de toute période de repos du SSD pour libérer un maximum de pages "SLC". Les données écrites exclusivement au sein de pages "SLC" seront alors réécrites de manière classique sur la Flash, ce qui libérera l'équivalent de la moitié de l'espace Flash disponible pour de nouvelles écritures en mode "SLC". Attention, pour que l'espace Flash disponible corresponde à l'espace disque disponible, il faut pour rappel disposer du TRIM.
Pour illustrer ce phénomène nous écrivons 64 Go de données sur le Vertex 4 et le Vector, effectuons une pause de 1, 5 ou 10 minutes puis écrivons de nouveau de manière séquentielle sur les derniers 64 Go disponibles. Les performances lors de cette phase d'écriture sont observées sous l'Analyseur de performances Windows.
Débit en écriture (en Dizaines de Mo /s) après une écriture de 64 Go et une pause de :
Vertex 4 : [ 1 minute ] [ 5 minutes ] [ 10 minutes ]
Vector : [ 1 minute ] [ 5 minutes ] [ 10 minutes ]
Comme vous pouvez le voir, plus on laisse de temps disponible au SSD, plus il peut consolider les 64 Go écrits précédemment de manière à libérer des pages "SLC" pour les futures écritures. Elle se fait selon nos estimations à environ 200 Mo /s, ce qui correspond à l'écriture en mode standard du Vertex 4. Durant cette période le Vertex 4 consomme environ 3 watts ce qui correspond à sa consommation en écriture classique, alors qu'un autre SSD serait au repos. Sur le Vector, l'algorithme semble moins agressif et le contrôleur ne cherche pas à libérer autant de page "SLC" que possible comme c'est le cas sur le Vertex 4 : il en a moins libéré après 5 minutes, et n'en libère pas plus après 5 minutes de repos supplémentaire. De plus si sur le Vertex 4 nous avons pu voir que ce mécanisme s'enclenchait même si on écrivait ne serait que 8 Go sur un SSD neuf, sur le Vector il ne se produit qu'une fois qu'on a écrit un volume plus important de donnée - 40 à 50 Go environ.
Cette technique n'est pas sans conséquence sur l'amplification en écriture et l'usure des cellules Flash. OCZ se gardant de donner des détails, on ne peut faire que des suppositions sur l'amplification en écriture qui en découle. On peut ainsi penser que pour une écriture de 10 Go le SSD va écrire ses 10 Go sur des pages "SLC", puis de réécrire ses 10 Go de manière classique. Cela entraîne donc 20 Go d'écritures, dont 15 sur des pages "SLC", et 10 Go de pages SLC qui seront donc à effacer (contre 10, 5 et 0 sur un autre SSD). Il serait éventuellement possible de réduire cette amplification au dépends d'une fragmentation importante des données, en ne réécrivant que les derniers 5 Go dans les pages correspondant au second bit des cellules encore libres dans les blocs contenant déjà les pages "SLC" utilisés par les 5 premiers Go, mais cela parait peu probable.
Et la lecture ?Quid de l'impact sur la lecture ? On commence par HD Tune dans lequel nous lisons tout le contenu du SSD après qu'il ait été écrit une première fois, puis après qu'il ait été écrit une seconde fois. Une nouvelle fois le Plextor M5P fait ici office d'étalon.
1ère passe : [ Plextor M5P ] [ Vector ] [ Vector 150 ] [ Vertex 450 ] [ Vertex 4 ] [ Agility 4 ]
2ème passe : [ Plextor M5P ] [ Vector ] [ Vector 150 ] [ Vertex 450 ] [ Vertex 4 ] [ Agility 4 ]
Comme attendu, sur le Plextor M5P le débit est stable tout au long de la lecture, et équivalent entre la lecture des deux passes d'écritures. Sur les OCZ c'est bien différent ! Sur la 1ère passe, on peut voir que les données écrites sur les pages "SLC" sont lues assez rapidement, avec des pics sur l'Agility 4 sur lesquels nous reviendront ultérieurement. Mais quand on lit les données écrites sur des pages lentes, les performances baissent : on passe de 480 à 370 Mo /s sur le Vector, 480 à 400 Mo /s sur le Vector 150, 450 à 325 Mo /s sur le Vertex 450, de 400 à 300 Mo /s sur le Vertex 4 et de 250-300 Mo /s à moins de 150 Mo /s sur l'Agility 4 ! Lire les données écrites à l'occasion de la seconde passe laisse par contre transparaître un débit stable et au niveau le plus élevé sur l'intégralité du SSD, exception faite des pics.
Revenons sur les pics maintenant observés notamment sur l'Agility 4. Ce SSD est annoncé pour atteindre un débit de 420 Mo /s en lecture, ce qui est particulièrement élevé pour un SSD affublé de mémoire asynchrone. Dans nos tests habituels, vous verrez plus loin dans ce dossier qu'il ne nous a jamais été possible de passer ne serait-ce que la barre des 300 Mo /s. OCZ annonce que ce chiffre est obtenu sous le logiciel de test ATTO, voici les performances que nous avons obtenues :
Effectivement, sur un test complet on atteint les 420 Mo /s dès lors que les accès font au moins une taille de 256 Ko. Si ensuite on relance un test en commençant à partir de cette valeur, il faut par contre attendre les accès de 2048 Ko pour atteindre ce débit. Et si on relance en commençant à cette nouvelle valeur, les 420 Mo /s ne sont atteint qu'avec les accès de 8192 Ko. Un comportement on ne peut plus étrange !
Sous HD Tune, si on ne mesure la vitesse en lecture que sur les 10 premiers Go sur un SSD rempli de données, on obtient ces résultats :
[ Plextor M5P ] [ OCZ Vector ] [ OCZ Vertex 4 ] [ OCZ Agility 4 ]
Sur le M5P mais aussi sur le Vector, la courbe est stable, alors qu'elle est instable sur le Vertex 4 et surtout sur l'Agility 4.
Débit en lecture (en Dizaines de Mo /s) après une écriture de 40 Go :
[ 1er essai ] [ 2ème essai ]
Autre test, si on écrit séquentiellement 40 Go de données sur l'Agility 4 à l'aide d'IOMETER, la lecture de ces 40 Go à de multiples reprises montre également des variations qui ne ressemblent pas à celles observées sous HD Tune : il y a bien des pics vers le haut à environ 400 Mo /s (contre 260 Mo /s normalement) mais ils sont plus espacés et plus long. On observe les mêmes pics à chaque relecture de la zone, même après avoir laissé le SSD au repos le temps qu'il réécrive les données de manière à libérer des pages "SLC". Si on efface complètement le SSD (Secure Erase) puis on réécrit et relit de nouveau 40 Go, on observe le même type de pics, mais ils ne sont pas placés de la même manière.
Enfin, à titre d'information la lecture d'une zone vierge du SSD avec IOMETER nous permet d'obtenir de manière continue le débit de 400 Mo /s. Malgré de nombreux essais nous n'avons toutefois pas été en mesure de comprendre quelles étaient les conditions nécessaires à l'obtention d'un tel débit sur une zone utilisée.
Au finalComme pour les SSD à base de SandForce, il ne faut pas prendre pour argent comptant tous les débits annoncés pour les SSD à base d'Indilinx Everest 2 et Barefoot 3.
En écriture tout d'abord, le mécanisme mis en place par OCZ pour obtenir les meilleures performances possibles fait que le débit ne peut pas être maintenu dans tous les cas de figure. Néanmoins, en utilisation classique et avec le TRIM, on devrait pouvoir en profiter, avec une réserve sur l'augmentation de l'amplification en écriture qui en découle. Le jeu en vaut-il la chandelle ? Pas forcément puisque justement en usage classique un débit si important en écriture ne sera pas très utile.
En lecture ensuite, il est en pratique très peu probable d'atteindre le niveau annoncé par OCZ en dehors d'un test synthétique tel que ATTO, sans que nous ayons pu identifier la cause de ce grand écart côté débit, sur les SSD équipés de l'Everest 2 et plus particulièrement l'Agility 4. Même si là encore en usage classique cela ne fait pas grande différence, les acheteurs utilisent tout de même ces données pour départager plusieurs SSD lors de leur achat. Dès lors leur inexactitude pose problème et on est à la limite de la publicité mensongère. Bonne nouvelle toutefois, l'OCZ Vector ne souffre pas de ce problème en lecture.
Enfin sachez que le mode "Performance" de l'Indilinx Everest 2 ne fonctionne pas exactement de la même manière en fonction de la capacité. Si les 128 Go d'un Vertex 4 128 Go sont destinés à être utilisés dans ce mode, ce qui entraîne en cas d'une écriture complète un débit maximal sur 64 Go et minimal sur 64 Go, sur un 256 Go ce sont également 128 Go qui sont utilisés dans ce mode. Lors d'une écriture complète on est pendant 64 Go à vitesse maximale, puis 128 Go à vitesse classique et enfin 64 Go à vitesse minimale. A contrario sur le Vector on observe le même comportement que ce soit en version 128 ou 256 Go. Bonne nouvelle par contre, ce mode "SLC" n'est pas utilisé sur les versions 512 Go.
2 - Optimiser son SSD
3 - Les contrôleurs et la Flash MLC et TLC
4 - SandForce, compression et débits : attention !
5 - OCZ Indilinx Everest 2 / Barefoot 3 et débits : attention !
6 - Samsung 840 EVO, TurboWrite et débits : attention !
7 - Toshiba Q Series et débits : attention !
8 - Capacité, overprovisioning et Garbage collector
9 - Corsair Force 3, Force GT et Force GS en test
10 - Corsair Performance Pro en test
11 - Corsair Neutron GTX et Neutron en test
12 - Crucial M500, M4 et C300 en test
13 - Intel SSD 520, 330 et 510 en test
14 - Kingston V200 et V300 en test
15 - OCZ Vertex 3.20 et Max IOPS en test
17 - OCZ Vector, Vector 150 et Vertex 450 en test
18 - Plextor M5 Pro, Plextor M3 Pro, M5S et M3 en test
19 - Samsung 840 Pro, 840 EVO, 840 et 830 en test
20 - Sandisk Extreme II, Ultra Plus, Extreme et SSD en test
21 - Toshiba THNSNHxxxGCST / Q Series en test
22 - Protocole de test
23 - Débits séquentiels
24 - Lectures aléatoire
25 - Ecritures aléatoires
26 - Lecture et écriture de fichiers
27 - Tests pratiques
28 - Tenue des performances et TRIM
29 - Consommation et efficacité énergétique
30 - Conclusion
Contenus relatifs
- [+] 31/07: Un bug de TRIM sous Linux pour les ...
- [+] 27/05: Comparatif SSD : 28 SSD de 480 à 51...
- [+] 24/04: Samsung Magician 4.6 et firmware 84...
- [+] 17/04: Fix 840 EVO en approche, 840 abando...
- [+] 13/03: Test d'endurance SSD, clap de fin à...
- [+] 21/02: Samsung 840 EVO : correctif en mars...
- [+] 27/01: Bug des Samsung 840 EVO, le retour
- [+] 05/12: Test d'endurance de SSD, le point à...
- [+] 30/10: Samsung reconnait un problème pour ...
- [+] 15/10: Le Samsung 840 EVO corrigé, pas le ...