Comparatif SSD : 28 SSD de 480 à 512 Go

Tenue des performances

Nous l'avons déjà évoqué à multiples reprises, notamment dans notre dernier comparatif de SSD 120 à 128 Go, les performances d'un SSD peuvent se dégrader au fur et à mesure de son utilisation.

A ceci plusieurs causes, la première est structurelle : un disque dur peut lire, écrire (une zone vierge) ou réécrire (une zone occupée) les données par paquet de 4 Ko. Avec la flash, on ne lit, écrit ou réécrit que par paquet de 4 Ko, 4 Ko et … 512 Ko puisque si l'écriture ou la lecture peut se faire par page, la réécriture doit se faire sur un même ensemble de pages appelé bloc. On grimpe même à 8 Ko, 8 Ko et 2048 Ko pour les puces 64 Gb 25nm de 8 Go et 16 Ko, 16 Ko et 4096 Ko pour les futures puces 128 Gb 20nm.

Quand il faut réécrire une zone déjà occupée par un fichier, cela pose donc quelques problèmes de performances et d'usure de la flash ! Pire, si le fichier a été effacé par l'OS sans TRIM, alors le SSD ne sait pas que les données qui correspondaient à ce fichier sont invalides et fera une opération de réécriture (read-modify-write) au lieu d'une écriture simple. Avec la commande TRIM, cet écueil est toutefois résolu puisque l'OS indique au SSD que la zone est de nouveau à considérer comme vierge.

Ce comportement structurel est accentué par la présence d'optimisations au sein des SSD visant à améliorer les performances en écritures aléatoires et l'amplification en écriture. Pour faire simple, lorsqu'on demande d'écrire de manière aléatoire des données à un SSD, celui-ci les écrits en séquentiel au niveau de la Flash, s'arrangeant au niveau de sa table d'allocation interne pour faire correspondre les adresses connues par l'OS (les LBA) et les pages Flash correspondantes. Pour qu'un tel mécanisme soit efficace, il faut toutefois que des blocs de mémoire Flash soient disponibles, ce qui est plus délicat en l'absence de TRIM.

Tous les SSD disposent d'un surplus de Flash, assez restreint de base : ainsi un SSD affichant une capacité de 128 Go (ou 119,2 Gio) intègre plus précisément 137,4 Go de Flash. Ces 6,8% de la Flash non accessibles pour stocker des données utilisateurs sont donc considérés comme libre par le contrôleur, qui peu au fil du temps consolider cet espace (c'est le Garbage Collection) afin de disposer de blocs entiers vierges de donnés.

Certains SSD vont plus loin et ajoutent ce qu'on appelle un overprovisionning, c'est-à-dire une provision supplémentaire de Flash. Ainsi les SSD affichant des capacités de 120 Go ou 480 Go ont autant de Flash que les 128 Go ou 512 Go, mais tout ou partie de la différence est réservée à cet usage. Dans le meilleur des cas c'est donc 12,6% du stock de Flash qui sera disponible.

Les SSD professionnels vont plus loin, avec par exemple une capacité disponible non plus de 480 mais de 400 Go. On passe alors à 27,2%, de quoi disposer d'encore plus de mémoire Flash additionnelle. Avec le TRIM, la situation sera identique si vous avez un SSD de 512 Go avec un remplissage maximal de 400 Go.

Attention par contre, sans TRIM même si vous maintenez de l'espace libre sur le SSD, celui-ci ne sera pas considéré comme libre par le contrôleur dès lors que les LBA correspondantes à l'espace libre ont été écrites dans le passé. Dans ces conditions le plus sûr est simplement de ne pas partitionner l'intégralité du SSD, du coup les LBA resteront vierge de données dans tous les cas : il est ainsi possible avec un SSD grand public de 512 Go d'avoir autant d'overprovisionning que sur un SSD professionnel.

On notera ici que les SSD à base de SandForce disposent d'un léger avantage, puisque si vous avez 500 Go de données qu'il peut compresser pour qu'elle n'occupe que 400 Go de Flash, ce qui peut être le cas par exemple avec une grosse base de donnée, vous aurez 100 Go de mémoire Flash supplémentaire pour les optimisations du contrôleur sans que votre capacité accessible soit diminuée.

