Comparatif SSD 2012-2013 : 37 SSD SATA 6G 120 et 128 Go
Publié le 13/04/2012 (Mise à jour le 15/11/2013) par Marc Prieur
Capacité : Go et GioTout comme sur les disques durs, la capacité utile des SSD reste un grand mystère pour de nombreux utilisateurs sous Windows pour la simple et bonne raison que les méthodes de calcul diffèrent entre la capacité disponible pour l'OS, les fabricants de SSD et les fabricants de NAND.
Ainsi Windows, au contraire de Mac OS X et de Linux, continue traditionnellement à compter les Ko, Mo, Go et To avec comme base 1 Ko = 1024 octets (base 2). Pourtant, depuis 1998 la norme est claire : 1 Ko = 1000 octets, et 1 Kio (kibioctet) = 1024 octets. Les supports de stockage magnétiques utilisaient déjà avant 1998 la norme actuelle, pour des raisons évidentes d'avantage commercial.
Un SSD de 128 Go affichera ainsi 119,24 Go sous Windows, mais c'est une erreur de Windows qui devrait afficher 128 Go _ou_ 119,24 Gio. De même un SSD de 120 Go est affiché comme disposant de 111,79 Go accessible au lieu de 120 Go _ou_ 111,79 Gio.
Pour ne pas faciliter les choses, les fabricants de mémoire DRAM ou Flash NAND utilisent encore une base 2. Si on prend pour exemple une puce Micron de dernière génération, un modèle 128 Gb ou 16 Go est ainsi composée de 16 384 blocs comprenant eux même 256 pages. Chaque page est constituée de 4096 octets utiles et de 224 octets pour l'ECC. On dispose donc au total de 17179869184 octets utiles, soit 17,18 Go ou 16 Gio, et non pas 16 Go.
Tous les SSD actuels de 120/128 Go disposent donc de 137,4 Go/128 Gio de Flash. Pourtant ils sont vendus comme disposant de 128 Go/119,24 Gio d'espace disponible dans le meilleur des cas, car l'espace disponible supplémentaire est réservé pour le remplacement des blocs défectueux, le stockage de certaines données utiles au contrôleur tel que la table de translation entre les adresses logiques du système (LBA) et les adresses physiques en Flash (les pages). Cet espace permet également au contrôleur de toujours disposer d'un minimum de pages et blocs Flash considérés comme vides, sans quoi les mécanismes visant à maintenir les performances et assurer une bonne durée de vie ne seraient plus du tout fonctionnels.
Certains SSD vont plus loin puisqu'ils ne proposent que 120 Go / 111,79 Gio d'espace utilisable pour stocker vos données. Ces 8 Go peuvent être liés à deux choses sur les SSD de 120 go testés ici :
- Les technologies de redondance comme le RAISE de SandForce : Corsair Force 3, Force GT, Sandisk Extreme
- Un overprovisionning : Intel SSD 510, Intel SSD 520
Attention sur des SSD de capacités différentes cela peut changer. Comme le RAISE nécessite 8 Go de Flash, sur les versions 60 Go des Force 3 et GT il est désactivé au profit de 4 Go d'OP (overprovisionning), alors que sur leurs versions 240 Go de ses SSD tout comme sur l'Intel 520 on trouve 8 Go d'OP ET 8 Go pour RAISE.
L'OverprovisioningL'intérêt d'avoir un espace Flash sur-réservé (un OP) est de toujours disposer d'un grand nombre de pages et de blocs flash considérés comme libre par le contrôleur. Ceci permet d'éviter les opérations de réécriture (read-modify-write) qui pour rappel ne peuvent se faire que par bloc alors qu'une écriture simple se fait par page et d'optimiser l'utilisation du write combining qui va concaténer des écritures aléatoires en écritures séquentielles au niveau de la Flash.
En l'absence de Flash disponible dans le pire des cas pour réécrire dans un bloc déjà utilisé il faut le lire, combiner les anciennes données avec les nouvelles, puis le réécrire. Sachant que sur un die Flash de 32 Gb une page fait 4 Ko et un bloc 1 Mo, contre 8 Ko et 2 Mo sur un die 64 Gb et 16 Ko / 4 Mo sur un die 128 Gb, cela peut engendrer une usure et une baisse des performances très importante.
Bien évidemment le "provisionning" par défaut expliqué ci-dessus et la commande TRIM permettent de contourner ce problème et il suffira de garder toujours un peu d'espace vierge (6-7% suffiront largement) sur le SSD. Pour rappel cette commande est envoyée au SSD lorsqu'on supprime un fichier et permet d'invalider les données stockées en Flash qui le concernait. On obtient donc une relative cohérence entre l'espace libre du point de vue utilisateur et l'espace de Flash libre pour le SSD, ce qui n'est pas possible en l'absence de TRIM puisqu'on se contente simplement alors de modifier la table d'allocation du système de fichier. Sans TRIM, un SSD sans OP aura donc moins de mémoire Flash qu'il peut considérer comme non occupée par des données utilisateurs : il sera donc alors limité dans les possibilités de write combining et devra faire souvent appel au read-modify-write.
Avec un OP, le SSD disposera dans tous les cas d'un important volume de mémoire Flash qu'il pourra manipuler à sa guise : ce seront les adresses physiques (pages) qui ne seront pas liées à des adresses logiques (LBA) dans la table de translation du SSD. Si Intel propose d'office un OP sur les SSD 510 et 520, il est tout à fait possible d'en faire un par vous-même : il suffit de ne pas utiliser tout l'espace du SSD, par exemple en ne le partitionnant pas entièrement. SandForce dispose ici d'un avantage inhérent à son algorithme de compression, puisque même si vous utilisez tous l'espace utilisateur disponible sur le SSD, les données occuperont moins de place physiquement dans la Flash et une partie restera donc disponible. Le volume de Flash disponible dépendra alors du taux de compression qu'a réussi à obtenir le contrôleur.
E9 reporte le volume de données écrit réellement en Flash, et EA/F1 le volume de donnée écrit par l'hôte vers le SSD
Quel est l'impact de l'OP en pratique ? Pour en savoir plus nous avons utilisé un Corsair Force GT car comme tous les SSD SandForce il permet d'avoir accès via le SMART au volume d'écriture demandé par l'OS et à celui réellement écrit sur la Flash, ce qui permet d'obtenir l'amplification en écriture.
On mesure ici les performances lors d'écritures aléatoires de 4 Ko incompressibles avec un seul accès concurrent pendant 20 minutes sur 24 Go du SSD sans envoie de commande TRIM dans diverses configurations d'espace flash disponible :
- SSD complètement vide (neuf) après secure erase (120 Go d'espace libre)
- SSD avec 0 Go d'espace libre et de flash non occupée au début du test
- SSD avec 4 Go d'espace libre et de flash non occupée au début du test
- SSD avec 8 Go d'espace libre et de flash non occupée au début du test
- SSD avec 16 Go d'espace libre et de flash non occupée au début du test
- SSD avec environ 0 Go d'espace libre mais 7 Go de flash non occupée du fait de la compression SandForce au début du test
Comme vous pouvez le voir, plus on dispose de Flash disponible au début du test, plus les performances sont bonnes. Cela est bien entendu vrai au début du test, phase durant laquelle on va exclusivement utiliser cet espace vierge, mais la stabilisation des performances qui arrive dans un second temps se fait également à un niveau plus élevé. On ne revient par contre jamais au niveau de performance initial qui ne peut être maintenu que dans le cadre du TRIM.
La baisse des performances est complètement liée à la pression plus importante sur la NAND comme le démontre les chiffres d'amplification en écriture obtenus lors du test :
- SSD vide : 1.39x
- 0 Go d'espace libre : 4.54x
- 4 Go d'espace libre : 2.54x
- 8 Go d'espace libre : 1.96x
- 16 Go d'espace libre : 1.53x
L'écriture séquentielle peut également profiter de ce surplus de Flash en l'absence de TRIM. Voici ainsi les performances obtenues lorsque l'on écrit la même zone de 24 Go de manière séquentielle après qu'elle aient été écrites en aléatoire :
Le facteur d'amplification obtenu est le suivant :
- SSD vide : 1.09x
- 0 Go d'espace libre : 1.78x
- 8 Go d'espace libre : 1.24x
Le Garbage collectorLes SSD utilisent un mécanisme appelé Garbage Collector qui a pour but de réorganiser les données au sein de la Flash afin de maximiser le nombre de pages et de blocs vierges de données ce qui permet d'accélérer les écritures suivantes. Ce Garbage Collector peut s'effectuer en temps réel lors de l'écriture de nouvelles données mais également lors des périodes de repos, on parle alors d'Idle Garbage Collector.
Mettre en avant ce dernier phénomène est assez complexe puisqu'il est nécessaire de remettre le SSD dans les mêmes conditions avant chaque début de test, et d'attendre ensuite un même temps entre diverses phases d'écritures que l'idle GC fasse son effet. Sur un Corsair Performance Pro, réputé pour avoir un GC efficace, nous effectuons les manipulations suivantes :
- Remplissage d'une partition A de 104 Go et d'une partition B de 24 Go (cas 0 Go d'OP)
- Remplissage d'une partition A de 96 Go et d'une partition B de 24 Go (cas 8 Go d'OP)
- Ecritures aléatoires par bloc de 4 Ko sur B (20 minutes)
- Pause éventuelle
- Ecritures séquentielles par bloc de 2 Mo sur B (5 minutes)
- Pause éventuelle
- Ecritures séquentielles par bloc de 4 Ko sur B (5 minutes)
On commence par le niveau de performance atteint pour les écritures séquentielles après avoir écrit de manière aléatoire sur notre partition B.
[ 0 Go d'OP ] [ 8 Go d'OP ]
Avec 0 Go d'OP, le SSD perd beaucoup en performances dans ce cas par rapport aux 300 Mo /s initiaux et on débute en dessous des 50 Mo /s sans pause entre les deux types d'accès. Au fil des écritures séquentielles sur la zone les performances remontent. Le GC au repos permet ici d'atteindre dès le départ 90 Mo /s que ce soit avec 5 ou 30mn de repos, mais elles peinent par la suite à dépasser les 100 Mo /s. Avec seulement 1mn l'impact est nettement plus faible. Le fait d'avoir 8 Go d'OP permet d'avoir un impact moindre sur les performances dès le départ avec ou sans GC. Cette fois le fait de laisser le SSD reposer 5 ou 30mn fait une différence alors que les courbes pour 1 et 5 minutes sont communes.
On passe ensuite aux écritures séquentielles après avoir effectué des écritures séquentielles sur la zone B.
[ 0 Go d'OP ] [ 8 Go d'OP ]
Avec 0 Go d'OP et sans pause et donc pas de GC les performances débutent à 30 Mo /s contre 75 Mo /s sur le SSD neuf. Avec une pause de 1, 5 ou 30mn les entre le séquentiel et l'aléatoire les performances sont très proches on démarre à 55 Mo /s sur la première minute mais on retombe ensuite directement au même niveau, un gain qui semble donc plus être lié à la remise à libération du cache en écriture qu'autre chose. Avec 8 Go d'OP on note une meilleure tenue des performances puisqu'on est à 50 Mo /s sans pause. Même avec 1mn de pause on débute à 65 Mo /s environ dans les performances, mais dès la seconde minute on revient au même niveau qu'en l'absence de pause.
Vous l'aurez compris, seul, l'Idle Garbage collector ne peut pas grand-chose. Le meilleur garant d'une bonne tenue des performances d'un SSD reste le TRIM, et en son absence l'Overprovisionning. L'Idle Garbage Collector n'est qu'accessoire.
Toshiba Q Series et débits : attention !
Corsair Force 3, Force GT et Force GS en test
Sommaire
1 - Introduction
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
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
16 - OCZ Vertex 4, Agility 4, Octane, Petrol 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
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
Vos réactions
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 ...