Test • WD_Black SN8100 (SM2508 + TLC 218L)

Des chiffres et des lettres (mais surtout des chiffres)

Dans un scénario optimal, le SN8100 surpasse effectivement ses concurrents y compris dans les accès aléatoires

Topo plus nuancé avec une seule instruction à gérer en mono thread : il est en léger retrait en séquentiel et mieux sur les lectures aléatoires

Avec l'utilisation de set de données incompressibles, les chiffres atteints sont, à l'instar de ceux du 9100 Pro, très haut dans la hiérarchie des résultats en SSD gen 5 : on peut épiloguer sur quelques différences notoires, mais la vérité annoncée reste que le couple SM2508 + BiCS 8 offre d'excellentes performances sans pour autant rien éclater de ce qu'on l'on connait déjà. Certes, une plateforme de test à base de X870e pourrait afficher des résultats plus flatteurs pour le profane en allant taper les 14,9 Go/s à fond de six : un gap qui restera totalement imperceptible à l'usage.

Même constat donc que celui que nous avions fait sur les autres unités PCIe 5.0 : ce premier jet synthétique des performances continue de nous indiquer que les unités PCI 4.0 sont encore loiiiiin d'être hors course.

Et une fois chiffré ?

Sieur SN8100 en mode bitlocké

Malgré la présence de coprocesseurs dédiés au chiffrement dans les contrôleurs, l'activation du chiffrement logiciel reste généralement pénalisante pour les performances d'un SSD. Par simple curiosité, nous avons activé BitLocker sur le système Windows de notre banc d'essai pour mesurer son impact... du moins dans le contexte de ce benchmark qui, fonctionnant dans des conditions optimales, constitue évidemment un cas d'usage idéal pour ce type de test.

Un petit coup de remplissage de disque en écriture linéaire pour voir comment le disque se tient au cours de cette opération qui est censée nous indiquer, entre autres, la quantité de TLC utilisée en pSLC, disque vide. Cache pseudo SLC qui comme on peut le voir est ultra large avec ~640 Go (soit un peu moins de 30 %) sous un niveau de performances proche des 12,9 Go /s.

Dans cet exercice, le SN8100 montre une belle prestation jusqu'à saturation du cache où le débit prend une première douche à 3750 Mo/s — ce qui reste excellent — puis une seconde mettant le contrôleur plus à la tâche au-delà de 750 Go écrits, se traduisant alors par des oscillations comprises environ entre 750 Mo/s et 3 Go/s. Pour grossir le trait, au lieu d'écrire 1 bit par cellule et gérer deux niveaux de tensions avant d'envoyer tout cela en RAM, le contrôleur devra écrire directement 3 bits par cellules et gérer huit niveaux de tensions, tout en sollicitant forcément davantage les algorithmes ECC et le garbage collection... Ainsi que le folding, c'est-à-dire le vidage de cache SLC existant.

Ce test ayant été réalisé cette fois en QD4, cela préfigure d'emblée que si le SN8100 affiche de gros chiffres quand tous les voyants sont au vert, une fois blindé d'instructions et dénué de cache, il se comportera exactement comme ses petits copains concurrents, comprendre pas forcément mieux. Détaillons ci-dessous la suite des évènements :

Le protocole pour les SSD

L'arrivée des SSD pour le grand public vers 2009 est la dernière grosse révolution en date des PC, accélérant les goulots d'étranglement et amenant les I/O disques à des niveaux d'échanges très rapides. En résultent des OS lourds comme un Windows – au hasard – très réactif et des réductions sur les temps de chargement d’applications sur des facteurs stupéfiants par rapport à ces bons vieux disques mécaniques.

Beaucoup de médias et autres influenceurs présentent en guise de test une série de screenshots issus d'applicatifs synthétiques dévoués à la tâche, la plupart du temps pas ou peu paramétrés, présentant de fait des chiffres, certes en accord avec les promesses des fabricants, mais peu ou pas représentatifs d'un usage utilisateur réel. On trouve également des comparatifs de temps de chargement d'applicatifs divers voire de jeux vidéo, parfois réalisés sur des plateformes différentes... Ahem. Soyons clairs, un SSD reste un SSD et les différences de performances de chargements lambdas (comme un jeu vidéo) ne seront pas flagrantes voire imperceptibles entre un bon vieux performer SATA et un NVMe de dernière génération.

D'un autre côté, couvrir tous les usages de tout à chacun serait un exercice rébarbatif et lourd dans sa mise en œuvre comme pour la présentation des résultats finaux que de toute manière personne ne lira. Nous avons fait le choix au Comptoir du vous proposer une approche mixée simple & rapide à consulter couvrant deux usages soutenus de l'unité sur banc. Dans un premier temps vous retrouverez un aperçu très rapide via un test synthétique qui pourra toujours vous donner une idée des perfs dans des conditions idéales de fonctionnement. Dans un second temps donc, deux routines de tests aux I/O parfaitement reproductibles simulant une charge importante tant en lecture qu'écriture dans un environnement où le disque est déjà en activité, et pas benché out-of-the-box :

• Le disque durant tous les benchs sera rempli à ~50% de sa capacité utile ;
• En prémices de chacun des deux tests, le reste du disque sera complètement rempli à plusieurs reprises notamment pour court-circuiter les process d'overprovisionning et d'amplification d'écriture ;
• S'en suivent immédiatement les étapes de benchs à proprement parler qui se déroulent en 2 phases : durant la première, l'unité est surchargée d'opérations d'écritures, puis la routine de bench est lancée. On répète cette phase à 14 reprises que l'on mesure : le but est encore d'empêcher le disque d'exécuter ses routines d'optimisations et de voir comment il se comporte dans un scénario où il sera lourdement sollicité ; durant la seconde phase, le disque va être laissé au repos quelques minutes, cette fois pour qu'il se réorganise, avant qu'à nouveau la routine de bench soit exécutée et mesurée. Cette phase sera répétée 5 fois, ce qui doit laisser largement le temps au disque de restaurer ses performances optimales.
• La première routine de test va effectuer un peu plus de 20 Go de copies de données réparties sur un nombre restreint de fichiers, donc des gros blocs de datas : priorité aux accès séquentiels en écriture ;
• La seconde routine va quant à elle exécuter un projet Photoshop et utiliser massivement des I/O des sous-systèmes mémoire + stockage : priorité aux accès aléatoires en lecture & écriture ;

Au terme de ces procédures qui durent plusieurs heures en fonction de la taille du disque, plusieurs dizaines de To auront été écrits sur le disque avec des pauses contrôlées en phase 2, en résultera une activité que l'on peut considérer comme sollicitant et qui montrera les limites, comme les qualités, du disque testé.

Une partie de matériel du banc de test (qui envoie du bois)

↓
Petits rappels sur les fondamentaux ?
Anatomie d'un SSD • • Endurance des SSD 1ère partie & 2ème partie