SSD 2009, acte 2 : OCZ Vertex et Indilinx Barefoot - HardWare.fr
>> Stockage >> SSD
Rédigé par Marc Prieur
Publié le 22 Avril 2009
URL: http://www.hardware.fr/art/lire/758/
Page 1
Indilinx & OCZ Vertex
Fondée en octobre 2006 par trois anciens cadres de chez Samsung Electronics, Indilinx est une société relativement récente dont le premier projet est le Barefoot, un contrôleur pour SSD utilisé sur de plus en plus de produits dont les OCZ Vertex.
Développé dès la création de la société et finalisé au premier semestre 2008, le Barefoot reprend une base commune à d’autres contrôleurs haut de gamme, à savoir un processeur ARM7. Il est capable d’utiliser une puce externe en tant que mémoire cache et adresse les puces Flash NAND, de type SLC ou MLC, en parallèle, ce afin d’atteindre des débits de 210 Mo /s en lecture et 170 Mo /s en écriture.
 OCZ fut le premier à annoncer ses produits à base d’Indilinx Barefoot, ce dès décembre 2008. Il aura toutefois fallu attendre février pour que les produits arrivent sur le marché, et encore avec des firmware qui n’ont pas cessé d’évoluer depuis.
 De base, le Vertex était en effet livré avec le firmware 0112, puis rapidement une nouvelle version 1199 augmentant sensiblement les performances à vu le jour mi mars. Seul problème, ce firmware était buggé et les données pouvaient être perdues en cas d’utilisation intensive. Le firmware 1275, disponible une semaine plus tard, corrigea le problème. Début avril le dernier firmware 1.1 ajouta pour sa part le support du TRIM. Les mises à jours devraient maintenant se faire à un rythme moins effréné, et c’est tant mieux car à chaque mise à jour d’un SSD à base de Barefoot, les données sont perdues : il serait utile que Indilinx travaille sur un flashage préservant les données !
