Problèmes rencontrés avec le SSD Intel
 
Performances qui se dégradent
 
Malgré le bon niveau de performances que nous venons de découvrir, nous ne pouvons décemment pas passer sous silence le problème majeur que nous avons rencontré avec le SSD Intel : à savoir une certaine forme de dégradation des performances au fil de son utilisation. Les résultats des pages précédentes sont ceux obtenus lors de la première utilisation du SSD, à savoir neuf comme s’il sortait de l’usine. Il s'agit donc de ses performances quand il est au meilleur de sa forme. Après ces tests répétés plusieurs fois, nous avons ensuite voulu effectuer des tests sous IOmeter, logiciel permettant de mesurer le nombre d’entrées/sorties dans différents cas de figure. Ce logiciel, développé par Intel, permet par exemple de simuler les performances du disque dans un scénario base de données, file server, etc. Les résultats étaient plutôt bons lors du premier run mais au fur et à mesure que nous testions des cas de figure différents, les performances chutaient dramatiquement. Nous avons alors effacé le fichier créé par IOmeter pour la réalisation de ses tests, effacé la partition et redémarré le PC. Nous avons relancé tous nos tests pour alors constater une baisse de performance impressionnante en écriture, les tests en lecture restant du même tonneau. Le débit séquentiel en écriture n’a plus rien à voir avec ce que l’on attend d’un SSD à savoir un débit constant. Jugez plutôt avec ces 2 captures d’écrans HDTune Pro 3.0 avant et après le test IOmeter :
 
                                                         
 
 
                                        Débits en écriture avec le SSD "neuf" et après une session IOMeter
 
 
Les pertes de débit sont alarmantes avec parfois des chutes jusque 0.4 Mo/s . La moyenne passe de près de 75 Mo/s à seulement 12.2 Mo/s ! Nous avons eu beau répété les tests avec redémarrage de la machine, reformatage du SSD, rien n’y a fait. Le score sous PCMark Vantage était lui aussi en chute, de même que les tests de transferts de fichiers. La seule solution pour revenir à des performances normales a été d’exécuter un Secure Erase avec le logiciel HDDErase, sous DOS. Cette opération n’est pas anodine et non sans risque puisqu’elle consiste à écraser l’entièreté des données du SSD et à le remettre dans l’état dans lequel il était à sa sortie d’usine. Seulement alors nous avons retrouvé des performances dignes de ce nom… temporairement.
 
Vu l’effet IOmeter, nous avons laissé tomber ce test "orienté entreprise" et n’avons effectué que des tests synthétiques, PCMark Vantage et des transferts de fichiers. Lors du premier run, rien à dire, tout se comporte comme attendu. Mais comme à notre habitude, nous avons répété les tests à plusieurs reprises à titre de vérification et de normalisation des résultats. Quelle ne fut pas alors notre surprise de redécouvrir des résultats en baisse par rapport au premier run. Certes, la chute est moins dramatique qu’après le test IOmeter mais tout de même. Au fur et à mesure que le SSD se remplit et/ou se vide, les performances diminuent et n’ont pas retrouvé le niveau du premier run, même après formatage et redémarrage du PC. Une fois de plus, seul un Secure Erase a permis de retrouver le niveau de performance initial. Par exemplele score PCMark passait de 32000 à 25000. Certes cela reste un très bon score mais il s'agit du seul SSD à se comporter de la sorte. Nous avons ensuite évité le test synthétique pour ne faire que des tests pratiques pour là aussi constater une baisse des débits sous PCMark. Les tests de transferts de fichiers restaient de leur côté plutôt bons mais un cran en-dessous des meilleurs scores obtenus.
 
 
Début d'explication
 
 
Ce problème nous interpelle d’autant plus que nous n’avons jamais rencontré ce cas de figure avec les autres SSD que nous avons en notre possession. Par exemple un Memoright de 64 Go obtient un niveau de performance constant, y compris après une session acharnée de IOmeter et ce sans redémarrer le PC. Etant donné que notre confrère Marc Prieur de Hardware.fr a lui aussi reçu un exemplaire de ce SSD Intel, nous lui avons demandé s’il rencontrait ces problèmes et la réponse fut positive. Lui aussi n’a jamais rencontré de tels soucis avec d’autres SSD qu’ils soient à base de SLC ou MLC. Même le décrié OCZ Core ne lui a pas posé de tels soucis. Nous nous sommes alors tournés vers Intel qui nous a laconiquement répondu que c’était un comportement… normal et attendu !  
 
