HardWare.fr


Comparatif SSD 2012-2013 : 37 SSD SATA 6G 120 et 128 Go
StockageSSD
Publié le Vendredi 15 Novembre 2013 par Marc Prieur

URL: /articles/860-1/comparatif-ssd-2012-2013-26-ssd-sata-6g-120-128-go.html


Page 1 - Introduction

La dernière mise à jour du 15/11/2013 a ajouté 6 nouveaux SSD détaillés ici
Enfin ! Après de longues semaines d'élaboration, voici notre nouveau comparatif de SSD. Pour ce comparatif initialement mis en ligne en 2012 et les mises à jours qui ont suivi, nous avons décidé de nous concentrer sur la capacité phare de 120 à 128 Go et de limiter notre sélection aux SSD offrant une interface SATA 6 Gbps/s. Ce sont ainsi pas moins de 37 SSD qui sont passés sur notre banc de test :


- Corsair Force 3
- Corsair Force GT
- Corsair Force GS
- Corsair Perf Pro
- Corsair Neutron
- Corsair Neutron GTX
- Corsair Neutron GTX B
- Crucial C300
- Crucial M4
- Crucial M500
- Intel 330
- Intel 510
- Intel 520
- Kingston V200
- Kingston V300
- OCZ Octane
- OCZ Petrol
- OCZ Vertex 3 MI
- OCZ Vertex 3.20
- OCZ Agility 4
- OCZ Vertex 4
- OCZ Vertex 450
- OCZ Vector
- OCZ Vector 150
- Plextor M3
- Plextor M3P
- Plextor M5S
- Plextor M5P
- Samsung 830
- Samsung 840
- Samsung 840 EVO
- Samsung 840 Pro
- Sandisk SSD
- Sandisk Ultra Plus
- Sandisk Extreme
- Sandisk Extreme II
- Toshiba Q Series


Nous profiterons également de ce dossier pour faire le point sur de nombreux aspects de cette technologie. Bonne lecture à tous !
Un SSD, c'est quoi ?
Avant toute chose, et pour ceux qui sortent d'hibernation, un petit rappel sur ce qu'est un SSD s'impose. Un SSD (pour Solid State Drive) est un support de stockage constitué de mémoire flash, en opposition au disque dur classique (HDD) qui stocke les données sur des plateaux magnétiques.

Les avantages des SSD sur les disques durs classiques sont multiples, tout d'abord en termes de performances, mais aussi de nuisance sonore et de résistance aux chocs. Leur utilisation est transparente pour le système, ils sont adressés comme des disques durs par le contrôleur SATA.

Leur désavantage se situe au niveau de la mémoire Flash dont la durée de vie est limitée. Ainsi, une Flash NAND MLC ne peut être écrite que 3 000 à 5000 fois pour celles gravées en 24-27nm, 10 000 fois pour celles en 34-35nm, mais ceci est heureusement compensé par des algorithmes de wear leveling qui répartissent l'usure entre les cellules et qui effacent complètement cette problématique sauf à réécrire complètement le SSD tous les jours, ce qui ne correspond pas vraiment à une utilisation classique.

Les puces sont également limitées du côté de la rétention des données, puisque si une cellule neuve est capable de stocker les données 10 ans, arrivée en fin de vie cette durée se limite à 1 an. En pratique et avec maintenant 4 ans de recul sur cette technologie, on peut affirmer que la confiance affichée par les constructeurs dans la fiabilité la mémoire Flash est justifiée.
Les nouveautés
Quoi de neuf depuis notre comparatif précédent ? Après des débuts en fanfare, le monde du SSD semble s'être grandement calmé puisque les SSD phares de l'époque tels que le Crucial M4 ou l'OCZ Vertex 3 sont encore d'actualité.

Bien sûr depuis de nouveaux modèles sont sortis, mais à défaut de pouvoir augmenter les débits en lecture puisqu'on est aux limites de l'interface SATA 6 Gbp/s ils se distinguent surtout par des débits en écriture plus élevés, notamment sur les modèles offrant de plus petites capacités (Samsung 830 et Plextor M3P par exemple). D'autres SSD se sont pour leurs parts concentrés sur les accès aléatoires, atteignant de nouveaux sommets dans ce domaine (OCZ Vertex 4).

Les mois passés ont permis également de voir que nul n'était à l'abri d'une faille dans son firmware. En août, Intel a ainsi sorti pour ses SSD 320 un firmware visant à corriger un bug qui rendait le SSD parfois inutilisable en cas de coupure de courant inopinée. En octobre, SandForce a proposé de nouveaux firmware mettant fin aux écrans bleus rencontrés par certains en sortie de veille notamment. En janvier ce fut au tour de Crucial de mettre à jour son M4 contre un bug entraînant un écran bleu chaque heure une fois passé les 5184 heures d'utilisation et de Samsung de mettre en ligne un firmware pour le Samsung 830 corrigeant un souci d'écran bleu en sortie de veille. Attention toutefois, si cette liste peut paraitre alarmiste de prime abord, il faut bien préciser que ces problèmes n'étaient pas systématiques. Bien heureusement, une très grande majorité des utilisateurs profitent de leur SSD sans encombre !


Page 2 - Optimiser son SSD

Optimiser son SSD sous Windows
De multiples guides consultables sur Internet annoncent vous aider à optimiser votre SSD sous Windows. La première chose à faire n'a pourtant rien à voir avec l'OS ni même avec les SSD puisqu'elle s'applique aussi aux disques durs classiques, il s'agit d'activer dans le bios de votre carte mère le mode AHCI du contrôleur Serial ATA en lieu et place du mode IDE classique, ce qui n'est pas forcément le cas par défaut. L'AHCI permet au périphérique de stockage d'optimiser son traitement lors de multiples accès simultanés. Attention, il est préférable de faire cette manipulation avant l'installation de l'OS sous peine d'un écran bleu au redémarrage, mais Microsoft propose toutefois un "Fix It" pour Windows Vista ou 7  qui permet de passer en AHCI sans réinstallation.


En ce qui concerne les optimisations de Windows 7 et 8, il faut bien avoir conscience qu'il a été conçu avec une prise en charge native des SSD et il n'est dès lors pas utile d'effectuer la moindre optimisation pour ce qui est des performances au niveau de l'OS en lui-même.

Derrière les "conseils d'optimisations" se cachent une sous-estimation complète de la robustesse des SSD actuels qui sont prévus pour encaisser à minima 20 à 40 Go d'écriture par jour pendant 5 ans, ce qui est très loin d'une utilisation classique qui se limitera généralement entre 5 et 10 Go. Dès lors, chercher à minimiser au maximum les écritures sur ce dernier n'est pas utile, et peut même être contre-productif pour la vitesse globale du système si on déplace certains fichiers temporaires sur un disque dur. De même si l'indexation des recherches par exemple est moins utile sur SSD que sur HDD, une recherche indexée restera plus rapide qu'une recherche classique sur SSD.


Ce n'est par contre pas le cas de Windows Vista qui nécessitera une désactivation de la défragmentation automatique, cette dernière étant contre-productive sur SSD (l'OS n'ayant pas connaissance de l'organisation interne des données sur la Flash) sauf sous Windows 8 ou la défragmentation sur un SSD envoie en fait la commande TRIM pour tout l'espace vierge du SSD. Vista ne supporte pas non plus la commande TRIM en temps réel contrairement à 7 : il faudra donc plutôt s'orienter vers des SSD doté de logiciels permettant de lancer régulièrement un TRIM sur l'espace libre, c'est le cas des Intel Toolbox et de Samsung SSD Magician.


Windows XP pour sa part nécessite en plus que les partitions soient créées manuellement (ou depuis un autre OS plus récent) avec un alignement optimal pour les SSD : avec l'alignement de base la première partition est créée à partir du 63è secteur d'un support de stockage (soit 32.5 Ko), ce qui tombe pile entre deux pages Flash d'un SSD. Une simple écriture de 4 Ko sera à cheval entre deux pages de 4 Ko du SSD, il lui faudra donc écrire ces deux pages. Windows Vista et 7 laissent 2048 secteurs de marge, ce qui permet d'éviter une usure superflue et des performances en berne.
Max OS X et Linux

Quid des autres systèmes d'exploitation ? Chez Apple, Mac OS X supporte correctement les SSD, mais la gestion du TRIM intégrée depuis la version 10.6.8 n'est pas active si le SSD n'est pas celui livré par Apple. Trim Enabler  permet toutefois de contourner ceci. Linux supporte pour sa part le TRIM depuis la version 2.6.33 du noyau en ext4, mais pour l'activer il faut monter les partitions avec l'option discard.
Augmenter la capacité disponible sous Windows
Si Windows 7 et 8 n'ont pas besoin d'être optimisé en termes de performances, leur configuration peut toutefois être modifiée afin de libérer de l'espace sur votre SSD s'il est utilisé en tant que disque système. Deux fonctionnalités peuvent en effet être très gourmandes en espace disque relativement à la taille encore assez réduite des SSD :

- Mise en veille prolongée
- Mémoire virtuelle

La mise en veille prolongée réserve sur le disque un espace en fonction de la taille de votre mémoire vive via le fichier hiberfil.sys, la désactiver permet donc de ne plus avoir ce fichier encombrant à la racine du SSD système. En contre partie vous ne pourrez par contre plus utiliser la veille de type "Suspend To Disk".


Pour supprimer hiberfil.sys, il faut exécuter la commande powercfg -h off en invite de commande

La mémoire virtuelle est une zone mémoire située sur le disque système qui peut être utilisée comme de la mémoire vive si cette dernière n'est pas disponible en une quantité assez importante. Bien entendu si on en vient à l'utiliser c'est bien plus lent que la mémoire vive mais cela permet de ne pas avoir de plantage de l'application par simple manque de mémoire. Là encore toutefois Windows réserve de base l'équivalent de votre mémoire vive sur le SSD via le fichier pagefile.sys, et il est tout à fait possible de réduire cet espace réservé.


Pour réduire pagefile.sys il faut personaliser la taille du fichier d'échange en passant par Paramètres système avancés puis le bouton paramètres puis l'onglet avancé puis le bouton Modifier pour la partie mémoire virtuelle (ouf!)

Contrairement à ce que beaucoup prétendent, il est impossible de donner une formule magique puisque tout dépend de l'usage du PC. Si vous la réduisez trop et qu'un programme nécessite plus de mémoire que le système ne peut lui proposer, il plantera, mais vu le faible coût de la mémoire les PC sont généralement surdimensionnés en mémoire vive par rapport à leurs besoins réels.

Avec 4 Go de mémoire vive en utilisation courante on ne devrait guère avoir besoin de plus de 2 Go de swap et avec 8 Go une taille de 1 Go devrait couvrir la plupart des besoins.


Sur un SSD de 64 Go avec 16 Go de RAM - ce qui représente il est vrai un cas extrême - la veille prolongée et le fichier d'échange occupent par défaut 28 Go d'espace !


Page 3 - Les contrôleurs et la Flash MLC et TLC

Contrôleurs : Indilinx, JMicron, LAMD, Marvell, Samsung et SandForce
Ce qui fait le cœur même d'un SSD c'est bien entendu son contrôleur et sa mémoire Flash. Côté contrôleur, on retrouve sur les SSD SATA 6G de ce comparatif différentes puces :

- Indilinx Everest : OCZ Petrol et Octane
- Indilinx Everest 2.0 : OCZ Vertex 4 et Agility 4
- Indilinx Barefoot 3 : OCZ Vector, Vector 150 et Vertex 450
- SandForce SF-2281 : Corsair Force 3, Force GT et Force GS, Intel SSD 520 et 330, OCZ Vertex 3 Max IOPS, et Vertex 3.20, Sandisk Extreme
- Marvell 88SS9174 : Corsair Performance Pro, Crucial C300 et M4, Intel 510, Plextor M3, M3P et M5S
- Marvell 88SS9175 : Sandisk Ultra Plus
- Marvell 88SS9187 : Plextor M5P, Crucial M500 et Sandisk Extreme II
- Marvell ???? : Toshiba Q Series
- Marvell 88SS9187 : Plextor M5P, Crucial M500 et Sandisk Extreme II
- Samsung S4LJ204X01 : Samsung 830
- Samsung S4LN021X01 : Samsung 840 Pro et 840
- Samsung S4LN045X01 : Samsung 840 EVO
- JMicron JMF661 : Kingston V200
- Link_A_Media Devices LM87800 : Corsair Neutron, Neutron GTX et Neutron GTX B
- Sandisk SDC1 : Sandisk SSD

En ce qui concerne les "puces" Indilinx Everest 1 et 2, il faut préciser que du point de vue hardware pur, il s'agit en fait (encore !) d'une puce Marvell, le 88SS9174 dans le cas de l'Everest et le 88SS9187 derrière l'Everest 2.0. A contraire le Barefoot 3 est bien 100% "maison". Les fréquences d'horloges sont par contre plus hautes et le firmware est par contre entièrement développé par Indilinx. Sachant que c'est bien le firmware plus que le hardware qui est le point clé d'un contrôleur, cela donne en partie raison au choix d'OCZ qui reste tout de même discutable.

Ceci est d'autant plus vrai que si pour le contrôleur SandForce les marges de modification au sein du firmware semble plutôt réduites (les implémentations de Corsair, Kingston, OCZ et Sandisk sont semblables), seul Intel l'ayant a priori vraiment modifié, le firmware de Marvell a déjà été largement customisé par Crucial, Intel et Plextor sans pour autant qu'il y ai remarquage.


Du point de vue hardware, tous ces contrôleurs ont en commun d'être basés sur un ou plusieurs processeurs de type ARM pour le traitement de leurs algorithmes de gestion de la Flash. Ils disposent d'une interface SATA 6G pour communiquer avec la machine hôte et gère la mémoire Flash sur 8 canaux (sauf le JMF661 et le 88SS9175 sur 4 canaux), que ce soit avec des bus asynchrones ou synchrones, et à l'exception du JMicron ils peuvent utiliser un codage AES pour sécuriser les données.