Pour le test de tenue de performances nous avons placé les SSD dans des conditions extrêmes, puisque nous remplissons la partition de données incompressibles avant d'effectuer via IOMeter des 32 écritures simultanées aléatoires de 4 Ko, ce pendant 100 minutes. Aucune commande TRIM n'est effectuée pendant le test, le contrôleur ne peut donc que compter sur lui-même. Ce test est effectué sur des partitions de diverses tailles sur chaque SSD :

- 512 ou 500 Go pour les SSD offrant une capacité supérieure à 480 Go
- 480 Go
- 400 Go

Généralement en tout début de test les performances sont encore à un niveau élevé, puisqu'on tape dans le surplus de Flash, mais les performances s'effondrent rapidement pour plus ou moins ce stabiliser à un niveau bien inférieur.

[ Corsair Force GS ]  [ Neutron GTX ]  [ Force LX ]  
[ Crucial M4 ]  [ M500 ]  [ M550 ]  [ MX100 ]  [ BX100 ]  [ MX200 ]  
[ Intel SSD 520 ]  [ SSD 730 ]  
[ Kingston HyperX 3K ]  
[ OCZ Vector ]  [ Vertex 450 ]  [ Vector 180 ]  [ Arc 100 ]  
[ Plextor M5Pro Xtreme ]  
[ Samsung 840 ]  [ 840 EVO ]  [ 840 Pro ]  [ 850 EVO ]  [ 850 Pro ]  
[ Sandisk Extreme ]  [ Extreme II ]  [ Sandisk Extreme Pro ]  [ Ultra II ]  
[ Seagate 600 ]  [ Toshiba HG6 ]  


Dès le début du test après une longue écriture séquentielle, certains SSD affichent en écriture aléatoire 4K QD32 des performances inférieures à celles mesurées dans les tests classiques. Ainsi les Corsair Force GS, Intel SSD 520, Kingston HyperX 3K et Sandisk Extreme sont nettement en dessous des 30K, 37K, 24K et 22K IOPS qu'ils obtenaient précédemment. Tous ces SSD sont à base de SandForce et c'est l'HyperX 3K qui est le plus en retrait avec "seulement" 11K IOPS environ (mais c'est quand même 110x ce que peut faire un disque dur !).

Deux autre SSD ont un comportement étrange, il s'agit des Sandisk Extreme II et Extreme Pro qui contrairement aux autres SSD sont plus lent durant la première minute de test qu'ensuite. Avec 20K IOPS ils sont ainsi nettement en dessous du niveau de 35-38KK IOPS atteint dans les tests classiques, mais ils retrouvent ce niveau juste après en "480 Go" et va même au-delà en "400 Go".

Ce qui nous intéresse le plus ici est de savoir à quels niveaux les meilleurs SSD arrivent à se stabiliser. C'est comme attendu assez variable en fonction du volume de Flash utilisé pour le test, voici un tableau récapitulant la moyenne obtenue sur les 30 dernières minutes :



Première chose, tous les SSD à base de SandForce sont à des niveaux assez bas. Ainsi même lorsqu'ils disposent de plus de Flash libre, en mode "400 Go", leurs performances restent inférieures à celles de certains SSD pour lesquels on utilise 512 Go. Avec les 480 Go d'utilisés sur les SandForce c'est bien entendu pire, avec 1,6K dans le pire des cas (Kingston HyperX 3K) et 2,8K dans le meilleur des cas (Sandisk Extreme). Heureusement pour les SandForce généralement une partie des données stockées sont compressibles, ce qui n'est pas le cas ici, ce qui leur permettra d'être dans une situation plus avantageuse.

Avec 512 Go d'utilisés c'est le 850 Pro qui s'avère le plus véloce avec tout de même 8,3K IOPS soutenues. Par contre avec 480 Go ce sont cette fois les OCZ Vector 180 et ARC 100 qui sont en tête avec respectivement 22K et 19K IOPS. Si on va plus loin et qu'on se limite à 400 Go le 850 Pro prend le large avec 44K IOPS.

Le niveau 500 Go n'a été testé que sur les SSD offrant une telle capacité utilisable maximale, c'est le MX200 qui s'en sort le mieux à ce niveau, profitant par rapport au MX100 512 Go d'une plus grande réserve de Flash.