Intel nous affirme en effet que leurs SSD à base de MLC ont été optimisés pour un usage dans un PC de bureau ou un portable. Un tel usage est défini chez Intel comme étant composé de nombreuses opérations de lecture et d'écritures principalement séquentielles, les écritures aléatoires étant plus rares par opposition à un usage plus "pro" où les lectures et écritures aléatoires sont légion. Ces SSD X25-M sont donc capables de supporter des applications qui effectuent des opérations aléatoires et/ou séquentielles intensives en lecture et des opérations d’écriture séquentielles intensives. D’après ce que nous avons compris, Intel a optimisé son SSD pour gérer au mieux les écritures selon la charge qui arrive. Le contrôleur essaie d'optimiser le travail en quelque sorte. Si la charge qui arrive est intense et inattendue, comme dans le cas du test IOmeter, le SSD va mettre du temps à s'adapter à ce cas non prévu à cause de la façon dont Intel l'a "programmé", à savoir pour un usage normal de type Desktop ou Laptop. Et c'est vrai qu'un test d'IOmeter durant deux heures d'affilée a révélé un nombre d'entrées/sorties anormalement bas au début mais augmentant progressivement au fur et à mesure que le temps s'écoulait.
 
Pour illustrer cette technique sans trop en dévoiler, ce n'est pas le genre du fondeur de s'étendre sur des détails techniques, Intel compare son système d'optimisation à une sorte de fonction interne de défragmentation, entendez par là, de réorganisation. Le problème avec IOMeter, c’est que la manière dont nous l’utilisons ne convient pas à cette opération. En effet, nous programmons des opérations de lecture et d’écriture 100% aléatoires et d’après Intel, effectuer de telless opérations intensives sur la totalité du SSD (IOMeter crée un fichier équivalent à la capacité du disque pour ses tests) va fragmenter le SSD à un tel point qu’il va s’en suivre des temps de latence très élevés pendant que le SSD exécute une réorganisation interne, consécutive à ce test. Intel conclut son explication en disant que sous peu, le SSD X25-E à base de SLC va arriver sur le marché et que ce dernier est de son côté taillé pour le monde de l’entreprise et des applications professionnelles.
 
Pour en revenir plus en détail au problème du disque X25-M, on peut l’expliquer de la manière suivante. Avec tous les SSD, les LBA (Logical Block Adressing) ne sont pas toujours situées dans la même localisation physique, par opposition au disque dur. Pour rappel, le LBA est la traduction en adresse de la localisation physique d’une information. Dans le cas d’un disque dur, le LBA traduit la localisation physique d’une information sur le disque (cylindre, tête de lecture, secteur) en adresse physique adressable par les composants qui veulent y accéder. Dans le cas d’un disque dur, un LBA ne change pas de place. Dans les SSD, ce n’est pas vrai. Par exemple, le LBA 3 peut très bien être stocké à la localisation physique 0 mais la prochaine fois que le LBA 3 sera programmé et réécrit, il pourrait être placé dans la localisation physique 253 ou 2564, etc. Selon Intel, à cause de cela, la performance des SSD varie dans le temps.
 