Si tous ces contrôleurs disposent d'une petite mémoire destinée à stocker le firmware et un minimum de données utilisateurs, respectivement 128 Ko et 64 Ko pour un Everest par exemple, ils font quasiment tous appels à une mémoire DRAM externe qui fait principalement office de cache en écriture et qui peut atteindre une taille de 1 Go sur l'Everest 2.0. Les exceptions sont le SandForce SF-2281, le Sandisk SDC1 et le contrôleur Marvell et employé sur le Toshiba Q Series.

Du côté de la gestion de l'usure de la Flash, ils supportent bien entendu tous le wear leveling, un algorithme qui essaie d'égaliser l'usure des cellules Flash au sein du SSD, ainsi qu'une correction d'erreur ECC plus ou moins poussée afin de vérifier l'intégrité des données.

Le SandForce SF-2281 est par ailleurs le premier à avoir introduit une technologie dénommée RAISE qui agit en quelque sorte comme un RAID 5 en interne. Une parité est donc calculée et dispatchée entre les die du SSD afin de se protéger de la perte des données en cas de perte d'une partie d'une puce Flash. Cette technologie a bien entendu un petit impact sur les performances et sur la capacité disponible, puisqu'elle grève la capacité de 8 Go sur les SSD l'utilisant. SandForce a depuis été imité par Indilinx qui propose une technologie similaire, RNA, sur l'Everest 2.0... tout comme Marvell qui intègre une fonctionnalité comparable sur le tout récent Marvell 88SS9187 (voilà un indice sur la puce qui se cache derrière l'Everest 2.0 !).

Une autre technologie propre à SandForce n'a pas été copiée, il s'agit d'une compression en temps réel des données sur laquelle nous revenons sur cette page.
Flash : MLC, TLC, Flash Forward (Toshiba et Sandisk), Hynix, IMFT (Intel et Micron) et Samsung

L'autre partie essentielle d'un SSD c'est bien entendu sa mémoire Flash. De nombreuses combinaisons sont proposées parmi les SSD de ce test, et nous avons essayé d'éviter tant que possible les redites afin d'éviter de faire dans la simple guerre des clones :


Un même contrôleur peut être associé à plusieurs types de NAND. Les premiers SSD SATA 6G utilisaient ainsi de la mémoire 32 ou 34nm fabriquée par IMFT (alliance Intel et Micron) ou Flash Forward (alliance Toshiba et Sandisk), on est depuis passé à de la mémoire 24 ou 25nm puis 20 ou 19nm. Le Petrol d'OCZ est le seul à faire appel à de la mémoire Hynix dont on sait juste qu'elle est gravée en 2xnm (soit entre 20 et 29nm…).

Le M5P de Plextor est le premier à avoir fait appel à de la mémoire MLC gravée en 19nm, dont l'endurance est inchangée par rapport à la MLC 24nm Toshiba (officiellement 3000 cycles), il a depuis été rejoint par de nombreux modèles. Côté IMFT c'est l'Intel 335, équivalent au 330 mais qui n'existe pas en version 120 Go, qui est le premier à avoir utilisé la mémoire 20nm du consortium. Il a été rejoint par le Crucial M500, l'OCZ Vertex 3.20 et le Vertex 450.

Il faut noter que chez IMFT on trouve deux type de Flash MLC 25nm, l'une certifiée pour 3000 cycles d'écritures, l'autre pour 5000 : Seuls l'Intel SSD 520 et le Kingston HyperX utilisent la 5000 cycles. En pratique toutefois les tests d'usure sur certains SSD tels que le Crucial M4 ont montrés que la 3000 était capable d'aller bien au delà, et dans tous les cas 3000 cycles restent suffisant pour une utilisation classique.

Samsung 830 utilise de la mémoire 27nm MLC de sa propre marque sur le 830, alors que le 840 Pro intègre de la MLC 21nm annoncée au même niveau d'endurance de 3000 cycles. A contrario le 840 classique utilise de la TLC 21nm moins endurante puisque limitée officiellement à 1000 cycles d'écriture. La TLC est moins endurante que la MLC car on stocke 3 bits par cellule Flash ce qui correspond à 8 niveaux de tension possible contre 4 en MLC (et 2 en SLC). La programmation de ce niveau de tension est donc plus long ce qui stresse (et use) plus la cellule. L'écriture devant se faire en plusieurs passes, elle est également plus lente. Attention toutefois à ne pas faire dans l'alarmisme inutile, 1000 cycles sont suffisant pour un usage classique : cela correspond par exemple sur un SSD 128 Go à 5 ans et 10 mois avec 20 Go d'écritures par jour et une amplification en écriture assez élevée de trois (et donc 11 ans et 8 mois sur un 256 Go). Le 840 EVO utilise également de la TLC, elle est cette fois gravée en 19nm et les die ne sont plus 8 mais 16 Go (les pages passent aussi de 8 à 16 Ko).

Le bus de communication entre la Flash et le contrôleur est également important : ce dernier peut être de type ONFI 1.0 dit asynchrone et limité à 50 MT/s mais aussi en ONFI 2.1 dit synchrone atteignant alors les 200 MT /s. Toshiba, Sandisk et Samsung utilisent de leur côté un bus similaire à l'ONFI synchrone dénommé Toggle. En clair, les mémoires Flash utilisant ce type de bus seront plus rapides, mais les asynchrones seront moins chères.

Enfin vous aurez peut-être remarqué que nous avons mis en italique la Flash utilisée dans l'OCZ Vector. Les puces MLC que l'on trouve au sein du Vector ne comportent que le logo OCZ puisque ce dernier achète à IMFT des wafer complet et s'occupe du packaging des puces. L'avantage se situe au niveau du coût qui est moindre, mais on ne pourra se fier qu'à OCZ pour ce qui est du niveau de qualité de puces intégrées.


Page 4 - SandForce, compression et débits : attention !

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.


Page 5 - OCZ Indilinx Everest 2 / Barefoot 3 et débits : attention !

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 :


[ 0.5 - 8192 Ko ]  [ 256 - 8192 Ko ]  [ 2048 - 8192 Ko ]


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 final
Comme 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.


Page 6 - Samsung 840 EVO, TurboWrite et débits : attention !

Samsung 840 EVO, TurboWrite et débits : attention !
Il est difficile de tirer son épingle du jeu dans un marché du SSD désormais mature, et beaucoup d'utilisateurs prennent trop à cœur les chiffres de performances fournit par les constructeurs alors que les chiffres atteints par les SSD sont généralement inutiles en pratiques et d'autres parts que ces chiffres sont à prendre avec des pincettes comme nous l'avons vu au cours des deux pages précédentes.

Avec la mémoire TLC utilisé dans ses Samsung 840 et 840 EVO, Samsung a pour avantage d'avoir une mémoire bien moins chère puisqu'il est possible de stocker 3 bits par cellule Flash ce qui correspond à 8 niveau de tension possible contre 4 en MLC (et 2 en SLC). On stocke donc plus de données par mm² de puce, mais en contrepartie la programmation du niveau de tension doit être plus précise et est donc plus longue, ce qui stresse (et use) plus la cellule.

L'usure n'est en soit pas un problème, car même avec 1000 cycles pour les TLC contre 3000 cycles pour les MLC on dispose d'assez de marge pour une utilisation classique même intensive. Par contre, la vitesse de programmation est un problème pour Samsung puisqu'elle entraine des débits en écriture moins important, un point problématique d'un point de vue marketing.

Le TurboWrite en action, c'est le petit pic au début de cette écriture complète du SSD

Pour résoudre ce souci le Samsung 840 EVO dispose d'une technologie appelée TurboWrite, qui utilise une partie de la TLC en tant que SLC, comme le fait OCZ en page précédente. Si la capacité accessible à l'utilisateur ne varie pas face au 840 qui intègre un overprovisionning par défaut, sur le 840 EVO cet OP laisse place à TurboWrite qui occupe même une partie du provisionning par défaut. Samsung réserve ainsi 36 Go, 27 Go, 18 Go et 9 Go de mémoire TLC pour disposer de 12, 9, 6 et 3 Go de cache TurboWrite sur les versions 1 To, 750 Go, 500 Go et 250/120 Go.


Comme vous pouvez le voir d'après les spécifications officielles, l'écart entre la vitesse TurboWrite et la vitesse d'écriture classique est variable, avec un facteur de s'approchant de x3 en version 120 Go et x2 en version 250 Go. A partir de la version 500 Go l'écart n'est plus que de 24% en faveur de TurboWrite.

Du coup Samsung comme les revendeurs ne se privent pas de mettre plutôt en avant la vitesse de TurboWrite comme celle en écriture, alors même qu'elle ne peut être soutenue. Car une fois les quelques Go de TurboWrite rempli, on retombe à une vitesse classique, ce cache étant vidé durant les périodes où le SSD n'écrit plus de manière intense.

A l'instar de la compression des données sur SandForce ou du mode SLC des Indilinx Everest 2 et Barefoot 3 que nous avons déjà pointé du doigt, TurboWrite semble avant tout être un artifice permettant d'afficher un gros débit en écriture séquentielle sur les fiches produit bien qu'il ne puisse être maintenu en pratique, un débit auquel les acheteurs de SSD accordent il est vrai bien trop d'importance par rapport à son utilité réelle.

On passe de plus de l'artifice à la publicité mensongère lorsque le débit hors TurboWrite n'est pas mentionné, un point avec lequel nous avions échangé avec Samsung qui avait du coup demandé aux revendeurs de préciser cette information. Malgré tout c'est loin d'être systématique, et quand c'est le cas ce n'est pas forcément aussi visible que le débit hors TurboWrite qui reste plus mis en avant. Pire, Samsung lui-même n'indique par le débit sans TurboWrite sur ses fiches produits officielles :


C'est dommage d'autant que le TurboWrite nous semble contre-productif du point de vue de l'usure. Un peu comme c'est le cas de la technique utilisée par OCZ lorsque l'espace "SLC" est consolidé, le TurboWrite augmente l'amplification en écriture du SSD et donc son usure à terme puisque pour écrire 3 Mo de données on écrit non pas 1 millions de cellules en TLC mais 3 millions en SLC puis 1 millions en TLC, soit 4 fois plus ! Attention par contre les cellules ne seront pas usées 4 fois plus vite pour autant, une écriture en "mode SLC" étant moins stressante qu'une autre en "mode TLC". L'autre problématique, exclusive à Samsung cette fois, est que TurboWrite prive le SSD d'une grande partie d'une grande partie de la Flash jusqu'alors réservée pour les optimisations interne du contrôleur destinées entre autre à réduire l'usure de la Flash (provisionning et overprovisionning) notamment en l'absence de TRIM.


Page 7 - Toshiba Q Series et débits : attention !

Toshiba Q Series et débits : attention !
Vous pensiez avoir fait le tour des techniques permettant - entre autres - de gonfler les débits annoncés sur les fiches techniques, nous aussi… Malheureusement les tests du Toshiba Q Series nous ont révélés une technique identique, voici par exemple sa courbe de débit en écriture complète sous HD Tune :


Comme chez OCZ, la première moitié des données écrites sur le SSD le sont à pleine vitesse, environ 470 Mo /s sur ce SSD 128 Go, mais la seconde moitié se fait à 100 Mo /s environ ! En moyenne on est à 283 Mo /s lors de ce premier passage. Si on décide de réécrire l'intégralité du SSD, sans commande TRIM dans l'intervalle, le débit est plus stable avec 161 Mo /s en moyenne.


Il semble clair que comme OCZ, Toshiba utilise prioritairement les pages Flash correspondant au premier des deux bits stockés dans chaque cellule Flash. Ce premier bit est le plus facile à programmer, et ces pages sont écrites comme de la SLC (1 bit stocké par cellule). A contrario une fois ces pages utilisées il faut passer aux autres pages qui correspondent au second bit, soit à des niveaux de tensions plus précis et plus long à programmer. Par contre les performances en lectures ne sont pas impactées quand on essaie de relire les zones écrites de manière non optimales, la lecture se 500 Mo /s dans tous les cas.

A contrario d'OCZ, nous n'avons pas noté de réorganisation de l'espace une fois les données écrites. Ce qui pourrait paraître comme un avantage au premier abord, puisqu'on limite le travail en fond de tâche et le volume de données réécrites, est tout sauf en être un. Imaginons un SSD 128 Go, sur lequel l'OS et les applications courantes installées en premier occupent 70 Go. Ces 70 Go seront stockés de manière fixes sur les pages "SLC", alors que quand vous vous écrirez, et réécrirez, sur les 58 Go restant cela se fera sur les pages les plus lentes à programmer et qui usent le plus les cellules. On imagine qu'au bout d'un moment tout ceci est réorganisé afin de lisser l'usure des cellules, mais nous ne savons pas dans quelles conditions.

Bien entendu seule la vitesse "en pointe" est mentionnée sur les fiches produits Toshiba...


Page 8 - Capacité, overprovisioning et Garbage collector

Capacité : Go et Gio
Tout 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'Overprovisioning
L'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 collector
Les 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.


Page 9 - Corsair Force 3, Force GT et Force GS en test

Corsair Force 3, Force GT et Force GS en test
Les SSD Force 3, Force GT et Force GS de Corsair représentent le cœur de la gamme SATA 6G de Corsair. Ils utilisent tous trois des contrôleurs SandForce SF-2281 qui sont respectivement associés à de la NAND IMFT 25nm asynchrone, de la NAND IMFT 25nm synchrone et de la NAND Sandisk 24nm.

On trouve sur le marché de nombreux équivalents aux deux premiers en terme de combinaison contrôleur / NAND, avec pour les plus courants :

- Corsair Force 3 : OCZ Agility 3, Kingston V+200
- Corsair Force GT : OCZ Vertex 3, Kingston HyperX/HyperX 3K, Intel 520 et 330


D'un point de vue extérieur ces SSD 2.5" sont tout ce qu'il y a de plus classiques avec une épaisseur de 9.5mm, en dehors de la couleur du Force GT pour le moins originale pour un SSD. Dans leur version boîte ils sont livrés avec un adaptateur pour emplacement 3.5" et les vis associées. Déclinés en versions 60 à 480 Go, leur garantie est de 3 ans.