Mais sans maîtrise, la puissance n'est rien. C'est pourquoi nous avons enregistré et représenté graphiquement, pour chaque minute de test, le délai maximal enregistré pour une opération d'écriture aléatoire. En effet c'est bien d'atteindre 10K IOPS, soit une moyenne de 0,1ms par accès, mais ce niveau de performance est gâché si par moment de rares accès nécessitent 1000ms (soit 1s) pour être exécutés ! Ce qui vous allez le voir peut arriver dans ces situations assez stressantes pour le contrôleur, si bien que nous avons du opter pour une échelle logarithmique pour l'axe des ordonnées :

[ Corsair Force GS ]  [ Neutron GTX ]  [ Force LX ]  
[ Crucial M4 ]  [ M500 ]  [ M550 ]  [ MX100 ]  [ BX100 ]  [ MX200 ]  
[ Intel SSD 520 ]  [ SSD 730 ]  
[ Kingston HyperX 3K ]  
[ OCZ Vector ]  [ Vertex 450 ]  [ Vector 180 ]  [ Arc 100 ]  
[ Plextor M5Pro Xtreme ]  
[ Samsung 840 ]  [ 840 EVO ]  [ 840 Pro ]  [ 850 EVO ]  [ 850 Pro ]  
[ Sandisk Extreme ]  [ Extreme II ]  [ Sandisk Extreme Pro ]  [ Ultra II ]  
[ Seagate 600 ]  [ Toshiba HG6 ]  

On commence par les mauvais élèves que sont le Crucial M4 et le Plextor M5Pro Xtreme. En effet, si en tout début de test quand il n'y a pas besoin de réorganiser la Flash on est à de bons niveaux, moins de 10ms pour la latence maximale observée, dès que c'est le cas et quelle que soit la capacité de Flash utilisée pour le test on atteint des latences maximales élevées, supérieures à la seconde. Les derniers OCZ Vector 180 et Arc 100 ne sont également pas à l'aise avec plus d'une seconde latence maximale, même en début de test, une régression par rapport à leurs prédécesseurs qui n'étaient pas très à l'aise non plus. Un point problématique pour OCZ qui met en avant les performances de ces SSD en aléatoire en l'absence de TRIM : c'est vrai pour les IOPS comme vu précédemment mais côté latence maximale ce n'est donc aussi rose.

Le Samsung 840 Pro, lorsque les 512 Go sont utilisés, affiche également des latences élevées mais contrairement aux SSD précités il en est exempt si on se limite à 400 Go. D'autres SSD ont parfois de rares latences supérieures à 1000ms : Corsair Neutron GTX, Kingston HyperX 3K, Sandisk Extreme et Seagate 600. C'est par contre assez rare, voire anecdotique sauf pour le SSD Kingston ou elles sont assez regroupées (nous avons fait le test deux fois pour vérifier si il n'y avait pas un souci externe au SSD).

Les Corsair Force GS, Crucial M500/M550/MX100/MX200/BX100 (en nette amélioration par rapport au M4 de ce côté, même si le MX200 fait moins bien que le MX100), Intel SSD 520, SSD 730, Samsung 840/840 EVO/850 Pro/850 EVO, Sandisk Extreme II/ Extreme Pro/Ultra II et Toshiba HG6 sont pour leur part complètement exempts de latences supérieures à 1000ms durant l'intégralité des tests.

Pour plus de simplicité nous avons représenté sous forme graphique, et sans échelle logarithmique cette fois, la moyenne de la latence maximale observée par minute durant les 30 dernières minutes :



C'est le Samsung 850 Pro qui l'emporte d'une courte tête, avec 8 et 5ms contre 12 et 9ms pour l'Intel SSD 730. Le Crucial MX100 n'est pas si éloigné avec 21 à 27ms selon la capacité utile, et on retrouve juste derrière le Samsung 850 EVO et 840 EVO, les Crucial M550 et M500 ainsi que les deux SSD à base de contrôleur LAMD, les Corsair Neutron GTX et Seagate 600.
Dans les mauvais élèves on retrouve les Plextor M5Pro Xtreme, Crucial M4, OCZ Vector 180 et Arc 100 précédemment cités, ainsi que le Samsung 840 Pro lorsque toute sa capacité est utilisée pendant ce stress-test.

A la sortie de ce test pour le moins extrême, il nous fait préciser qu'en usage classique les SSD ne seront pas soumis à de telles conditions. Il est néanmoins intéressant de voir leur comportement dans ce type de test, car qui peut le plus, peut le moins.