Pour remédier à cela, le SSD Intel s’adapte à la charge en cours et tente d’optimiser les tables de localisation des données afin d’obtenir les meilleures performances pour n’importe quel workload. Si le but est d’essayer d’offrir les meilleures performances possibles à l’utilisateur en permanence, la contrepartie est que cela crée des résultats inconsistants dans les benchmarks à cause de cette tentative d’optimisation. Cette opération prenant du temps, il faudrait logiquement laisser passer pas mal de temps entre chaque benchmark, ce que nous avons plus ou moins tenté de faire en ne nous concentrant que sur le test pratique de copie de fichiers et PCMark Vantage, avec à la fin un test théorique de mesure des débits pour voir si l’écriture est revenue à la normale. Malhuereusement, ce n'était pas le cas. La difficulté c’est que le temps pour parvenir à un état stabilisé dépend fortement des activités qui ont précédé la tâche actuelle. C’est par exemple ce qu’il se passe avec le test IOMeter qui stresse fortement le SSD à un point qu’il lui faut une longue période pour revenir à une situation normale.
 
Malgré des tests avec de longue période de stabilisation entre chaque cas pratique et une répétition prolongée des tests, nous avons constaté des débits lors des transferts de fichiers toujours un cran en-dessous de ceux observés au tout début. Ce SSD est donc difficile à évaluer car les benchmarks synthétiques ne sont pas consistants dans le temps et que les tests pratiques de transferts de fichiers sont parfois eux aussi touchés par les "optimisations" qu'Intel a mis en place.
 
 
Faut-il réellement s'en inquiéter ?
 
 
Oui et non. Oui car dans certains cas, la perte de performance en écriture est minime tandis que dans d'autres cas, elle est dramatique. Pour illustrer cela, voici un tableau avec des résultats mesurés après 3 cas de figure particulier.
 
 
Le premier cas de figure est la mesure des débits en écriture après une session normale de benchmarks, sans avoir utilisé IOmeter. Il a donc s'agit d'utiliser HDTune Pro, PC Mark Vantage et H2Benchw. Seulement après nous avons effectué la copie des fichiers.
Le deuxième cas de figure est la mesure des débits après une session de 2 heures de IOmeter qui consiste en des écritures 100% aléatoires de fichiers d'une taille de 512 bytes avec une proportion de 20% d'écriture et 80 % de lecture.
Le dernier cas de figure est la mesure des débits en écriture après une session IOmeter de 5x2 minutes qui consiste en écritures 100% aléatoires de fichiers d'une taille de 512 bytes, 4, 16 et 64 Ko avec une proportion de 20% d'écriture et 80 % de lecture.
 
Voici les débits mesurés relatifs aux cas de figure ci-dessus et mesurés après redémarrage du PC :
 
 
                                                       
 
 
 
Comme on le voit, la session de 2 heures de IOmeter ne fait baisser les débits que de quelques Mo/s. Il y a donc perte mais limitée car il est vraisemblable que la durée du test a permis au contrôleur de faire face à cette charge inattendue. Dans le troisième cas de figure, les débits chutent considérablement. Le test IOmeter intense et court semble avoir fortement perturbé le SSD à un tel point que les débits s'effondrent et qu'il faudra du temps et d'autres opérations importantes d'écriture avant de revenir à la normale. Nous avons effet recommencé les tests durant 1 heure après les tests IOmeter pour au final constater inlassablement des résultats proches.
 
Si ces cas de figure sont exceptionnels, ils témoignent de la manière "étonnante" dont Intel gère les écritures sur ce SSD et rien ne dit qu'un jour un utilisateur "de bureau" ne va pas créer scénario engendrant de telles pertes. Intel affirme de manière ferme que ce ne sera pas le cas et cette certitude nous semble quelque peu arrogante ou à tout le moins faisant preuve d'un excès de confiance. Pour bien faire, il faudrait tester ce SSD plusieurs semaines ou mois dans une configuration utilisée quotidiennement et mesurer l'évolution de ses performances.

RamDisk Plus 9 has a most unique feature. Our patent pending technology can access memory beyond the limitation imposed by a Windows 32-bit operating system! In other words, RamDisk Plus 9 can use "unmanaged" Windows' memory e.g. above 4GB. It can also use the stubbornly inaccessable memory between 3.2GB and 4GB.

See the product's help file for detailed explanation of what "unmanaged" memory is and how to access and use it with RamDisk Plus 9.