Les spécifications officielles des Corsair Force 3, Force GT et Force GS ne font état que de leurs performances sur des données très fortement compressibles. Dans ce cas, tout est merveilleux et même un Corsair Force 3 60 Go atteint des performances impressionnantes.
Malheureusement quand on regarde les chiffres en incompressibles plus réalistes qui sont fournis par un concurrent, OCZ pour ne pas le citer, pour des SSD similaires c'est bien moins rose et on passe par exemple de 540 Mo /s à 180 Mo /s en lecture et de 490 Mo /s à 65 Mo /s en écriture ! Du fait de sa mémoire synchrone, le Corsair Force GT souffre moins du passage en incompressible, surtout en lecture. Au fil de la hausse de la capacité les performances sont en hausse, surtout en écriture, mais on note un moins bien sur les versions 480 Go. Malheureusement aucune donnée similaire n'est disponible pour le GS.


A l'intérieur pas de surprise avec la présence du SandForce et de 16 puces Flash IMFT 25nm sur les deux premiers et 8 puces Sandisk 24nm sur le dernier. Ces puces offrent une capacité totale de 137,4 Go ou 128 Gio, mais seuls 120 Go ou 111,79 Gio sont accessibles à l'utilisateur sur les Force 3 et Force GT, puisqu'en sus de l'espace réservé classique sur les puces Flash (7% environ) qui ramène la capacité utile à 128 Go ou 119,24 Gio, 8 Go supplémentaires sont réservés à la technologie RAISE de SandForce qui permet de protéger les données en cas de défaillance totale d'une partie d'une puce Flash. On passe ainsi à une capacité utile de 120 Go ou 111,79 Gio. Ce n'est pas le cas du Force GS qui se passe du RAISE et offre bien 128 Go d'espace accessible.

Aucune mémoire DRAM externe n'est nécessaire à la puce SandForce ce qui permet quelques économies.


Page 10 - Corsair Performance Pro en test

Corsair Performance Pro en test
Le Performance Pro de Corsair constitue le haut de gamme en SSD SATA 6G chez Corsair. Il utilise en fait la même base que le Plextor M2P (et sort a priori de la même usine) et est basé sur un contrôleur Marvell 88SS9174 associé à de la NAND Toshiba Toggle fabriquée en 32nm.


D'une épaisseur de 9.5mm, ce SSD au format 2.5" est livré dans sa version boite avec un adaptateur 3.5" et les vis qui vont avec. Disponible en versions 128 Go mais aussi 256 Go, il est accompagné d'une garantie constructeur de 3 années.


Du côté des performances officielles les débits annoncés en écriture sont très important dès la version 128 Go.


Une fois ouvert on découvre donc le contrôleur Marvell accompagné de 2 puces de 256 Mo de DDR3-1333 Nanya qui font office de cache. Côté NAND ce sont un total de 8 puces de 16 Go pièces d'origine Toshiba qui sont utilisées.


Page 11 - Corsair Neutron GTX et Neutron en test

Corsair Neutron GTX et Neutron en test
Présent de longue date sur le marché du SSD, Corsair a décidé avec les Neutron et Neutron GTX de faire dans l'originalité et est le premier à intégrer un tout nouveau contrôleur LM87800 de Link_A_Media Devices (LAMD). Peu connu du grand public, LAMD est déjà présent depuis quelques années dans le milieu du stockage, notamment du côté des contrôleurs pours disques durs, et a été racheté il y a peu par Hynix.



Le LM87800 utilise comme quasiment tous les contrôleurs une architecture ARM. Deux cœurs sont ici présents, associé à un cache de type DDR2 alors que la mémoire Flash est gérée sur 8 canaux. Elle peut être de type ONFi ou Toggle mode, et la communication avec le système se fait par une interface SATA 6 Gbps. Le LM87800 gère bien entendu le TRIM et intègre une correction ECC et une gestion avancée de la NAND (wear-leveling, garbage collection, TRIM). On notera également la présence d'un algorithme DSP dénommé eBoost censé augmenter la durée de vie des cellules Flash.


Tous deux garantis 5 ans, les Corsair Neutron et Neutron GTX associent respectivement le LM87800 a de la mémoire IMFT 25nm ONFi synchrone et Toshiba 24nm Toggle mode ou 19nm pour la version "B" du GTX (décrite ici). La mémoire cache est de 256 Mo, et ces deux SSD au format 2.5" 7mm sont livrés avec un adaptateur 3.5" et la visserie nécessaire à leur installation. Seul le GTX dispose de la fonctionnalité eBoost. Voici les performances annoncées par Corsair :


Comme d'habitude les performances augmentent avec la capacité, et le GTX se distingue essentiellement du Neutron classique via ses performances en écriture séquentielle. On notera que Corsair a fait le choix de réserver une part supplémentaire de la NAND disponible à des fins d'over-provisionning, d'où les capacités utiles réduites par rapport à d'autres SSD.


A l'intérieur du Neutron GTX on retrouve donc le contrôleur LM87800 entouré de 8 puces Flash Toshiba 24nm Toggle et un total de 256 Mo de DDR2 Samsung.


Au sein du Neutron GTX B ce sont 16 puces Flash Toshiba 19nm Toggle.

Le Neutron intègre pour sa part au côté du LM8780016 puces Flash Micron 25nm ONFi synchrone et 2x128 Mo de DDR2 Samsung.


Page 12 - Crucial M500, M4 et C300 en test

Crucial M500, M4 et C300 en test
Crucial, filiale de Micron, est le premier à avoir utilisé le contrôleur Marvell 88SS9174 dans ses SSD. Le Crucial C300 fut ainsi le premier SSD SATA 6G disponible dès février 2010. A l'époque associé à de la mémoire IMFT 34nm (une joint-venture Intel et… Micron !), le C300 a connu ensuite une évolution début 2011 avec le Crucial M4 qui utilise de la mémoire IMFT gravée en 25nm et dotée d'un bus synchrone, avec au passage des performances en hausse pour ce qui est des accès séquentiels. Enfin le M500 a marqué début 2013 le passage à de la mémoire 20nm et à un contrôleur Marvell 88SS9187.


Les C300 et M4 sont de base en format 2.5" 9.5mm, mais qu'une déclinaison en 7mm existe. La version 9.5mm est toutefois facilement transformable en version 7mm puisque les 2.5mm supplémentaires sont obtenus via une coque intermédiaire amovible, attention par contre cette manipulation vous fera perdre la garantie de 3 ans. Le M500 fait pour sa part 7mm mais il est fournit avec un adaptateur permettant d'atteindre les 9.5mm si cela s'avère nécessaire.


De base le Crucial M4 n'est livré avec aucun accessoire, mais une version avec un kit de transfert (logiciel de clonage et connectique USB) est également vendue afin de faciliter la migration depuis un disque dur. Le M500 n'est à ce jour pas disponible dans une telle version.


Les spécifications officielles des C300 et M4 montrent que le M4 améliore les choses en lecture séquentielle, écriture séquentielle et aléatoire mais est en recul pour ce qui est de la lecture aléatoire. Les performances en écriture du M4 augmentent jusqu'à la version 256 Go mais pas au-delà.

Côté M500 la première chose à noter, ce sont les capacités qui sont de 120, 240, 480 et 960 Go. Contrairement à ce que Crucial a fait sur les M4, les M500 intègrent une réserve de Flash supplémentaire en sus de celle de base, variant de 8 à 64 Go selon la version. Même si côté endurance les MLC 25nm et 20nm IMFT utilisées par Crucial sont spécifiées pour 3000 cycles, Crucial a fait le choix d'intégrer la technologie RAIN (Redundant Array of Independent NAND) au sein du M500. Similaire au RAISE de SandForce, il s'agit grâce à la parité de protéger les données de la défaillance d'une mémoire Flash.

Si on compare le M500 au M4 niveau performances on remarque des gains notables en écritures sur la version 480 Go par rapport au M4 512 Go, alors que les lectures aléatoires sont en hausse sur toutes les capacités. Côté écriture aléatoire, les gains sont notables dès la version 240 Go. Attention toutefois, certains chiffres officiels du M4, notamment pour la lecture aléatoire des versions 64 et 128 Go, sont en fait sous-estimés par rapport à la pratique ce qui rend la comparaison difficile.

Il est clair par contre que le Crucial M500 120 Go offrira un débit nettement inférieur au M4 128 Go en écriture, alors que ce sera proche sur la capacité supérieure et en faveur du M500 au-delà. Ceci s'explique probablement par le fait que le M500 intègre moins de die Flash du fait d'une capacité unitaire supérieure de ceux-ci, ce qui limite donc les possibilités d'écritures en parallèle. En effet les M4 64 et 128 Go utilisaient des die 32 Gb, alors qu'en 20nm la capacité minimale est de 64 Gb et celle utilisée sur les M500 de 128 Gb. Au passage, il faut savoir que les pages d'un die de 128 Gb font 16 Ko, contre 8 Ko pour un die 64 Gb. Sachant que la page est la plus petite quantité qui puisse être lue ou écrite en Flash, cela pourrait donc avoir un impact négatif sur les accès de petite taille.

Du côté des caractéristiques additionnelles on notera par rapport au Crucial M4 le support du codage AES 256 bits en hardware (avec IEEE1667 et TCG Opal 2.0, ce qui permet l'usage du codage matériel par BitLocker sous Windows 8 via le standard Microsoft eDrive) ainsi que d'une sonde de température. Notez d'ailleurs qu'une fois la limite de 65 °C atteinte, les performances seront limitées jusqu'à redescendre à 55 °C. Pour atteindre un tel de niveau de température il faudra combiner une forte charge continue et l'absence de toute ventilation.


A l'intérieur du Crucial C300 on retrouve donc le Marvell 88SS9174 accompagné d'un cache DRAM Micron de 128 Mo et de 16 puces de 8 Go IMFT 34nm.


Au sein du Crucial M4 le Marvell 88SS9174 est accompagné de 256 Mo de DRAM Micron et de 16 puces de 8 Go IMFT 25nm.


Le Crucial M500 intègre pour sa part un Marvell 88SS9187, 256 Mo de DRAM et 8 puces de 16 Go IMFT 20nm. On note la présence de nombreux condensateurs afin de tenter de préserver au mieux les données en cas de coupure de courant, un point assez rare sur les SSD grands publics. Attention toutefois il ne s'agit toutefois pas d'une protection complète évitant la perte des données en cache comme c'est le cas sur les SSD professionnels.


Page 13 - Intel SSD 520, 330 et 510 en test

Intel SSD 520, SSD 330 et SSD 510 en test
Après avoir lancé des SSD utilisant ses propres contrôleurs SATA 3G dès 2008 avec le X25-M, Intel a décidé de ne pas développer de contrôleur de nouvelle génération pour le SATA 6G et d'utiliser des puces tierces en se concentrant sur la mise au point de firmware dédié.


Le premier SSD basé sur cette nouvelle stratégie fut l'Intel 510 basé sur un contrôleur Marvell 88SS9174 associé à de la mémoire IMFT 34nm, une combinaison proche de celle du C300 mais assez différente en pratique tant les choix au niveau du firmware sont différents : plus de débit en séquentiel au détriment des accès aléatoires, et un overprovisionning par défaut de 8 Go sur la version 120 Go et 6 Go sur la version 250 Go.


Intel a ensuite lancé l'Intel SSD 520 qui est cette fois basé sur le couple SandForce SF-2281 et Flash IMFT 25nm synchrone certifiée pour 5000 cycles d'écriture, comme c'est le cas également du Kingston HyperX. Les Corsair Force GT, OCZ Vertex 3 et HyperX 3K sont pour leur part associés à de la mémoire certifiée pour 3000 cycles. Ici encore la différence se fait au niveau du firmware qui est spécifique. Disponible en versions 60, 120, 240 et 480 Go, il se distingue également des autres SandForce sur la version 120 Go puisque Intel ne réserve pas 8 Go pour la technologie RAISE au profit de 8 Go de "simple" overprovisionning. Selon Intel le RAISE n'est en effet pas utile pour la qualité de NAND actuellement utilisée dans ces SSD.


Enfin l'Intel SSD 330 est une déclinaison un peu moins performante du 520 qui se distingue surtout par sa garantie qui est de 3 ans, comme le 510, a contrario du 520 qui est à 5 ans (dans la limite de l'usure en écriture mesurée par la valeur SMART du media wear out pour la version OEM).


Ils sont trouvables en version nue mais également en version boite qui intègre un adaptateur 3.5" et les vis qui vont avec ainsi qu'un câble SATA et un adaptateur d'alimentation Molex vers SATA. Les SSD 510 et 330 sont d'une épaisseur de 9.5mm tout comme le SSD 520, mais ce dernier est facilement transformable en 7mm en retirant une surcouche plastique noire située au-dessus du SSD, mais cela annule alors la garantie. On notera qu'Intel propose un logiciel de gestion assez complet sous Windows qui permet entre autre de lancer un TRIM sur l'espace libre sous Windows XP et Vista, une exception avec Samsung.


Du côté des spécifications officielles le SSD 510 affiche des performances assez modestes en termes d'accès aléatoire, que ce soit en lecture ou en écriture. Il répond par contre présent pour ce qui est du séquentiel.


Pour ce qui est du SSD 520 c'est le grand écart du côté de l'écriture selon le type de données, et on note une montée en puissance régulière au fil de l'augmentation de la capacité pour ce qui est de l'écriture séquentielle, l'écriture aléatoire étant en retrait sur la version 480 Go. Les spécifications du 330 ne sont pas communiquées pour ce qui est des données incompressibles.


A l'intérieur du SSD 510 120 Go on retrouve 16 puces IMFT gravées en 25nm qui sont adressées par une puce Marvell 88SS9174 soutenue par 128 Mo de cache DRAM Hynix.


Le SSD 520 120 Go est pour sa part composé d'un contrôleur SandForce SF-2281 et de 8 puces IMFT 25nm.


En dehors de la couleurs du PCB (sic!) rien ne permet de distinguer physiquement un SSD 330 d'un SSD 520.


Page 14 - Kingston V200 et V300 en test