L’OCZ Vertex est disponible en 4 capacités : 30, 60, 120 et 250 Go. Les débits annoncés varient en fonction de cette dernière : respectivement 230, 230, 250 et 250 Mo /s en lecture et 135, 135, 180 et 160 Mo /s en écriture. Pour avoir une vue d’ensemble des performances, nous avons donc testé une version 30 Go et une version 120 Go.
 Une fois désossé, on voit au sein du Vertex un contrôleur Indilinx associé à une puce SDRAM Elpida de 64 Mo adressée en 32 bits à une vitesse de 166 MHz (soit 666 Mo /s de bande passante théorique). Côté Flash NAND, c’est Samsung qui est à la baguette avec 16 puces MLC de 8 Go pièce (8 de part et d'autre du PCB).
Page 2
Dégradation & TRIMLa dégradation des performances Nous en avions parlé lors de notre précédent article sur les SSD, un SSD « neuf » n’as généralement pas les mêmes performances qu’un SSD utilisé. Commençons tout d’abord par l’usure qui concerne tous les SSD, à savoir la perte de performances lorsqu’on écrit des petits blocs de donnée.
Au sein des puces Flash NAND, les cellules mémoires sont regroupées au sein de pages, ces pages composant des blocs. Généralement une page fait 4 Ko, un bloc fait 512 Ko. Il faut savoir qu’il est possible de lire ou d’écrire une puce Flash NAND par page, mais que les données ne peuvent être effacées que par bloc.
Autre paramètre à prendre en compte, lorsqu’un fichier est effacé par le système, le SSD n’est tout simplement pas au courant, puisque l’opération se situe uniquement au niveau du système de fichiers. Le SSD n’a donc connaissance de l’invalidité d’une donnée contenue dans une page qu’à partir du moment où l’on va réécrire dessus !
Le phénomène qui en découle est du coup assez simple : lorsque l’on va écrire un nouveau fichier de 4 Ko sur une page déjà utilisée, le SSD va alors devoir lire le bloc entier, puis l’effacer, et enfin réécrire toutes les pages de ce bloc. Pour une écriture de 4 Ko, on aura donc jusqu'à 512 Ko de lecture, une phase d’effacement et 512 Ko d’écriture, ce qui a logiquement un impact négatif sur les performances, particulièrement lors de l’écriture aléatoire de fichiers de petite taille.
Autre problématique, l’adressage des pages mémoire Flash utilise un système indirect, le contrôleur faisant office de traducteur entre les adresses logiques utilisées par le système de fichiers (les LBA) et les adresses physiques des pages Flash correspondantes. La correspondance n’est en effet pas fixe comme c’est le cas des disques durs, le contrôleur Flash se chargeant d’allouer au mieux les pages afin d’optimiser les performances (write combining) ou d’améliorer la durée de vie des cellules (wear leveling).
C’est surtout un write combining agressif qui peut ici poser problème. Le write combining fonctionne de manière assez simple, puisqu’il s’agit de combiner plusieurs écritures aléatoires en une seule écriture séquentielle : écrire d’une traite 32 pages dans un même bloc va bien plus vite que d’écrire 1 page dans 32 blocs différents, et cerise sur le gâteau, cela use moins le SSD. La table d’allocation doit alors être mise à jour pour que LBA 0 = Page 0, LBA 133 = Page 1, LBA 289 = Page 2, etc.…
Seul problème, si on doit ensuite réécrire de manière séquentielle sur le SSD avec une telle table d’allocation, les performances sont alors fortement réduites puisqu'on fera physiquement des écritures non séquentielles ! Bien entendu en fonction du contrôleur le SSD essaie de réorganiser au mieux la table d’allocation pour ce type d’écriture mais sans grand succès si toutes les pages ont déjà été utilisées une fois. Le write combining est d’ailleurs lui-même mis à défaut faute de page libre, puisqu’il ne peut alors plus faire son office faute de matière première.Vive le TRIM C’est là qu’intervient la fonction TRIM. Proposée en 2007 par le comité technique T13 qui est chargé de définir les spécifications de la norme ATA, il s’agit d’une commande permettant au système d’indiquer au support de stockage qu’un LBA contient des données qui sont désormais invalides.
Ca peut paraître « bête », mais cela va considérablement simplifier la vie des contrôleurs SSD pour ce qui est de la bonne tenue des performances. Au niveau du contrôleur, l’implémentation n’est pas fixe mais logiquement il s’agira de supprimer la référence à la page dans la table d’allocation LBA / page Flash.
Effacer physiquement chaque page à ce moment, c'est-à-dire lire le bloc entier auquel elle appartient, l’effacer et le réécrire, serait complètement contre-productif du point de vue de l’usure des puces mémoires, mais il est imaginable que tout bloc ne contenant que des pages qui ne font plus partie de la table d’allocation soit remis à 0.
 Dans tous les cas le fait de savoir quelles sont à l’avance les pages disponibles pour une écriture permettra au contrôleur d’optimiser au mieux les écritures, qu’elles soient séquentielles ou aléatoires, et donc de ne plus se retrouver face à la problématique actuelle lorsque toutes les cellules ont été utilisées au moins une fois.
Pour pouvoir utiliser cette fonction, deux conditions sont toutefois nécessaires. D’une il faut un SSD qui supporte cette fonctionnalité, que ce soit à sa sortie ou via un nouveau firmware comme c’est le cas de l’OCZ Vertex, de deux il faut que le système d’exploitation en tire partie. C’est possible dès à présent sous Linux, et pour Windows il faudra attendre Seven, qui ne l’intègre d’ailleurs pas pour l’instant dans ses versions beta.
Autre solution, OCZ propose un utilitaire en version beta à destination des Windows 32 bits permettant d’utiliser la fonction TRIM du SSD. Il ne s’agit pas ici de l’utiliser à la volée mais lorsqu’on lance l’utilitaire, celui-ci lit la table d’allocation du système de fichier et indique au SSD via la commande TRIM les adresses LBA qui ne sont pas utilisées. Et voilà !
Page 3
L'usure du Vertex en pratiqueL’usure du Vertex en pratique Voici un exemple pratique de la dégradation des performances d’un SSD avec le Vertex 30 Go lorsque la fonction TRIM n’est pas utilisée.
Cas 1 : Performances séquentielles - Accès séquentiels uniquement
Tout d’abord, voici les débits (en Ko /s) en écriture et lecture séquentielles lorsqu’on n’effectue que des accès de ce type (une lecture, une écriture, une lecture, une écriture, une lecture et une dernière écriture, à chaque fois sur l'intégralité du SSD soit 30 Go) :
  On note une légère baisse de performances entre un disque neuf et un disque utilisé, puisque l’on passe de 206 à 196 Mo /s en lecture et de 159 à 145 Mo /s en écriture. Pas de quoi fouetter un chat toutefois.
Cas 2 : Performances séquentielles - Accès aléatoires puis accès séquentiels
Cette fois on part d’un disque neuf (après HDD Erase ou flashage) que l’on « use » en écrivant uniquement par bloc de 4 Ko de manière aléatoire, pendant 30 minutes.
  Les performances en lecture séquentielle sont dégradées dès le premier run. Pire, la seconde lecture qui a lieu après la première écriture séquentielle offre des performances encore plus basses, qui commencent à remonter au 3è passage. Les moyennes en lecture sont ainsi de 148, 93 et 116 Mo /s, à comparer aux 206 Mo /s obtenus dans le meilleurs des cas sur un SSD « neuf ».
En écriture, c’est encore pire, et ce dès que l’on essaie d’écrire en séquentiel avec une table d’allocation auparavant utilisée pour une écriture aléatoire : 25.6 Mo /s dans un premier temps, débit qui remonte progressivement à 40.8 puis 50 Mo /s. Lentement, et difficilement, la table d’allocation se réorganise.
Cas 3 : Performances aléatoires
Voici maintenant une observation de l’évolution des performances (en I/O par seconde) lors d’écriture de fichier de 4 Ko de manière aléatoire. On lance le test sur le SSD Vierge, 6 fois 5 minutes, puis une seconde fois sur un SSD ont les cellules ont auparavant été remplies de manière séquentielle.
 Le problème qui se pose ici est donc la valeur que l’on doit inclure dans un test : certains diront qu’un Vertex fait 3270 I/O par seconde, alors qu’on est rapidement loin de cette valeur même sur un Vertex tout neuf. Sur un SSD qui a été préalablement rempli, les performances baissent toujours, mais la courbe est cette fois stabilisée.L’utilitaire TRIM Voyons voir ce que peut faire l’utilitaire TRIM développé par Indilinx contre ce phénomène qui n’est pas sans nous refroidir vis-à-vis comme c’était le cas avec le SSD Intel X25-M. Ce logiciel se lance simplement sous Windows XP ou Vista 32 bits, son fonctionnement en 64 bits n’était pas encore complètement stable. Une fois lancé il envoie lit la table d’allocation du système de fichier et indique au SSD via la commande TRIM les adresses LBA qui ne sont pas utilisées.
 Et voilà ! Que ce soit en lecture séquentielle, écriture séquentielle, ou écriture aléatoire, les performances du Vertex reviennent alors à leur niveau d’origine. Voilà donc une très bonne nouvelle qui laisse présager du meilleur quand la fonction TRIM sera implémentée directement au niveau du système d’exploitation et qu’elle se fera à la volée. En attendant, ceux qui possèdent un Vertex et qui remarquerait une baisse notable de leurs performances n’auront plus qu’à utiliser l’utilitaire pour ramener les performances d’origine sur l’espace libre restant.
Page 4
Le testLe test Pour ce test, nous avons comparé ces nouveaux SSD à différents modèles :
- OCZ Core V2 - OCZ Apex - Samsung PM410 - Samsung PS410 - Samsung PB22-J 64 Go - Samsung PB22-J 256 Go - Mtron MOBI 3500
L’OCZ Core V2 représente ce qui se fait de « mieux » en combinaison JMicron JMF602/MLC, l’Apex étant une version RAID (deux SSD en un). Les SSD Samsung SLC et MLC sont les références de la génération précédente, idem pour le Mtron MOBI 3500 qui était une alternative intéressante. Enfin les Samsung PB22-J sont la nouvelle génération de Samsung, représentée en deux capacités puisque leurs caractéristiques diffèrent. Nous avons également ajoutés à titre indicatif les performances d’un VelociRaptor, d’un disque 3"1/2 Samsung SpinPoint F1 640 Go et d’un disque 2"1/2 Samsung SpinPoint M5 160 Go.
Diverses mesures ont été effectuées au cours de ce comparatif. Tout d’abord, nous nous sommes intéressés aux performances « synthétiques » des disques : temps d’accès moyen, débit séquentiel, I/O en accès séquentiel et aléatoire. Viennent ensuite des tests un peu plus applicatifs, à savoir un indice de performance applicatif basé sur PC Mark Vantage et enfin de l’écriture et la lecture de divers ensembles de fichiers. Ces fichiers sont composés de la sorte :
- Gros : 13.2 Go pour 6 fichiers (2.2 Go de moyenne) - Moyens : 7.96 Go pour 10480 fichiers (796 Ko de moyenne) - Petits : 2.86 Go pour 68184 fichiers (44 Ko de moyenne)
La source ou la cible lors de la lecture ou de l’écriture sur le disque est un RAID de trois disques VelociRaptor 150 Go, qui viennent remplacer un raid de deux Raptor 150 Go dans les tests précédents. Ce type d’information est bien entendu intéressant puisque si le débit séquentiel donne une idée des performances lors de la copie de gros fichiers, les choses seront différentes avec des petits fichiers.
La machine de test était basée sur un chipset X38 monté sur une carte mère P5E d’ASUSTeK, et les ports Serial ATA étaient configurés dans le bios en AHCI (Advanced Host Controller Interface) afin de disposer du NCQ, le tout fonctionnant sous Vista SP1.
Pour finir, nous avons également ajoutés de nouveaux tests pratiques afin de proposer des données un peu plus parlantes à ceux qui se demandent si un SSD vaut la peine par rapport à un disque dur classique. Pour se faire nous avons chronométré diverses opérations sur une autre machine à base de P5QC, QX9770, GTX 280 et 2x2 Go de DDR2-1066.
Page 5
Performances synthétiquesPerformances synthétiques
 Mesuré à l’aide de h2benchw, le temps d’accès des SSD est vraiment époustouflant. Les Vertex arrivent à abaisser encore le record pour un SSD MLC avec 0.12ms, contre 0.10ms pour le MOBI 3500.
Nous continuons avec le débit, à l’aide de h2benchw toujours. Contrairement à d’autres logiciels tel que HDTune ou HDTach, ce dernier effectue vraiment un test séquentiel puisqu’il lit ou écrit la totalité du disque, là ou ces logiciels sauteront de zone en zone afin de réduire le temps de test.
 Avec un débit en lecture supérieur à 200 Mo /s, les Vertex 30 et 120 Go se placent directement en première place. En écriture les résultats sont également très bons, notamment pour ce qui est du Vertex 120 Go. La version 30 Go est légèrement en retrait comme le laisser deviner ses spécifications mais bon … 159 Mo /s ce n’est déjà pas si mal, non ?
Voici maintenant venu le temps de mesurer le nombre d’accès 100% aléatoires pouvant être supportés par ces systèmes de stockage, ce à l'aide de IOMeter. Il s’agit ici de faire des accès par petit bloc de 4 Ko et de voir le nombre de ces accès que le support est capable de soutenir chaque seconde, dans un premier temps en utilisant un type d’accès séquentiel puis en utilisant un accès aléatoire.
 C’est en lecture que les SSD montrent leur grande force, qui est bien entendu inhérente à leur temps d’accès très réduit. Que l’accès soit séquentiel ou aléatoire, les performances restent très bonnes, alors que sur les disques durs classiques le déplacement de la tête de lecture pénalise grandement les performances. On note que les Vertex se comportent extrêmement bien, même si le MOBI 3500 est devant lors de lectures aléatoires.
 En écriture les disques durs sont meilleurs, l’avantage étant essentiellement lié au cache. Pour les SSD par contre, les choses se compliquent énormément, d’autant que le test est effectué sur un support dont les pages ont déjà toutes été préalablement remplis de manière séquentielle. Les SSD à base de puce JMicron (OCZ Core V2, OCZ Apex) sont tout simplement catastrophiques, avec un niveau de performances qui ne permet d’assurer aux utilisateurs une utilisation très fluide de la machine (freezes et autres lags …). Autre grosse déception, le Samsung PB22-J que nous avons pu ici tester en version 64 Go offre des performances qui sont également limite : certes, elles devraient être suffisantes pour éviter les lenteurs perceptibles sur les SSD JMicron, mais on est tout de même 2,3 fois en dessous du Samsung PM410 de génération précédente !
Côté Vertex, les performances sont là, avec environ 450 I/O par seconde sur les deux versions testées on et bien au-delà des performances d’un disque dur classique, chose excellente dans ce domaine difficile pour les SSD. Jusqu’alors seul Intel était parvenu à soutenir un niveau de performance élevé dans ce secteur, mais avec une dégradation des performances importante dans le temps, dégradation qu’il est facile de contrer sur le Vertex avec l’utilitaire TRIM. De plus, comme nous l’avons vu dans la partie dédiée aux performances du Vertex dans le temps, il sera tout à fait possible de soutenir plus de 3000 I/O par seconde en écriture aléatoire 4K lorsque le TRIM sera intégré au système d’exploitation.
Page 6
PC Mark VantagePC Mark Vantage Nous passons maintenant à des tests moins synthétiques, avec pour commencer l’indice de performance disque de PC Mark Vantage. FutureMark reproduit sur le disque un ensemble de lecture / écriture enregistrée lors de diverses taches, à savoir le démarrage de Vista, le chargement d’applications (Word, Photoshop, IE, Outlook), la manipulation de fichiers multimédias (photo, vidéos, musique), le jeu (chargement dans Alan Wake) et le scan du disque via Windows Defender.
 Deux choses sont ici à noter, la première c’est que bizarrement la version 64 Go du PB22-J offre des performances légèrement supérieures à la version 256 Go. Côté Vertex c’est encore mieux et de manière nette, l’avantage étant plus logiquement à la version 120 Go.
Page 7
Gestion de fichiersGestion de fichiers Nous passons maintenant à la gestion de fichiers. Sont relevés les débits en lecture et en écriture de divers ensembles de fichiers. Ces fichiers sont composés de la sorte :
- Gros : 13.2 Go pour 6 fichiers (2.2 Go de moyenne) - Moyens : 7.96 Go pour 10480 fichiers (796 Ko de moyenne) - Petits : 2.86 Go pour 68184 fichiers (44 Ko de moyenne)
La source ou la cible lors de la lecture ou de l’écriture sur le disque est un RAID de trois disques VelociRaptor 150 Go.
 En lecture les SSD de dernière génération, Vertex inclus, sont très véloces pour les gros fichiers. Par contre, lorsqu’il s’agit de travailler sur des fichiers petits ou moyens, les performances sont relativement proches de la génération précédente et des disques durs classiques, exception faite du 5400 tpm.
 En écriture, les Vertex s’en sortent bien notamment sur les fichiers de moyenne taille ou ils sont nettement devant la concurrence, exception faite du disque dur Samsung 7200 tpm qui s’en sort étonnamment bien. On note par contre que si les résultats sont bons sur les gros fichiers, ils sont assez éloignés du débit synthétique obtenus sous h2bench (200 Mo /s pour rappel sur le Vertex120 Go !).
Page 8
Tests pratiquesTests pratiques Nous avons enfin décidé de rajouter d’autres tests pratiques au sein de nos tests de SSD, notamment afin de proposer des données un peu plus parlantes à ceux qui se demandent si un SSD vaut la peine par rapport à un disque dur classique. Pour se faire nous avons chronométré diverses opérations sur une machine à base de P5QC, QX9770, GTX 280 et 2x2 Go de DDR2-1066.
- Démarrage de Windows Vista On mesure le temps nécessaire pour démarrer Windows Vista fraichement installé avec les drivers. Le temps est celui depuis le passage du bios (disparition du logo P5QC) jusqu’à l’arrivée sous le bureau Windows avec un curseur de souris sans sablier.
- Installation du Service Pack 1 Il s’agit ici du temps nécessaire à l’installation du Service Pack 1, le fichier d’installation étant lui-même situé sur le SSD.
- Démarrage d’un Windows Vista SP1+Kaspersky+Word+Excel+Outlook+Photoshop Après avoir installé Kapersky Antivirus 2009, la suite Office et Photoshop CS4, nous mettons des raccourcis vers Word, Excel, Outlook et Photoshop dans le répertoire Startup du menu démarrer. Le temps mesuré est celui depuis le passage du bios jusqu’à la fin du lancement de Photoshop CS4.
- Chargement du niveau “Train” dans Crysis Warhead Après avoir installé et patch Crysis Warhead, nous le lançons avec l’option –DEVMODE et chargeons via la console le niveau train avec la commande « map train ».
Nous n’avons pas pu faire les tests sur la version 256 Go du Samsung PB22-J, le SSD n’étant plus en notre possession.
 On ne note pas de grosse différence entre les SSD pour ce qui est du démarrage de Vista. Il y’a vraiment un trou entre un disque dur classique, même un VelociRaptor, et un SSD, mais ces derniers ne se distinguent les uns des autres.
 L’installation du Service Pack 1 de Vista montre par contre des écarts importants. S’il n’est pas très étonnant de retrouver les SSD en JMicron en dernière position, il est plus surprenant de voir le MOBI 3500 si mal placé. On retrouve ensuite le PB22-J qui est devancé par l’ancienne génération PM410 de Samsung, alors que la version SLC, le Samsung PS410, s’en tire bien. Les Vertex offrent pour leur part, et de loin, le meilleur temps d’installation. On notera que comparé aux disques durs classiques, les SSD peuvent être cette fois nettement plus lents !
 Alors que le démarrage « simple » de Vista ne montrait pas de grosse différence entre les SSD, les choses changent lors d’un lancement multi-applicatif très lourd. On retrouve ainsi en tête le Samsung PS410, suivi des 2 Vertex et du MOBI 3500. Les Samsung MLC sont un peu en retrait, la nouvelle génération étant moins rapide que l'ancienne, et on retrouve en queue de peloton les OCZ Apex et Core V2. Ces derniers restent toutefois légèrement devant un VelociRaptor.
 Comme vous pouvez le voir, le fait de passer d’un HDD à un SSD ne change pas forcément la vie dans le chargement du niveau d’un jeu. Il faut savoir que le lors du chargement, il y’a bien entendu des opérations de lecture qui sont effectuées sur le support de stockage, mais aussi une grande partie du temps qui est lié à la création de l’environnement par le processeur à partir des données qui sont lues, cette partie étant incompressible. Du coup, le gain même si il est présent reste ici léger.
Page 9
ConsommationConsommation Tous les SSD testés ici sont parfaitement silencieux. Nous nous sommes donc concentrés sur la mesure de consommation, au repos ainsi qu’en charge sous IOMeter. Voici les résultats obtenus :
 En plus d’être très performants, les Vertex sont très économes en charge ! Que demander de plus …
Page 10
ConclusionConclusion Avec les Vertex, OCZ jette un pavé dans la marre des SSD. Certes, plus qu’OCZ c’est Indilinx qui est à la source des performances, mais le suivi effectué par OCZ au travers de ses forums techniques et les remontées auprès d’Indilinx qui en découlent ont permis au Vertex d’évoluer rapidement depuis sa sortie. Bien entendu ces évolutions devraient à terme être disponibles pour tout les SSD déclinées sur la même base, comme c’est le cas par exemple des SuperTalent UltraDrive ME ou des G.Skill Falcon.
 Relativement abordable puisqu’à base de MLC, offrant des performances de haut vol dans tous les cas de figure, économe en énergie et premier SSD à nous donner un avant gout de ce qu’apporte le TRIM, le Vertex a pour ainsi dire tout du SSD parfait. On regrettera seulement une disponibilité en dent de scie depuis son lancement ainsi qu’une mise à jour du firmware fastidieuse puisqu’effaçant les données contenues sur le SSD.
Ceux qui sont frileux à l’idée de s’orienter vers un SSD MLC, préférant s’orienter vers la SLC qui est 10 fois plus endurante en terme de cycles d’écriture, seront ravis d’apprendre que certains constructeurs proposent l’Indilinx couplé à ce type de mémoire (SuperTalent UltraDrive LE, OCZ Vertex EX) : le prix devrait par contre être au moins double des versions MLC, et côté performance on peut s’attendre à 10% de mieux en accès séquentiels et 70-80% de mieux en accès aléatoires.
Au final, jusqu’alors notre préférence allait au Samsung MLC 64 Go de première génération, le PM410, puis à son grand frère le PB22-J précédemment testé en version 256 Go. La version 64 Go s’est ici avérée assez décevante, le PB22-J 64 Go étant à certains égards moins performants que la PM410 64 Go ! Le Vertex se place donc sans trop forcer sur la première place du podium.
On notera par ailleurs que Intel a rendu disponible il y’a quelques jours un nouveau firmware pour son X25-M censé contrecarrer les baisses importantes de performances qui peuvent arriver dans certains cas. Une bonne chose qu’il nous reste à vérifier et qui pourrait permettre au X25-M de se repositionner face au Vertex. Reste que son prix est encore élevé, puisqu’un X25-M 80 Go est au tarif d’un Vertex 120 Go et qu’il n’existe pas de version plus abordable !
 Quid de l’avenir ? On sait déjà que Indilinx travaille sur son nouveau contrôleur, le Jet Stream. Les premiers prototypes sont prévus pour le second semestre, le constructeur tablant sur un débit de 500 Mo /s, le tout via une interface SATA 6 Gbps /s. Miam !
Copyright © 1997-2009 HardWare.fr. Tous droits réservés.
|