Kingston V200 et V300 en test
Géant mondial de la mémoire, Kingston s'attaque depuis quelques temps déjà au marché du SSD avec sa gamme SSDNow. Initialement Kingston se contentait de revendre sous sa propre marque des X25-M Intel, puis les gammes V et V+ ont été fabriquées en association avec Toshiba qui fournissait la NAND pour les deux et un contrôleur maison pour le V+, le V utilisant une puce JMicron remarquée.


Depuis Kingston s'est un peu plus rapproché des solutions traditionnelles et utilise les combinaisons SandForce SF-2281 + IMFT 25nm synchrone sur l'HyperX (soit la même chose que les Corsair Force GT et OCZ Vertex 3) et SandForce SF-2281 + IMFT 25nm asynchrone sur les SSDNow V+ 200 (équivalent Corsair Force 3 et OCZ Agility 3). Pour plus d'originalité ce sont vers le Kingston SSDNow V200 et V300 que nous nous tournons puisqu'il s'agit de combinaisons inédites : JMicron JMF66x + NAND Toshiba 24nm d'un côté, SandForce SF-2281 + NAND Toshiba 19nm de l'autre.


Le SSDNow V200 fait 7mm de haut en versions 64 et 128 Go et 9.5mm en version 256 Go, le V300 7mm dans les trois versions 60, 120 et 240 Go. Ils sont garantis 3 ans et trouvables en version nue mais aussi en version boite en :

- kit de mise à jour pour PC portable : Logiciel de clonage, vidéo d'installation, entretoise pour porter la hauteur à 9.5mm, boitier USB 2.0 externe
- kit de mise à jour PC de bureau : Logiciel de clonage, vidéo d'installation, adaptateur 3.5", câble SATA et adaptateur d'alimentation Molex vers SATA
- kit complet : Tout !


On ne peut que saluer Kingston pour ces versions boites très complètes.


Les spécifications officielles montrent que l'interface SATA 6G n'est pas saturée par le V200, même en lecture. Les écritures aléatoires semblent également un point faible sur ce SSD, bien que le niveau atteint soit largement suffisant pour une utilisation desktop. Côté V300, SandForce oblige on ne peut pas vraiment se fier à ces données obtenues avec des données compressibles.


A l'intérieur du V200 on trouve donc 8 puces Flash NAND MLC fabriquées par Toshiba en 24nm, qui ne bénéficient pas a priori d'un bus de type Toggle. Elles sont accompagnées de 2x128 Mo de DDR2 ProMos qui sont gérées par un contrôleur Toshiba qui est en fait un JMicron SATA 6G, probablement le JMF661 qui gère la Flash sur 4 canaux, contre 8 pour le JMF662, au vue des performances annoncées.


Les entrailles du V300 sont composées du SandForce SF-2281 et de 16 puces Flash NAND MLC gravées en 19nm d'après les dires de Kingston et… marquées par Kingston, alors qu'on s'attendait à voir le logo Toshiba ! On ne sait pas si il s'agit d'un simple remarquage ou si Kingston, comme OCZ avec IMFT, va jusqu'à acheter des wafer à Toshiba.

Mise à jour du 28/02/2014 : Attention, depuis quelques semaines Kingston livre des V300 dotés de mémoire Flash asynchrone bien moins rapide, cf. cette actualité !


Page 15 - OCZ Vertex 3.20 et Max IOPS en test

OCZ Vertex 3.20 et Max IOPS en test
Nous n'avons pas intégré dans ce comparatif les Vertex 3 et Agility 3 d'OCZ, qui sont similaires aux Force GT et Force 3 de Corsair. OCZ propose par contre un SSD original à base de SandForce SF-2281, le Vertex 3.20, et proposait à la première de ce publication de ce comparatif également le Vertex 3 Max IOPS.


Derrière le Vertex 3 Max IOPS se cache en fait l'association de la puce SandForce avec de la mémoire annoncée comme plus rapide et plus endurante que la 25nm IMFT synchrone, de la Toshiba 32nm Toggle. Il mesure mesure 9.5mm de hauteur, est livré avec un adaptateur 3.5" et ses vis et est garanti 3 ans.

Le Vertex 3.20 fait pour sa part appel à de la mémoire IMFT 20nm synchrone, il s'agit à notre connaissance du seul SSD à base de SandForce dans cette configuration. Il mesure 9.5mm, est livré "nu" mais la garantie reste de 3 ans.

Pour le reste on retrouve une configuration classique et des capacités de 120 et 240 Go accessibles à l'utilisateur, 8 Go étant réservé au RAISE dans un cas et 8 Go au RAISE et 8 Go à l'overprovisionning dans l'autre cas.



A l'intérieur on retrouve le SandForce SF-2281 et 8 puces de 16 Go Toshiba 32nm Toggle, et aucun cache de type DRAM comme c'est l'habitude chez SandForce.


L'OCZ Vertex 3.20 utilise pour sa part un SandForce SF-2281 et 16 puces de 8 Go IMFT 20nm. Contrairement au Crucial M500, les puces utilisées ici intègrent des dies de 64 Gb qui ont donc l'avantage d'utiliser des pages de 8 Ko seulement. Cela devrait être payant côté performances, et il faut espérer qu'OCZ ne changera cet ensemble pour 8 puces de 16 Go à base de die 128 Gb.


Page 16 - OCZ Vertex 4, Agility 4, Octane, Petrol en test

OCZ Vertex 4, OCZ Agility 4; Octane et Petrol en test
Lancés en fin d'année 2011, les OCZ Octane et Petrol utilisent tous deux le contrôleur SATA 6G Indilinx Everest. Pour rappel, OCZ a racheté l'an passé Indilinx, ce qui lui permet désormais de prendre ses distances avec SandForce afin de proposer des SSD aux caractéristiques originales.

Les OCZ Vertex 4 et Agility 4 annoncés en avril et mai 2012 continuent sur la même lancée mais utilisent désormais la version 2 de l'Everest. Il faut toutefois noter que si du point de vue firmware les Everest sont exclusifs à Indilinx, le hardware qui l'exécute n'est autre qu'un contrôleur Marvell.

Enfin le Vector utilise le tout dernier contrôleur Indilinx, le Barefoot 3. Cette fois, hardware _et_ software sont "maison" ! Les combinaisons sont les suivantes :

- Petrol : Indilinx Everest + Flash Hynix 2xnm
- Octane : Indilinx Everest + Flash IMFT 25nm synchrone
- Agility 4 : Indilinx Everest 2 + Flash IMFT 25nm asynchrone
- Vertex 4 : Indilinx Everest 2 + Flash IMFT 25nm synchrone


Ils font tous 9.5mm d'épaisseur et seul le Vertex 4 est livré avec un adaptateur 3.5". La garantie est de 3 années pour les Petrol (64 et 128 Go) et Octane (64, 128, 256, 512 Go et 1 To) mais passe à 5 ans sur les Vertex 4 (128, 256 et 512 Go).


Les spécifications officielles de l'OCZ Petrol laissent entrevoir des performances assez modestes pour ce qui est des lectures aléatoires, l'Octane étant mieux pourvu de ce côté. Mais c'est le Vertex 4 qui se démarque ici avec des performances de très haut vol dans tous les domaines. L'Agility 4 bien qu'un peu en retrait ne démérite pas complètement. Ces chiffres sont toutefois à relativiser puisqu'obtenus avec une technique assez particulière que nous avons décrite sur cette page : Indilinx Everest 2 / Barefoot 3 et débits : attention !


Les entrailles du Petrol montrent un contrôleur Indilinx IDX300, 2 puces de 256 Mo de DRAM et 16 puces de 8 Go de Flash Hynix 2xnm qui ne disposent pas a priori d'un bus haute performance de type Toggle ou ONFI synchrone.


A l'intérieur de l'Octane on trouve le contrôleur Indilinx IDX300 bien entendu mais aussi 2 puces de 256 Mo de DRAM ainsi que 16 puces de 8 Go de Flash IMFT 25nm synchrone.


L'Agility 4 intègre un contrôleur Indilinx IDX400, deux puces de 256 Mo de DRAM et 16 puces de 8 Go de Flash IMFT 25nm asynchrone.


Le Vertex 4 est équipé en son sein d'un Indilinx IDX400, de deux puces de 256 Mo de DRAM et de 16 puces de 8 Go de Flash IMFT 25nm synchrone.


Page 17 - OCZ Vector, Vector 150 et Vertex 450 en test

OCZ Vector, Vector 150 et Vertex 450 en test
Alors que la plateforme Indilinx Everest associait en fait une puce Marvell et un firmware Indilinx, l'Indilinx Barefoot 3 est une puce maison. Elle est déclinée chez OCZ sur trois SSD :

- Vector : Indilinx Barefoot 3 + Flash IMFT 25nm synchrone
- Vector 150 : Indilinx Barefoot 3 + Flash Toshiba 19nm toggle
- Vertex 450 : Indilinx Barefoot 3 + Flash IMFT 20nm synchrone





Ces SSD ont en commun une coque identique de 7mm d'épaisseur au travers de laquelle OCZ a décidé de faire "ressentir" la qualité du SSD avec 117g environ sur la balance, là ou un Samsung 840 Pro est par exemple à 51g. Si effectivement en main le SSD fait plus "solide", ceci n'est qu'un détail futile qui sera au final dérangeant pour une intégration dans un portable.

Ils sont tous trois livrés avec une version d'Acronis True Image, et les Vector et Vector 150 y ajoutent un adaptateur 3.5" qui se fait de plus en plus rare dans les bundle. La garantie des deux Vector est de 5 ans, mais celle du Vertex 450 de 3 ans. Il faut noter que si le Vertex 450 devait supporter l'AES-256, seul le Vector 150 conserve la mention de ce codage sur sa fiche technique officielle.


Les performances officielles de tous ces SSD sont proches, seul le Vertex 450 128 Go dénote un peu en écriture. Il faut toutefois préciser que ces chiffres sont obtenus par une technique assez particulière que nous avons décrite sur cette page, ils ne sont pas valables dans tous les cas de figure : OCZ Indilinx Everest 2 / Barefoot 3 et débits : attention. On notera que sur le Vector 150 a fait le choix d'intégrer un espace flash sur-réservé ce qui réduit l'espace utilisateur disponible. Ceci permet en contrepartie de maintenir un très bon niveau de performances et une amplification en écriture réduite en écritures aléatoires même en l'absence de TRIM, domaine dans lequel le Barefoot 3 était déjà bon comme nous l'avions notamment noté dans le comparatif des SSD 480-512 Go.


On trouve dans le Vector un Indilinx IDX500, deux puces de 256 Mo de DRAM et 16 puces de 8 Go de Flash. Elles arborent le logo OCZ, il s'agit en fait de wafer vendus par IMFT à OCZ qui se charge du découpage des puces et de leur packaging.


Le Vector 150 arbore le même contrôleur et également deux puces de 256 Mo de DRAM. 8 puces de 16 Go de Flash (intégrant chacune 2 die 8 Go) Toshiba 19nm toggle sont présentes.


Enfin le Vertex 450 intègre lui aussi un Indilinx IDX500, toujours un total de 512 Mo de DRAM et 16 puces de Flash IMFT 20nm, qui sont cette fois packagées par Micron lui-même.


Page 18 - Plextor M5 Pro, Plextor M3 Pro, M5S et M3 en test

Plextor M5 Pro, Plextor M3 Pro, M5S et M3 en test
Pour les plus anciens d'entre vous, Plextor est synonyme de produit de qualité, notamment dans le domaine des lecteurs et des graveurs de CD. Il y a 3 ans environ Plextor a été racheté par PLDS, une joint-venture crée en 2007 par Philips et Lite-On IT dédiée au ODD (lecteur et graveur optique), et depuis la société tente de s'introduire sur le marché du SSD avec des SSD à base de Marvell.


Lancés en début d'année les M3, M3 Pro et M5S utilisent tous trois un contrôleur Marvell 88SSE9174 associé à de la mémoire Flash Toshiba 24nm Toggle pour les deux premiers et à de la mémoire IMFT 25nm pour le dernier. Si les M3 et M3P sont donc équivalent point de vue matériel, ce dernier dispose d'un firmware permettant d'obtenir d'encore meilleures performances en écriture.

Le M5 Pro est le dernier né des SSD Plextor et il utilise deux nouveautés, côté contrôleur tout d'abord avec le Marvell 88SS9187 qui apporte entre autre une correction d'erreur plus poussée (128 bits) et un codage AES 256 bits, et côté mémoire avec de la Flash Toshiba 19nm Toggle, qui a pour principal intérêt d'être moins onéreuse à produire.


Les M3 et M5S font 9.5mm de hauteur et sont garantis 3 ans, contre 7mm et 5 ans pour les M3 Pro et M5 Pro. Les M3, M3 Pro et M5 Pro sont livrés avec un adaptateur 3.5", la visserie nécessaire, le logiciel de clonage Acronis True Image HD OEM alors que le M5S est livré nu. Si les M3 et M3 Pro disposent d'une garantie durant laquelle Plextor fera passer un transporteur à sa charge chez vous pour récupérer le SSD pour l'Union Européenne, la Norvège et la Suisse (une année ailleurs), ce n'est plus le cas des M5S et M5 Pro. Si cela va de pair avec une baisse significative de prix, pourquoi pas, sinon c'est une mauvaise nouvelle.


Les spécifications montrent que le M3P apporte un gain important par rapport au M3 en écriture séquentielle et aléatoire, surtout sur la version 128 Go. La version 64 Go du M3 ne semble pas souffrir de gros bridage sur ses performances. A contrario le M5S souffre en écriture dans cette configuration. La version 128 Go du M5S est assez proche du M3, et en 256 Go elle est un peu plus rapide.

Les gains du M5P sur le M3P se font surtout dans le domaine de l'aléatoire sur les versions 128 et 256 Go. C'est surtout la version 512 Go qui profite le plus de ce changement de génération puisqu'elle reste proche de la version 256 Go en aléatoire.


A l'intérieur du Plextor M3 on retrouve le Marvell 88SS9174 accompagné de 256 Mo de cache DRAM (il est 128 Mo sur la version 64 Go et 512 Mo en 256 Go) et de 8 puces de 16 Go de Flash Toshiba 24nm Toggle.


Le Plextor M3P n'est pas vraiment différent puisqu'à côté du Marvell 88SS9174 on retrouve 256 Mo de cache DRAM (512 Mo pour les versions 256 et 512 Go) et 8 puces de 16 Go de Flash Toshiba 24nm Toggle.


Le M5S utilise un autre PCB. Le Marvell 88SS9174, les 256 Mo de cache DRAM (il est 128 Mo sur la version 64 Go et 512 Mo en 256 Go) et les 8 puces de 16 Go de Flash IMFT 25nm synchrone sont situées du même côté.


Enfin le M5P reprend le PCB des M3. A gauche on retrouve donc le nouveau Marvell 88SS9187 et à droite les 256 Mo de cache DRAM (512 Mo en version 256 Go et 768 Mo en version 512 Go) et 8 puces de 16 Go de Flash Toshiba 19nm Toggle.


Page 19 - Samsung 840 Pro, 840 EVO, 840 et 830 en test

Samsung fait figure d'exception au sein de ce comparatif puisqu'il s'agit du seul constructeur qui peut se targuer, depuis l'abandon des contrôleurs par Intel, de maitriser de A à Z la production d'un SSD, que ce soit au niveau du contrôleur, de la mémoire Flash, de la mémoire cache DRAM mais aussi bien entendu du firmware.

Après le 830, un best-seller, Samsung a lancé il deux nouvelles références, les 840 et 840 Pro, en septembre 2012. A la rentrée 2013 le 840 Pro a été remplacé par un nouveau modèle, le 840 EVO. Attention, contrairement à ce que l'on pourrait penser au premier abord le 840 Pro est le vrai "successeur" du 830.


Tous ces SSD font 7mm d'épaisseur. Si le 830 était décliné en versions 64, 128, 256 et 512 Go, la plus petite capacité est absente des gammes 840 et 840 Pro qui sont respectivement disponibles en 120/250/500 Go et 128/256/512 Go. Le 840 EVO ajoute aux capacités du 840 des versions 750 et 1 Go.


L'espace utilisateur inhabituel fournit par Samsung sur les 840 et 840 EVO est lié à la mémoire utilisée sur ce SSD : de la TLC 21nm ou 19nm annoncée à 1000 cycles d'écritures, soit 3 fois moins que la MLC 21 ou 27nm des 840 Pro et 830. La TLC est moins endurante que la MLC car on stocke 3 bits par cellule Flash ce qui correspond à 8 niveau de tension possible contre 4 en MLC (et 2 en SLC). La programmation de ce niveau de tension est donc plus long ce qui stresse (et use) plus la cellule. L'écriture devant se faire en plusieurs passes, elle est également plus lente.

Attention toutefois à ne pas faire dans l'alarmisme inutile, 1000 cycles sont suffisant pour un usage classique : cela correspond par exemple sur un SSD 128 Go à 5 ans et 10 mois avec 20 Go d'écritures par jour et une amplification en écriture assez élevée de trois (et donc 11 ans et 8 mois sur un 256 Go). Reste que Samsung a toutefois fait preuve de prudence sur le 840 en réservant d'office une partie de la Flash pour l'over-provisionning, ce qui permettra de limiter l'usure de la Flash en limitant par exemple l'amplification d'écriture dans un environnement ne supportant pas le TRIM comme nous l'avons vu précédemment.

Sur le 840 EVO l'espace est utilisé pour contrecarrer l'autre défaut inhérent à la TLC, la relative lenteur d'écriture. TurboWrite permet donc pendant un temps d'améliorer cette vitesse d'écriture en utilisant une partie de cellules TLC en mode SLC comme nous l'expliquons ici. Alors oui, les débits sur une écriture courte (jusqu'à 3 Go d'une traite sur les 120/250 Go, 6 Go sur le 500 Go par exemple) sont plus élevés mais on perd l'over-provisionning du 840 et l'usure de la Flash est augmentée puisque les données écrites dans en mode SLC dans les cellules sont ensuite réécrites en mode TLC dans d'autres. Un choix intéressant pour afficher de gros débits dans les fiches produit, mais est-il vraiment bon pour les utilisateurs ? On peut en douter.

Les Samsung 830, 840, 840 Pro et 840 EVO sont trouvables en version nue mais aussi en kit desktop (adaptateur 3.5", câble SATA, adaptateur Molex vers SATA, Norton Ghost 15) ou Notebook (entretoise pour passer à 9.5mm, câble SATA vers USB, Norton Ghost 15) comme le fait par exemple Kingston.

Ils sont garantis 3 ans (830, 840, 840 EVO) et 5 ans (840 Pro) et livrés avec un utilitaire assez complet qui permet entre autre de lancer un TRIM sur l'espace libre sous Windows XP et Vista, une exception partagée avec l'Intel Toolbox. Il faut noter que le dernier firmware du 840 EVO rend son codage AES 256 bits compatible IEEE1667 et TCG Opal 2.0, ce qui permet l'usage du codage matériel par BitLocker sous Windows 8 via le standard Microsoft eDrive.


Les performances officielles font état de très haut niveau de performances en lectures quelques soit le modèle. En écriture séquentielle c'est comme d'habitude variable en fonction de la capacité mais aussi du modèle puisque le 840 souffre ici de ce côté de la présence de mémoire TLC. En écriture aléatoire par contre les gains sont importants par rapport au 830 et ce même sur le 840 dès lors qu'on s'attaque aux capacités de 250 et 500 Go - le 830 étant semble-t-il bridé par son firmware de ce côté. Le 840 EVO atteint en TurboWrite des débits en écriture notablement plus élevés que sans.




Au sein du Samsung 830 on trouve donc le contrôleur Samsung S4LJ204X01 accompagné de 256 Mo de DDR2 Samsung et de seulement 4 puces Flash Samsung de 32 Go pièce. Bien entendu il n'est pas possible d'atteindre une telle capacité sur un seul die et chaque puce en combine en fait 4. Cette mémoire est gravée en 27nm et utilise un bus de type Toggle mode.


Le 840 Pro intègre un contrôleur Samsung S4LN021X01, toujours 256 Mo de mémoire et 4 puces de Flash Samsung combinant chacune 4 die 21nm MLC.


Le 840 reprend une configuration similaire au 840 Pro si ce n'est la mémoire qui est désormais de type 21nm TLC.


Sur le 840 EVO le contrôleur est un S4LN045X01, une évolution un peu plus véloce fonctionnant à 400 MHz au lieu de 300 MHz. On retrouve là encore 256 Mo de mémoire et 2 puces de Flash combinant chacune 4 die de 16 Go de TLC 19nm.


Page 20 - Sandisk Extreme II, Ultra Plus, Extreme et SSD en test

Sandisk Extreme II, Ultra Plus, Extreme et SSD en test
Sandisk est un acteur important du marché de la Flash. Au sein de l'alliance Flash Forward avec Toshiba tout d'abord, il est à la pointe pour ce qui est de la fabrication avec des puces actuellement fabriquées en 24nm et 19nm. Mais Sandisk est surtout connu du public pour ses produits à base de Flash tels que les cartes mémoires et les clefs USB.

Depuis quelques années Sandisk s'intéresse bien entendu aux SSD, avec un succès assez variable puisque le Sandisk G3 utilisant un contrôleur maison ne nous avait par exemple pas convaincu en 2010. A compter de 2012 Sandisk a décidé de faire confiance à des contrôleurs tiers.


Cela a commencé par la gamme Extreme, combinant l'habituel SandForce SF-2281 SATA 6G avec de la 24nm Toggle Sandisk, et Sandisk a ensuite lancé début 2013 l'Ultra Plus utilisant un Marvell 88SS9175, une version allégée du 888SS9174 ne supportant que 4 canaux au lieu de 8, et de la MLC 19nm Toggle Sandisk. Entre les deux une autre gamme de SSD qui n'a pas vraiment de nom et que nous nommeront simplement Sandisk SSD a fait son apparition. Elle utilise cette fois un contrôleur maison, le Sandisk SDC1, combiné à de la 19nm Toggle Sandisk.

Enfin Sandisk a lancé en juin 2013 l'Extreme II, combinant le dernier contrôleur Marvell 88SS9187 gérant la flash sur 8 canaux avec de la MLC 19nm Toggle Sandisk. A contrario des autres SSD qui se limitent à 3 ans de garantie, elle est de 5 ans sur les Extreme II. L'Extreme fait 9.5mm d'épaisseur contre 7mm pour ses compères. L'Ultra Plus et l'Extreme II sont fournis avec un adaptateur pour les passer à une hauteur de 9.5mm.

Tous sont garantis 3 ans, l'Extreme fait 9.5mm de hauteur contre 7mm pour les Ultra Plus et SSD. L'Ultra Plus est fournit avec un adaptateur 9.5mm, en dehors de ça la boite contient uniquement un petit manuel.


Les spécifications officielles de l'Extreme ne font état que des performances avec des données fortement compressibles, ce qui permet d'afficher des débits séquentiels très importants et illusoires en écriture. On peut par contre voir que les lectures aléatoires augmentent avec la capacité et que la version 480 Go souffre en écriture aléatoire par rapport à la 240 Go.

Les caractéristiques de l'Ultra Plus laissent entrevoit de bons débits malgré l'utilisation de 4 canaux, et les spécifications de l'Extreme II laissent entrevoir des performances encore meilleures. Sa capacité utilisable est un peu moindre du fait d'un overprovisionning obligatoire. Le Sandisk SSD affiche des débits séquentiels importants mais des chiffres aléatoires assez faibles pour un SSD, même si ils restent 20 à 50x supérieurs à ceux d'un disque dur.


Au sein du Sandisk Extreme on retrouve donc le SandForce SF-2281 et 4 puces de Flash Sandisk 24nm Toggle de 32 Go pièce intégrant chacune 4 die de 8 Go.


Ouvrir le Sandisk SSD est quasiment impossible, la fermeture se fait par un système de clips plastiques et une fois le tout monté bon courage pour l'ouvrir. Contrairement aux Samsung 840 et 840 Pro on ne trouve pas vraiment d'information sur le contenu de ce SSD et nous nous devions donc de l'ouvrir, il a donc fallu passer par quelques coups de … marteau. Une fois ouvert on découvre un tout petit PCB avec le contrôleur Sandisk SDC1 et 4 puces de Sandisk de 32 Go intégrant chacune 8 dies de 8 Go. On notera que le SDC1 n'est pas épaulé par une DRAM externe dont seul SandForce a su se passer sans nuire aux performances jusqu'alors.


Le Sandisk Ultra Plus s'ouvre sans encombre grâce aux vis placées sous l'étiquette principale. Il utilise également un PCB de taille très réduite au sein duquel on trouve le Marvell 88SS9175, 64 Mo de DRAM Samsung et deux puces de Flash 19nm intégrant chacune 8 dies de 8 Go. Il faut noter qu'une partie de la Flash serait utilisée en mode SLC, ce que Sandisk appelle nCache. Malheureusement nous n'avons pu obtenir aucun détail précis à son sujet et n'avons pas pu mettre en évidence sa présence dans les tests de performances.


Au sein de l'Extreme II on trouve le Marvell 88SS9187 accompagné de 256 Mo de DRAM et de 4 puces de Flash 19nm dont ne sait pas si elles intègrent des die 8 ou 16 Go. Là encore le contrôleur est censé utiliser un mode SLC appelé nCache qui nous n'avons pas pu voir lors de nos tests. On note au dos du PCB de nombreux emplacements vides destinés à accueillir des condensateurs sur une version professionnelle qui sera alors protégée contre la perte de de donnée en cas de coupure de courant.


Page 21 - Toshiba THNSNHxxxGCST / Q Series en test

Toshiba THNSNHxxxGCST / Q Series en test
Toshiba est associé à Sandisk au sein de l'alliance Flash Forward pour la fabrication de la mémoire Flash. Comme IMFT et au contraire de Samsung une partie de la Flash produite est revendue, les puces MLC 19nm étant notamment utilisées sur des SSD OCZ, Corsair et Kingston.

Toshiba propose depuis longtemps des SSD sous sa propre marque mais il n'a jamais vraiment réussi à percer sur le marché des SSD vendus seuls, se concentrant plutôt sur les OEMs. Plutôt qu'une entrée directe sur le marché, Toshiba avait un temps conclu un partenariat avec Kingston qui vendait de nombreuses références utilisant de la mémoire et un contrôleur Toshiba sous sa propre marque.


Le SSD testé est une version OEM, THNSNH128GCST, que l'on trouve également en version non-OEM sous la dénomination Q Series. D'apparence assez brute (la version Q Series a une étiquette de plus), il fait 7mm de hauteur et il faut noter que sa garantie n'est que de deux ans en Europe, une exception puisque sur les SSD les garanties sont généralement de 3 ou 5 ans.


Les caractéristiques officielles sont pour le moins impressionnantes avec des débits en écritures élevés ce dès la version 128 Go. Les écritures aléatoires sont un peu retrait par rapport à ce qu'annoncent d'autres SSD, mais à des niveaux très largement suffisant pour n'importe quel usage autre qu'un serveur de base de donnée soumis à une charge soutenue. Il faut toutefois beaucoup relativiser le débit en écriture annoncé par Toshiba puisqu'il n'est en fait soutenu que sur la moitié du SSD !

A l'instar d'OCZ sur ces derniers SSD, Toshiba utilise en effet prioritairement les pages Flash correspondant au premier bit de chaque cellule Flash. Ainsi, la première moitié des LBA (adresses logiques vue par l'OS) écrites sur le SSD sont associées à des pages Flash utilisées en mode SLC (un bit par cellule). A contrario, pour la deuxième moitié des LBA l'écriture se fait bien plus lentement ! Ce mécanisme est décrit sur cette page.


A l'intérieur du Toshiba THNSNH128GCST un contrôleur marqué Toshiba et Marvell. Rien ne permet de savoir de quel contrôleur Marvell il s'agit, et il n'est associé à aucune mémoire DRAM ce qui est une première chez Marvell. Combiné au mode SLC, ceci laisse à croire que le firmware a été fortement personnalisé par Toshiba. 4 puces de Flash 19nm toggle Toshiba sont intégrées, on ne connait pas la capacité de chaque die.


Page 22 - Protocole de test

Protocole de test
Tester les SSD de manière correcte nécessite des logiciels adaptés, ce qui n'est pas le cas de tous. Des outils tels que h2bench, HD Tune ou HD Tach ont été prévus à la base pour les disques durs et peuvent opérer sur des zones vierges de données par exemple.

Ils peuvent alors être trompés lors des mesures de lectures, les lectures aléatoires étant transformées en lectures séquentielles par certains contrôleurs quand le SSD est vide ! De même, ces logiciels tout comme ATTO Disk Benchmark n'écrivent que des suites binaires de 0 ou de 1, ce qui permet aux contrôleurs dotés d'algorithme de compression temps réel d'arriver à des ratios de compression bien supérieurs à ceux obtenus avec de véritables données, de quoi gonfler artificiellement leurs résultats.

Même les logiciels spécialisés ne sont pas exempts de défauts puisque si CrystalDiskMark par exemple permet de tester rapidement un SSD, il ne donne que des résultats partiels dans le cadre d'un comparatif. Ainsi son fichier de test n'est que de 4 Go dans le meilleur des cas, ce qui fait que les tests aléatoires n'adressent le support que sur un espace assez restreint ce qui avantage certains contrôleurs (cf. cette actualité).


Les performances dites synthétiques sont donc mesurées à l'aide de cette formidable boite à outil qu'est IOMeter. Les performances sont mesurées dans plusieurs cas, avec une durée de 2 minutes à chaque fois :

- Lectures séquentielles par blocs de 2 Mo
- Lectures aléatoires par bloc de 4 Ko
- Ecritures séquentielles par blocs de 2 Mo
- Ecritures aléatoires par bloc de 4 Ko

Ceci permet de voir le débit du support de stockage en terme de débit mais aussi d'entrées / sorties. Les tests sur des blocs de 4 Ko sont faits avec 1, 2, 4, 8, 16 et 32 commandes simultanées afin de mettre en avant la possibilité qu'a le contrôleur de paralléliser ces accès. Etant donné qu'il est très rare en usage desktop d'avoir besoin de plus de 4 accès simultanés, et pour une plus grande lisibilité des graphiques, seules les résultats jusqu'à 4 commandes sont donc reportés.

En lecture séquentielle, nous effectuons le test avec 1, 2 et 4 commandes, le résultat reportés étant la moyenne des trois, et en écriture séquentielle, avec une seule commande. Ces tests sont effectués uniquement avec des données incompressibles par la compression en temps réel du contrôleur SandForce, alors qu'auparavant nous donnions les résultats avec des données incompressibles et des données compressibles.

Viennent ensuite des tests pratiques, avec pour commencer l'écriture et la lecture de divers ensembles de fichiers. Ces fichiers sont composés de la sorte :

-Extra : 731,17 Mo de moyenne
-Gros : 5,20 Mo de moyenne
-Moyens : 800,88 Ko de moyenne
- Petits : 48,78 Ko de moyenne

La source ou la cible lors de la lecture ou de l'écriture sur le SSD est un Ramdisk de 8 Go. Vu la rapidité des SSD récents et afin d'avoir des résultats moins sujets à variation, nous utilisons Robocopy avec un logiciel maison qui permet de faire les tests en boucle. Chaque test est effectué 5 fois de suite nous effectuons la moyenne des 3 scores intermédiaires.

Suivent pour finir des tests purement pratiques, à savoir diverses opérations chronométrées après copie d'une image système sur chacun des SSD :

- Démarrage de Windows 7
- Démarrage de 3D Studio Max 2011
- Démarrage de 3D Studio Max 2011 + Visual Studio 2010 + Bibble Pro 5
- Rescan du code source d'Ogre sous Visual Studio 2010
- Régénération des aperçus d'un répertoire de 48 RAW sous Bibble 5 Pro
- Lancement de Battlefield 3
- Lancement d'un niveau de Battlefield 3

Attention ces chronométrages ne sont pas comparables à ceux des précédents tests. D'une part, le processeur est cette-fois overclocké à 4.5 GHz, d'autre part pour Windows 7 nous mesurons désormais le temps entre le début du démarrage de Windows (après le menu de démarrage accessible via la touche F8) et l'apparition du bureau.

Pour 3d Studio Max 2011 il s'agit du délai entre le lancement et l'apparition de la fenêtre d'astuces, alors que le démarrage multi-applicatif est fait via un batch. Le code source du moteur 3D Ogre est utilisé sous Visual Studio 2010 alors qu'un répertoire contenant 48 RAW issus d'un 5D mark II sert de base au test sous Bibble 5 Pro. Pour Battlefield 3 nous mesurons le temps de lancement du jeu entre la validation du mot de passe Origin et le début des vidéos d'introduction, et le chargement d'un niveau entre la validation de la reprise de la campagne (mission 7 – Thunder Run) et l'apparition de l'image à l'écran. Toutes ces mesures sont effectuées en chronométrage manuel 5 fois, avec une extinction de la machine entre chaque mesure. Nous effectuons la moyenne des 3 scores intermédiaires.


En sus des SSD SATA 6G 120 à 128 Go du comparatif, nous intégrons les performances à titre informatif obtenues sur un Intel X25-M "Postville" 120 Go, une gamme lancée pour rappel en juillet 2009 (cf. notre test)


Nous effectuons enfin des tests de tenue de performance en écriture que nous détaillons dans la page dédiée à ce sujet. Le système de test est composé d'une carte mère Intel DP67BG (P67 Express) associé à 16 Go de DDR3-1600 et un Core i7-2600K, le tout sous Windows 7 SP1 64 bits.


Page 23 - Débits séquentiels

Lecture séquentielle
On commence par les débits séquentiels qui sont pour rappels mesurés avec IOMeter et des blocs incompressibles de 2 Mo avec 1, 2 et 4 commandes simultanées pendant 2 minutes. Nous reportons ici la moyenne obtenue dans ces trois cas :


De nombreux SSD parviennent à dépasser la barre des 500 Mo /s : Corsair Neutron et Neutron GTX/GTX "B", Crucial M4, OCZ Vector, Vector 450, Plextor M3, M3P, M5S et M5P ainsi que les Samsung 830, 840, 840 EVO, 840 Pro et le Sandisk Extreme II. Avec 497 et 493 Mo /s, le Crucial M500 et l'Intel SSD 520 échouent de peu.

En queue de peloton on trouve le Corsair Force 3 qui est pénalisé par sa NAND asynchrone malgré ses spécifications officielles avec seulement 198 Mo /s en lecture, ce qui n'est pas digne d'un SSD en SATA 6G. Un vieil X25-M est ainsi supérieur, mais si les OCZ Agility 4, Kingston V200 et OCZ Petrol font un peu mieux leurs scores ne sont pas non plus fantastiques, et dans le cas de l'Agility 4 on est très loin des 420 Mo /s annoncés par OCZ.
Ecriture séquentielle
Toujours avec IOMeter, on mesure les performances en écriture séquentielle avec des blocs incompressibles de 2 Mo et 1 commande pendant 2 minutes :


Là c'est vraiment le grand écart entre les modèles et seuls deux SSD dépassent les 400 Mo /s, l'OCZ Vector 150 et le Toshiba Q Series. Mais attention, il s'agit pour rappel de débits en pointes, qui ne sont pas contreparties comme expliquées dans les pages "Attention !". Nous avons d'ailleurs barré le chiffre des SSD pour lequel le débit mesuré par notre protocole peut être éloigné du débit enregistré dans d'autres conditions.

Plusieurs SSD dépassent les 300 Mo /s sans faire usage de ce genre d'artifice, avec par ordre alphabétique Corsair Force GS, Neutron GTX et GTX "B", Plextor M3P et M5P, Samsung 840 Pro, Sandisk SSD et Sandisk Extreme II.

La dernière position est occupée par le X25-M V2 mais on ne lui en voudra pas vu son grand âge. De nombreux SSD sont sous les 150 Mo /s : Corsair Force 3, Crucial C300, Crucial M500, OCZ Petrol, Samsung 840/840 EVO et Sandisk Extreme. Le Crucial M500 souffre ici du nombre réduit de die NAND qu'il embarque, alors que le Samsung 840 est plus lent du fait de la TLC.

Pour rappel nous testons ici les versions 120/128 Go de ces SSD, en passant aux versions 240/256 puis 480/512 Go les performances augmentent généralement. Il ne faut pas non plus trop s'attarder sur les débits brut séquentiels, en effet il est très rare d'avoir besoin d'un débit en centaine de Mo /s pendant une durée importante.


Attention de nombreux SSD ne sont pas capable de maintenir de telles performances en écriture sur la durée, c'est notamment le cas de ceux à base de contrôleur Indilinx ou SandForce, nous vous donnons rendez-vous sur la page "Tenue des performances et TRIM" pour en savoir plus.


Page 24 - Lectures aléatoire

Lectures aléatoires
Toujours via IOMeter nous relevons les performances lors de lectures aléatoires par bloc de 4 Ko sur l'intégralité du SSD après que ce dernier ait été rempli de données incompressibles.

Ces mesures sont faites avec un nombre d'accès simultanés variant entre 1 et 32 pendant 2 minutes, ce qui permet de mettre en évidence la capacité du SSD à traiter en parallèle ces accès. Toutefois, sachant qu'en utilisation classique le nombre d'accès simultanés se situe plutôt entre 1 et 4, nous nous sommes ne reportons que les données jusqu'à 4 commandes pour des raisons de lisibilité.

En sus des accès aléatoires, nous reportons à titre informatif les valeurs pour les mêmes accès lorsqu'ils sont effectués en séquentiel.

[ Lectures aléatoires 4 Ko : IOPS ]  [ Lectures aléatoires 4 Ko : Mo /s]
[ Lectures séquentielles 4 Ko : IOPS ]  [ Lectures séquentielles 4 Ko : Mo /s ]


[ Lectures aléatoires 4 Ko : IOPS ]  [ Lectures aléatoires 4 Ko : Mo /s]
[ Lectures séquentielles 4 Ko : IOPS ]  [ Lectures séquentielles 4 Ko : Mo /s ]


Le SSD le plus rapide pour les accès aléatoires est le 840 Pro de Samsung, il est suivi de très par le Sandisk Extreme II, l'OCZ Vertex 4, le Sandisk Ultra Plus, le Plextor M5P, le Crucial C300 et enfin les Plextor M3 et M3P, Samsung 840 EVO et 840. Globalement les SSD à base de SandForce ne sont pas à l'aise dans cet exercice dès lors qu'il est effectué sur l'intégralité du SSD (ils s'en tirent mieux sur une zone réduite, cf. cette actualité) tout comme l'OCZ Petrol qui est nettement moins véloce que l'Octane. Mais la dernière place revient au Sandisk SSD qui est de loin le moins rapide.

Si on regarde les mêmes accès lorsqu'ils sont effectués en séquentiel on note du Sandisk Extreme II et des Samsung 840, 840 EVO et 840 Pro. Le Sandisk Ultra Plus n'est pas très éloigné de ce groupe de test. Certains SSD ont par contre un comportement étonnant avec des performances en lectures séquentielles qui ne sont pas nettement au-dessus de celles en aléatoires, c'est le cas des Corsair Neutron et Neutron GTX (mais pas de la version B), Kingston V200, OCZ Agility 4 et Vertex 4. Il s'agit clairement d'une faille dans le firmware étant donné le gap de performances par rapport aux SSD concurrents.


Page 25 - Ecritures aléatoires

Ecritures aléatoires
Nous passons cette fois aux mesures lors d'écritures aléatoires par bloc de 4 Ko de données incompressibles sur l'intégralité du SSD. Le test est effectué pendant 2 minutes avec un nombre d'accès simultanés variant entre 1 et 32. Là encore pour des raisons de lisibilité et étant donné l'usage qui est fait des SSD desktop nous ne reportons les valeurs sur le graphique que pour 1, 2 et 4 accès. En sus des écritures aléatoires, les écritures séquentielles sont reportées.

[ Ecritures aléatoires 4 Ko : IOPS ]  [ Ecritures aléatoires 4 Ko : Mo /s ]
[ Ecritures séquentielles 4 Ko : IOPS ]  [ Ecritures séquentielles 4 Ko : Mo /s ]


[ Ecritures aléatoires 4 Ko : IOPS ]  [ Ecritures aléatoires 4 Ko : Mo /s ]
[ Ecritures séquentielles 4 Ko : IOPS ]  [ Ecritures séquentielles 4 Ko : Mo /s ]


Si le dernier firmware du Kingston V200 a corrigé ses performances asthmatiques dans ce domaine, la place est désormais prise par le Sandisk SSD. Avec une commande, les Vector et Vector 150 sont les plus rapides, au-delà les bons chiffres affichés sont en partie liés au mode SLC et ne peuvent donc pas être soutenus dans tous les cas de figure. Ce n'est pas le as du Samsung 840 Pro qui affiche également un très bon niveau de performance même en augmentation le nombre de commandes, il est suivi des Corsair Neutron GTX et GTX "B".

Il faut toutefois noter que tous ces SSD offrent des performances très largement suffisantes pour une utilisation desktop qui ne fait pas appel à ce type d'écriture en masse. Seul le Sandisk SSD dénote vraiment, avec le X25-M qui est pardonné vu son vieil âge.

La mise en parallèle des écritures séquentielles et aléatoires a pour intérêt de mettre en avant les capacités du contrôleur à faire du write combining, c'est-à-dire à concaténer des écritures aléatoires en écritures séquentielles au niveau de la Flash. Plus les performances en aléatoire sont proches de celles en séquentielle, plus il est efficace. Avec une commande seuls le X25-M V2 et le Sandisk SSD sont nettement plus lent en aléatoire, le nouveau firmware ayant résolu ce souci sur le Kingston V200. Au-delà on perd notablement en efficacité mais il y'a des exceptions notamment du côté des Corsair Neutron et Neutron GTX, Crucial M4 et M500, les OCZ à base d'Everest 2 / Barefoot 3, les Plextor, les Samsung 840 (toute déclinaison).


Page 26 - Lecture et écriture de fichiers

Lecture et écriture de fichiers
On passe désormais aux tests pratiques, avec pour commencer l'écriture et la lecture de divers ensembles de fichiers. Ces fichiers sont composés de la sorte :


- Extra : 731,17 Mo de moyenne (vidéos)
- Gros : 5,20 Mo de moyenne (audio)
- Moyens : 800,88 Ko de moyenne (photo)
- Petits : 48,78 Ko de moyenne (fichiers divers)


La source ou la cible lors de la lecture ou de l'écriture sur le SSD est un Ramdisk. Vu la rapidité des SSD récents et afin d'avoir des résultats moins sujets à variation, nous utilisons Robocopy avec un logiciel maison qui permet de faire les tests en boucle. Seuls les petits fichiers sont ici compressibles par l'algorithme de compression SandForce.

[ Lectures de fichiers ]  [ Ecritures de fichiers ]

[ Lectures de fichiers ]  [ Ecritures de fichiers ]


En lecture de petits fichiers les SSD le plus véloce est le Corsair Performance Pro, suivi de près par les SSD à base de SandForce et le Toshiba Q Series, les OCZ en Everest 1 (Octane / Petrol) et les Samsung 840, EVO et Pro. Les SSD OCZ en Everest 2 (Vertex 4 et surtout Agility 4) sont à contrario en queue de peloton.

Lorsqu'on augmente la taille des fichiers les écarts se creusent et on retrouve en tête avec les fichiers dit extra les SSD qui affichaient les meilleures performances séquentielles, avec de nombreux modèles vers les 400 Mo /s.

En écriture les écarts sont plus marqués et le Sandisk SSD qui s'en tirait bien dans les tests synthétiques est à la rue dans ce test pratique. Le Q Series de Toshiba est en tête, mais c'est lié à son mode SLC déjà expliqué sur la page dédiée et nous avons d'ailleurs barré le score dans le graphique. Il en vas de même pour les Vector 150 et Vertex 4 qui le suivent, même si dans le cas d'OCZ le mode SLC est plus utilisable puisque le SSD essaie de libérer ce type d'espace tant que possible.

Parmi les SSD n'utilisant pas ce genre de technique c'est le Samsung 840 Pro qui tire son épingle du jeu, il est suivi par les Corsair Netruon GTX, les Plextor M3P et M5P et le Corsair Force GS. On notera le comportement des Sandisk Ultra Plus et Extreme II, qui contrairement aux autres SSD nécessitent des fichiers de très grande taille pour atteindre le débit en écriture maximums.

Attention de nombreux SSD ne sont pas capable de maintenir de telles performances en écriture sur la durée, soit parce qu'ils sont moins bons en cas de réécriture sur une zone déjà utilisée même avec le TRIM (ceux à base de SandForce), soit parce qu'ils utilisent un mode SLC qui rend les performances très variables en fonction de l'usage du SSD (les derniers OCZ et le Toshiba Q Series).


Page 27 - Tests pratiques

Tests pratiques
On passe à des tests purement pratiques, à savoir diverses opérations chronométrées après copie d'une image système sur chacun des SSD :

- Démarrage de Windows 7
- Démarrage de 3D Studio Max 2011
- Démarrage de 3D Studio Max 2011 + Visual Studio 2010 + Bibble Pro 5
- Rescan du code source d'Ogre sous Visual Studio 2010
- Régénération des aperçus d'un répertoire de 48 RAW sous Bibble 5 Pro
- Lancement de Battlefield 3
- Lancement d'un niveau de Battlefield 3

Attention ces chronométrages ne sont pas comparables à ceux des précédents tests. D'une part, le processeur est cette-fois overclocké à 4.5 GHz, d'autre part pour Windows 7 nous mesurons désormais le temps entre le début du démarrage de Windows (après le menu de démarrage accessible via la touche F8) et l'apparition du bureau.

Pour 3d Studio Max 2011 il s'agit du délai entre le lancement et l'apparition de la fenêtre d'astuces, alors que le démarrage multi-applicatif est fait via un batch. Le code source du moteur 3D Ogre est utilisé sous Visual Studio 2010 alors qu'un répertoire contenant 48 RAW issus d'un 5D mark II sert de base au test sous Bibble 5 Pro. Pour Battlefield 3 nous mesurons le temps de lancement du jeu entre la validation du mot de passe Origin et le début des vidéos d'introduction, et le chargement d'un niveau entre la validation de la reprise de la campagne (mission 7 – Thunder Run) et l'apparition de l'image à l'écran. Toutes ces mesures sont effectuées en chronométrage manuel 5 fois, avec une extinction de la machine entre chaque mesure. Nous effectuons la moyenne des 3 scores intermédiaires.


A titre informatif avec un disque dur Hitachi 7K3000 on met sur ce système 25.5 secondes pour Windows, 40.9s pour 3ds et 63.4s pour 3ds/VS/Bibble.

Nous l'avons déjà noté à de multiples reprises et ce dès notre comparatif de 2010, si les SSD creusent l'écart dans les tests applicatifs contre les disques durs, entre eux les différences sont plus minces sauf modèle à problème, et même le vieil X25-M Postville s'en tire bien ! Les écarts dans les tests synthétiques ne se retrouvent pas vraiment en pratique pour la simple et bonne raison que les données sont lues plus rapidement qu'elles ne peuvent être traitées, nous en avions apporté la preuve il y a un an en donnant des chiffres également très proches lorsqu'on utilisait un Ramdisk pourtant 10 à 15x plus rapide que les SSD.

Le gros avantage des SSD sur le disque dur est ici flagrant, c'est le peu d'écart qui sépare le lancement de 3d studio max seul de celui où l'on combine 3 applications. Bien entendu on ne lance pas souvent 3 applications en même temps, mais le but est ici de montrer que les SSD permettent de conserver une excellente réactivité du système même en cas d'utilisation du système de stockage par plusieurs tâches simultanées là ou un HDD sera bien à la peine.

Il est difficile de désigner un vainqueur puisque les écarts sont sommes toutes assez faibles, par contre certains modèles dits de nouvelle génération sont un peu à la traîne. Le plus lent est ainsi l'OCZ Petrol, suivi par l'OCZ Agility 4 et le Sandisk SSD. Le Kingston V200, l'OCZ Octane et le Vertex 4, bien que bien plus proches du gros de la troupe, sont également en léger retrait, mais leurs successeurs les V300 et Vector font mieux.


Cette fois l'Hitachi 7K3000 est à 19.2s pour Visual Studio et 28.9s pour Bibble. Les SSD sont de nouveau très proches, les OCZ Petrol / Agility 4 et le Kingston V200 étant un peu à la traine.


Un Hitachi 7K3000 met ici 58.6s pour lancer le jeu et 23s pour charger un niveau. Il faut toutefois noter que tous les jeux ne profitent pas autant d'un SSD et qu'étant donné la taille des jeux et le prix au Go des SSD il faut y réfléchir à deux fois ! Encore une fois les SSD sont proches entre eux et l'OCZ Petrol et le Sandisk SSD sont en queue de peloton.


Page 28 - Tenue des performances et TRIM

Tenue des performances et TRIM
Nous l'avons déjà évoqué à multiples reprises, 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 (voir 8 Ko, 8 Ko et 2048 Ko pour une puce Flash 25nm de 8 Go et 16 Ko, 16 Ko et 4096 Ko pour les futures puces Flash 20nm de 16 Go).

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 écriture 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.

Qu'en est-il en pratique ? Tester l'usure des performances d'un SSD n'est pas chose évidente mais nous avons évalué le comportement des SSD face à une situation extrême. Cette fois avant toute mesure de performance l'intégralité des l'espace accessible est remplie de données écrites séquentiellement.

La grande majorité de ces données ne sont pas compressibles par le contrôleur SandForce de manière à ne pas les avantager de manière complètement artificielle, à l'exception de 8 Go qui le sont fortement ce qui permet tout de même de donner un avantage à cette technologie comme ce sera de toute façon le cas en pratique.


A : 80 à 88 Go, données fixes incompressibles. B : 8 Go, données fixes incompressibles et qui subira un formatage rapide pour TRIM aux étapes 4 et 10. C : 8 Go de données fixes fortement compressibles. D : Zone de test de 24 Go, préalablement écrite en incompressible.

Les seules cellules Flash que le SSD considère comme vierges sont donc celles dédiées à l'overprovisionning, voir celles économisées du fait de la compression, chose qui ne doit naturellement pas arriver dans un système qui libère correctement les cellules via le TRIM.

On fait alors plusieurs mesures de performances en suivant ces étapes :
1. Remplissage du SSD
2. 20mn d'écritures aléatoires
3. 5mn d'écritures séquentielles
4. TRIM (libération de cellules) de 8 Go
5. 5mn d'écritures séquentielles
6. Reset du SSD (secure erase)
7. Remplissage du SSD
8. 5mn d'écritures séquentielles
9. 20mn d'écritures aléatoires
10. TRIM (libération de cellules) de 8 Go
11. 20mn d'écritures aléatoires
Les durées de 5 et 20 minutes ont été fixées en fonction des débits et des capacités d'overprovisionning des SSD de 120/128 Go, afin notamment de ne pas écrire uniquement dans ce dernier. La commande TRIM n'est utilisée qu'aux étapes l'indiquant, sinon les écritures se font en continu sans y faire appel (il s'agit de réécritures au sein d'un même fichier) ce qui constitue un cas extrême. Si nous ne reportons ici que des performances en écriture, il faut toutefois préciser que les performances en lecture peuvent également être impactés négativement, mais dans une moindre mesure. Sont également intégrées les performances sur un SSD "neuf" (après Secure Erase), avec donc 100% d'espace Flash considéré comme vierge par le contrôleur.


[ Corsair Force 3 ]  [ Corsair Force GT ]  [ Corsair Force GS ]  [ Corsair Perf. Pro ]
[ Corsair Neutron ]  [ Corsair Neutron GTX ]  [ Corsair Neutron GTX B ]
[ Crucial C300 ]  [ Crucial M4 ]  [ Crucial M500 ]
[ Intel X25-M V2 ]  [ Intel SSD 510 ]  [ Intel SSD 520 ]  [ Intel SSD 330 ]
[ Kingston V200 ]  [ Kingston V300 ]
[ OCZ Vertex 3 MI ]  [ Vertex 3.20 ]  [ Petrol ]  [ Octane ]  [ Agility 4 ]  [ Vertex 4 ]
[ OCZ Vector ]  [ Vector 150 ]  [ Vertex 450 ]
[ Plextor M3 ]  [ Plextor M3P ]  [ Plextor M5S ]  [ Plextor M5P ]
[ Samsung 830 ]  [ Samsung 840 ]  [ Samsung 840 EVO ]  [ Samsung 840 Pro ]  
[ Sandisk SSD ]  [ Sandisk Extreme ]  [ Sandisk Ultra Plus ]  [ Sandisk Extreme II ]
[ Toshiba Q Series ]


Sont représentées sur ce graphique les performances en écriture séquentielle sur un SSD neuf, puis aux étapes 8 ("après remplissage"), 3 ("après aléatoire") et 4 ("après TRIM 8 Go") lors d'une écriture séquentielle en boucle sur les mêmes 24 Go d'espace disque. Il faut bien comprendre que cet espace peut être réécrit plusieurs fois, puisqu'à 133 Mo /s il ne faut que 3 minutes pour le faire.

Un SSD aura des performances très stables dans tous les cas de figure si la courbe verte est stable et si les autres courbes sont au même niveau. Généralement vous observerez que la courbe violette est très en dessous au moins pendant quelques temps, il faut dire que le cas de figure représenté est assez extrême et peu représentatif d'une utilisation classique du SSD.

Un seul SSD maintient le même niveau de performance en écriture séquentielle quelle que soit la situation, c'est l'Intel SSD 510 d'Intel. Le simple fait d'être rempli peut faire baisser les performances, comme sur les OCZ Agility 4, Vertex 4, Vector, Vector 150, Vertex 450 ou encore le Toshiba Q Series du fait des techniques mises en places pour utiliser prioritairement les pages Flash en mode "SLC".


Le fait d'écrire en séquentiel sur un espace LBA préalablement utilisé pour des écritures aléatoires et en l'absence de pages Flash marquées comme étant vierges est dommageable pour de nombreux SSD. La majorité des SSD passent ainsi plus ou moins largement sous la barre des 100 Mo /s au départ, les exceptions étant l'Intel SSD 510, les Plextor M3, M3P et M5S, le Samsung 840 EVO ainsi que les OCZ Vector, Vector 150 et Vertex 450. Ils souffrent tout de même d'une baisse par rapport à leurs maximums, à l'exception du 510.

A force d'écrire en boucle en séquentiel sur ce même espace les performances augmentent rapidement sauf sur quelques SSD : Corsair Performance Pro, OCZ Octane/Petrol et Toshiba Q Series ou le gain est lent voir inexistant. Si le fait de libérer 8 Go de Flash via la commande TRIM permet de revenir aux performances initiales sur le Performance Pro et la plupart des SSD (même si cela n'est pas immédiat sur le Samsung 840 Pro), on reste en dessous sur les OCZ Octane, Petrol, Agility 4, Vertex 4, Vector, Vector 150 et Vertex 450 ainsi que sur le Kingston V200, le Toshiba Q Series et tous les SSD à base de SandForce : Corsair Force 3, Force GT et Force GS, Kingston V300, Intel SSD 520 / 330, OCZ Vertex 3 MI et 3.20, Sandisk Extreme.

Ces derniers SSD sont donc à éviter pour qui à besoin d'un débit en écriture élevé soutenu. Les Samsung 840 Pro, Corsair Neutron GTX, Plextor M3P/M5P et Sandisk Extreme II sont plus adaptés, combinant une bonne tenue des performances et des performances qui de base sont élevées.


[ Corsair Force 3 ]  [ Corsair Force GT ]  [ Corsair Force GS ]  [ Corsair Perf. Pro ]
[ Corsair Neutron ]  [ Corsair Neutron GTX ]  [ Corsair Neutron GTX B ]
[ Crucial C300 ]  [ Crucial M4 ]  [ Crucial M500 ]
[ Intel X25-M V2 ]  [ Intel SSD 510 ]  [ Intel SSD 520 ]  [ Intel SSD 330 ]
[ Kingston V200 ]  [ Kingston V300 ]
[ OCZ Vertex 3 MI ]  [ Vertex 3.20 ]  [ Petrol ]  [ Octane ]  [ Agility 4 ]  [ Vertex 4 ]
[ OCZ Vector ]  [ Vector 150 ]  [ Vertex 450]
[ Plextor M3 ]  [ Plextor M3P ]  [ Plextor M5S ]  [ Plextor M5P ]
[ Samsung 830 ]  [ Samsung 840 ]  [ Samsung 840 EVO ]  [ Samsung 840 Pro ]
[ Sandisk SSD ]  [ Sandisk Extreme ]  [ Sandisk Ultra Plus ]  [ Sandisk Extreme II ]
[ Toshiba Q Series ]


Sont représentées sur ce graphique les performances en écriture aléatoire sur un SSD neuf, puis aux étapes 2 ("après remplissage"), 9 ("après séquentiel") et 11 ("après TRIM 8 Go") lors d'écritures aléatoires 4 Ko en boucle sur les mêmes 24 Go d'espace disque. Il faut bien comprendre que cet espace peut être réécrit plusieurs fois, puisqu'à 60 Mo /s il faut moins de 7 minutes pour le faire et que le test dure 20 minutes.

Là encore un SSD aura des performances très stables dans tous les cas de figure si la courbe verte est stable et si les autres courbes sont au même niveau. Peu de SSD y parviennent et il faut préciser qu'en n'effectuant des écritures aléatoires sur les 24 derniers Go du disque il y'a 96 à 104 Go de données fixes : avec des écritures aléatoires sur la totalité du SSD les résultats seraient encore moins bons. Toutefois là encore ce serait un test très extrême et peu représentatif sauf à utiliser un RAID en l'absence de TRIM et y placer une BDD très lourde en oubliant d'utiliser l'overprovisioning... une mauvaise idée !

Pour la plupart des utilisateurs, dans un environnement compatible TRIM, on s'assurera juste que les 2 premières minutes de la courbe bleue sont proches du niveau de performance obtenu sur la courbe verte. Sans TRIM on s'assurera que les courbes rouges et violettes ne s'éloignent pas trop de la verte. Au delà des performances qui seront toujours suffisantes pour une utilisation classique (on a rarement besoin de plus de 10 Mo /s en écriture aléatoire de ce type), des performances basses sont le signe d'une amplification en écriture importante.

Le Crucial C300 souffre d'un comportement assez étonnant, lié à son dernier firmware et qui ne se produit qu'avec un accès concurrent et disparait dès que l'on passe à 2 accès.

Les Corsair Neutron et Neutron GTX tirent ici leur épingle du jeu. Offrant sur un SSD neuf de très bonnes performances, ils parviennent à les maintenir même après avoir été remplit de données de manière séquentielle, un très bon point pour qui voudrait les utiliser au sein d'un serveur en l'absence de TRIM. Les OCZ Vertex 4, Vector, Vector 150, Vertex 450, Samsung 840 Pro et Sandisk Extreme II ne déméritent pas non plus.

Les SSD à base de SandForce (Corsair Force 3, Force GT et GS, Kingston V300, Intel SSD 520/330, OCZ Vertex 3 MI et 3.20 et Sandisk Extreme) sont pour rappel ici avantagés car ils disposent du fait de la compression d'un surplus de Flash disponible puisqu'une partie des données statiques sont compressibles. En pratique toutefois ils ne tirent pas un énorme avantage de ceci par rapport aux autres SSD et cela leur permet tout juste de leur tenir tête, en dehors des Intel SSD 520 et 330 qui ajoutent à ceci 8 Go d'OP, par rapport aux autres SSD qui n'ont pourtant pas cet avantage. Bien entendu, plus les données seront compressibles, plus ils disposeront d'une réserve de Flash et plus ils maintiendront leurs performances à un niveau élevé. Phénomène étrange, quasiment tous les SandForce sont moins rapides pendant les premières minutes après le TRIM que sans TRIM.

La plupart des SSD en Marvell (Corsair Performance Pro, Crucial M4 et M500, Intel 510, Plextor M3, M3P, M5S, M5P et Sandisk Ultra Plus) ont globalement des comportements assez proches et gagnent eux lors du TRIM que ce soit durant les premières minutes comme dans la stabilisation. L'Intel SSD 510 affiche toutefois des performances globalement assez basses, et chose bizarre sur SSD neuf ses performances baissent après seulement 14 minutes d'écriture. Durant cet intervalle l'hôte n'a demandé qu'un peu plus de 40 Go d'écritures au SSD, et cette baisse des performances laisse penser que le SSD est à cours de Flash vierge ce qui veut donc dire que l'amplification en écriture serait de x3 !

On retrouve ce même phénomène sur le Toshiba Q Series après un volume d'écritures de 60 Go environ, ce dernier n'est d'ailleurs pas à la fête même après le TRIM de 8 Go. Une baisse sur SSD neuf est également enregistrée sur le Samsung 830 qui se comporte pourtant assez bien par ailleurs, avec notamment un très bon niveau de performance après TRIM, mais avec une baisse des performances moins importante. La baisse commence après environ 68 Go d'écritures, alors que sur les 20 minutes on écrit environ 92 Go de données. Ceci a été corrigé sur les 840 Pro, 840 et 840 EVO. Le 840 EVO est au passage bien moins à l'aise que le 840 dans cet exercice avec des courbes qui descendent bien plus bas, la faute à l'espace Flash utilisé par le TurboWrite au lieu d'être consacré à l'overprovisionning classique comme sur le 840 !

Enfin si le V200 de Kingston n'est clairement pas à la fête avec des performances divisées par x3.5 dans le pire des cas, c'est tout de même bien mieux qu'avec le firmware précédent puisqu'elles sont 5 à 10x supérieures. Le Sandisk SSD est du coup le seul à offrir des performances très basses, et elles ne sont pas si stables qu'elles n'y paraissent lorsqu'elles ne sont plus écrasées par l'échelle :



Page 29 - Consommation et efficacité énergétique

Consommation et efficacité énergétique
La dernière mesure concerne la consommation, que nous évaluons à l'aide d'une pince ampèremétrique. Elle est mesurée au repos d'une part, en lecture séquentielle et en écriture séquentielle, ce dernier cas étant l'une des charge qui demande le plus au SSD.

[ Consommation ]  [ Efficacité énergétique ]

[ Consommation ]  [ Efficacité énergétique ]


En règle générale, la plupart du temps le SSD est au repos cette valeur est donc importante sur un portable ou un ultraportable ou chaque watt économisé joue sur l'autonomie. Le Kingston V200 est de fait un peu trop gourmand pour cet usage, et il est ensuite suivi des SSD en Everest et Everest 2, le surcadencage du contrôleur Marvell par OCZ jouant probablement ici, mais aussi par le Vector en Barefoot 3. Les Vector 150 et Vertex 450 sont meilleurs de de côté. Les SSD les plus économes sont Samsung 840 et 840 Pro avec 0.35 watt seulement.

Il faut noter que les certains portables permettent même grâce au support des fonctionnalités d'énergie avancées (HIPM et DIPM), de faire entrer le SSD dans des était plus économes. Les différent Samsung 840, le Crucial M500 et le Sandisk Extreme II supportent ainsi ce mode qui permet d'atteindre une consommation de 0,1w voir moins !

Pour juger la lecture et l'écriture nous nous intéresserons plus particulièrement au second graphique qui représente le débit obtenus par watts consommé. En lecture le plus efficace est de loin le Sandisk SSD, et le moins efficace le Kingston V200. En écriture le X25-M est en queue de peloton alors qu'encore une fois c'est le Sandisk SSD qui est le plus efficace, un chiffre qu'il faut toutefois prendre avec des pincettes puisque les performances en écriture en dehors du test synthétique utilisé ici sont en fait très faibles. Parmi les SSD au comportement plus conforme c'est en fait le Plextor M3P affiche de loin le meilleur rapport entre débit et consommation.

Attention, la vision n'est que partielle pour les Agility 4, Vertex 4, Vector, Vector 150 et Vertex 450 dans le cas de l'écriture puisque ces derniers vont ensuite repasser par une seconde phase afin de libérer les pages les plus rapides pour les prochaines écritures (cf. Indilinx Everest 2 / Barefoot 3 et débits : attention !). Si on prend en compte cette partie le débit en écriture en Mo par watts est alors divisé par 2 voir 3, ce qui les place largement en queue de peloton ! Dans une moindre mesure les Samsung EVO sont aussi impactés par le vidage du cache TurboWrite.


Page 30 - Conclusion

Conclusion
Avant de passer aux recommandations à proprement parler, nous tenons une nouvelle fois à porter votre attention sur cette manie qu'ont les constructeurs d'afficher sur les fiches produit des débits en écriture très élevés alors qu'ils ne sont pas valables de manière continue.

Les premiers à avoir lancé cette mode sont les (nombreux) intégrateurs de contrôleur SandForce, profitant de la compression du contrôleur pour annoncer des débits peu réalistes en pratique (Corsair, Intel, Kingston, OCZ et Sandisk). Intel s'en tire un peu mieux que les autres, puisqu'à défaut de préciser le débit en incompressible dans ses brochures commerciales, il le fait dans la documentation technique, mais ce n'est pas suffisant ! OCZ l'a également fait, mais seulement sur une partie des références.

OCZ a ensuite emboîté le pas sur la priorisation des pages Flash "SLC" des puces MLC sur ses SSD en Indilinx Everest 2 et Barefoot 3, il a été suivi par Samsung et le TurboWrite du 840 EVO et enfin par Toshiba qui utilise une technique similaire à OCZ, sans libération des pages Flash "SLC", sur ses Q Series.

Si la compression SandForce n'a pas de contre-indications en pratique, ce n'est pas le cas des autres techniques qui à notre sens sont contre-productives puisque les débits atteints ne sont pas utiles en pratique alors qu'elles risquent d'amplifier l'usure des cellules Flash. Mais c'est avant tout pour la mise en avant du débit maximal uniquement, et non pas d'un intervalle de débit qui peut être soutenu sur tout le SSD, que nous décidons de mettre un carton rouge aux SSD utilisant ces techniques.

Peu de constructeurs échappent donc à ce carton rouge. C'est le cas de Crucial et Plextor.


Conclure un comparatif de 30 pages et 36 produits en quelques lignes n'est pas aisé, même en excluant les modèles qui ne sont aujourd'hui plus d'actualité, d'autant que le prix de la mémoire Flash évolue régulièrement ce qui fait bouger quotidiennement ou presque le prix des SSD 120 à 128 Go, à la baisse et parfois à la hausse, avec forcément un léger décalage en fonction du constructeur. Pourtant le paramètre prix est important dans le jugement de ces solutions.


En dehors de ce celui-ci, si nous ne devions retenir qu'un SSD de ce comparatif ce serait le 840 Pro de Samsung, qui affiche des performances de haut vol dans tous les domaines en plus d'une garantie de 5 ans et d'une fiabilité désormais éprouvée. Il précède d'autres modèles sans vrais défauts tels que le Plextor M5 Pro Xtreme et le Corsair Neutron GTX "B" qui occupent également les premières places.



Le paramètre prix a néanmoins sont importance, et il met hors-jeu ces SSD, surtout le 840 Pro, du fait d'un positionnement tarifaire inadaptée. Une constante ces derniers mois chez Samsung qui vends par ailleurs ses 840 et 840 EVO en TLC au même prix que d'autres SSD en MLC qui sont donc préférables.



A l'heure où nous écrivons ces lignes, les SSD Sandisk Extreme II et Ultra Plus sont en effet mieux positionnés. Le premier est le plus performant des deux et bénéficie d'une garantie de 5 ans, mais est un peu plus cher. Le Kingston V300 est également un bon compromis, encore moins cher que l'Ultra Plus il est légèrement moins performant, sans que cela n'ait vraiment d'impact en pratique, par contre sa capacité disponible est un peu moindre (120 Go contre 128 Go). Enfin le Crucial M500 est également un SSD au positionnement intéressant, et le seul à proposer un codage AES 256 bits compatible IEEE1667 et TCG Opal 2.0.



Beaucoup de SSD ne se distinguent ni par leurs caractéristiques ni par le tarif, et constituent le ventre mou de ce comparatif. Peu de modèles sont à éviter coûte que coûte, néanmoins si vous trouvez encore en magasin un Sandisk SSD ou un Crucial V4 (non testé ici car en SATA 3G) passez votre chemin du fait de leurs performances moyennes, et fuyez les OCZ Petrol et Octane SATA 3G (des séries qui sont heureusement stoppées) très peu fiables. Évitez également le Toshiba Q Series, dont le mode "SLC" nous semble pire que celui de Samsung et d'OCZ.

La fiabilité est d'ailleurs un problème récurrent chez OCZ, puisqu'assez inégale en fonction des séries de SSD. Même les SSD en Barefoot 3 semblent plus sujets à problèmes que la moyenne, alors que la fiabilité était un point mis en avant par le constructeur à leur lancement. Dans ces conditions et sans plus de recul il est difficile de conseiller un SSD tel que le dernier Vector 150 malgré des avantages comme une excellente tenue des performances en écriture aléatoire.

Plus globalement, et en dehors de quelques modèles à éviter, tous ces SSD offrent à l'usage une expérience très satisfaisante et un confort d'utilisation sans commune mesure avec celui d'un disque dur. Après avoir goûté au SSD, il est difficile de revenir en arrière ! En pratique les écarts entre la plupart des SSD sont faibles, et plus que des SSD plus performants, ce qui arrivera surtout une fois que nous serons débarrassés des limites du SATA 6 Gb/s, c'est surtout une baisse de prix qui est attendue.

À quand les SSD 512 Go à 150 € ? Les paris sont ouverts !

Mise à jour du 28/02/2014 : Attention, depuis quelques semaines Kingston livre des V300 dotés de mémoire Flash asynchrone bien moins rapide, cf. cette actualité !


Copyright © 1997-2019 HardWare.fr. Tous droits réservés.