Connexion
Abonnez-vous

SSD 4600 de Micron : PCIe 5.0 x4 (jusqu’à 14,5 Go/s) et 3D NAND G9

Le 21 février à 08h37

Dans son communiqué, le fabricant explique que son « SSD 4600 est le premier SSD client Gen 5 de Micron ». Il est au format M.2, avec une interface x4, le débit maximum théorique est donc de 16 Go/s. Micron se rapproche de cette limite avec jusqu’à 14,5 Go/s en lecture et 12 Go/s en écriture. Les IOPS sont de 2,1 millions dans les deux cas.

Micron affirme que son « SSD 4600 offre une efficacité énergétique jusqu’à 107 % améliorée (Mo/s par watt) par rapport aux SSD de performance Gen 4 », c’est-à-dire le SSD 3500. Puisque les débits sont doublés, cela signifie qu’il n’y a très certainement quasiment aucune différence sur la consommation. Mais c’est toujours mieux présenté comme le fait Micron…

Le SSD exploite des puces TLC 3D NAND G9 (9e génération). Nous en avions déjà parlé l’été dernier, elles disposent de 276 couches, permettant ainsi d’augmenter la densité. Le contrôleur est un SM2508 (huit canaux) de chez SiliconMotion. La fiche technique est disponible par ici. Le tarif n’est pas précisé.

Ce nouveau venu est donc assez proche du Crucial T705 (Crucial est une marque de Micron, pour rappel). Il est annoncé jusqu’à 14,5 Go/s en lecture et 12,7 Go/s en écriture), avec de la 3D NAND TLC sur 232 couches de Micron. Le contrôleur est un Phison PS5026-E26.

D’autres fabricants n’ont pas attendu 2025 pour passer au PCIe 5.0, une norme finalisée en 2019. On en parlait déjà en 2021 avec le SSD CD7 de Kioxia (PCIe 5.0 x2) et le PM1743 de Samsung (PCIe 5.0 x4, jusqu’à 13 Go/s et 2,5 millions d’IOPS). Corsair aussi répond présent avec son MP700 (PCi 5.0 x4,. jusqu’à 10 Go/s et 1,5 millions d’IOPS).

Le 21 février à 08h37

Commentaires (13)

votre avatar
Toujours aussi bluffant. Le problème derrière est que ces vitesses ne sont réellement exploitables qu'en IO_DIRECT tant la lenteur du cache des pages mémoire limite tout.
votre avatar
généralement, les modèles Crucial sont de ceux qui s'en sortent le mieux sur ce genre de choses.

Pour le Micron, je ne sais pas ce que ça va donner, à voir.
votre avatar
Je parle du cache mémoire, un mécanisme OS donc.
votre avatar
Est-ce que tu aurais une source sur le sujet? Ça m'intéresse. :)
votre avatar
Non mais tu peux tester avec fio avec/sans --direct=1, et si possible fais le en bypassant toutes les couches intermédiaires type fs, chiffrement, lvm etc. histoire d'éliminer les causes potentielles. Par ex chez moi j'obtiens à peine 50% de perf (100% = 7go/s) sans accès direct.

Et le pire c'est que la copie classique userland type read()/write() avec O_DIRECT est plus rapide que les syscall kernel land conçus pour tels que sendfile(). Même constat pour Linux et Windows.

La lecture/écriture directe a des limites (concurrence, alignement mémoire, absence de cache évidemment, etc.) mais par contre le périphérique peut être utilisé à son plein potentiel.
votre avatar
Le cache est assez utile (notamment pour l'écriture en continue de petis fichiers type log), du coup le désactiver faut avoir un cas d'usage franchement particulier :)

Là je comprends qu'il y'a un "bottleneck" au niveau du CPU ou de la mémoire sur ta machine, qui n'arrive pas à sortir plus de 7go/s en continue ?
votre avatar
Il est utile dans certains et cas et limitant dans d'autres, c'est pour ça que je ne conseillerai pas de le désactiver aveuglément. Le use-case où il est limitant de manière flagrante est la copie de gros fichiers type films/séries/VM.

Ma machine est en ryzen 7000 + DDR5 à 5600mhz donc si cette conf n'est pas suffisante je ne sais pas ce que l'on peut faire de plus.
votre avatar
Le use-case où il est limitant de manière flagrante est la copie de gros fichiers type films/séries/VM.
bah 2sec au lieu de 1sec pour déplacer un film de 2h ~7go, je suis même pas sûr que le use-case soit si significatif :) Surtout que sous linux les déplacement ou copies sont "transparentes" le fichier est immédiatement disponible / utilisable au nouvel endroit, le sous système se chargeant d'accéder les données là où elles sont. (Contrairement à windows qui verrouille le fichier pendant le déplacement).
votre avatar
Le rapport TBW/Capacité (600), à l'instar de tous les SSD actuels, est vraiment pourri. Tenu compte de la write-amplification liée à la gestion des flashs par le contrôleur, cela veut dire qu'on est sur des mémoires flash supportant entre 1 et 2k cycles d'effacement de leurs secteurs physiques.

On en arrive à une endurance divisée par 100 comparé aux SLC initiales!

Bref, tout ceci ne tiens que tant qu'on n'utilise intensivement qu'une faible fraction de la capacité de ce genre de stockage.

C'est sans doute généralement le cas, mais pour du stockage statique/de long terme, un HDD est moins cher et comme on n'a pas besoin de perfs faramineuses dans cet usage, je ne comprends toujours pas bien cette fuite en avant sur les capacités des SSD.

Si encore on permettait de les configurer pour utiliser les flashs intégrées en mode pSLC (avec une capacité divisée par le nb de bits/cellule des flashs intégrées), au moins l'utilisateur pourrait choisir une gestion plus saine et efficace s'il compte avoir un usage très intensif sur une fraction de la capacité. Les eMMC, c'est dans la norme (même si en general cette configuration one-time-programmable est hélas toujours déjà verrouillée d'usine pour les produits grand public qui en intègrent).
votre avatar
Pour résumé, comme l'endurance l'augmente pas, si on utilise vraiment le disque, la vitesse supplémentaire permet juste de les griller encore plus vite.
votre avatar
L'endurance se casse plutôt la gueule, mais comme pour la majorité des usages l'utilisateur n'en stresse qu'une infime fraction, les algos de wear levelling distribuent l'usure sur la totalité de l'espace et ça se voit pas trop...

Mais je vois pas trop le bon deal d'acheter un espace énorme et de compter dessus pour distribuer l'usure.

Ou a la limite donner le choix à l'acheteur avec une configuration à réception du SSD, vu que les flash MLC/TCL/QLC actuelles peuvent toutes fonctionner en pSLC (ou pseudo-SLC, avec capacité divisée par le nb bits/cell nominal) ce qui les fait pas remonter à une SLC et ses 100k cycles d'effacement, mais on est dans les 30k ou lieu de 1 ou 2k tout en bénéficiant des prix/volumes des xLC vs SLC (devenue hors de prix, même pour les applications embarquées ou tout est passé pSLC niveau eMMC et eUSB).
votre avatar
Ce n'est pas parce que le "disque" lit/écrit plus vite que tu vas y lire ou écrire plus de trucs. La "rapidité" d'usure est plus lié au taux de remplissage : un disque plein à moins de place dispo pour diluer les écritures sur un grand nombre de cellules "libres".

Après si tu ne fais que des benchs d'écriture stressant, oui il y'a théoriquement moyen de cramer assez rapidement ce SSD. Le 2to à 12Go/s d'écriture il faudrait (en théorie) 2min47 pour le remplir complètement, soit environ 8j pour écrire complètement 4000 cycles.
Sauf que les 12go/s ne tiennent probablement que quelques secondes avant surchauffe et baisse drastique de la vitesse d'écriture.
votre avatar
le PM1743 de Samsung (PCIe 5.0 x4, jusqu’à 13 Go/s et 2,5 millions d’IOPS)
Ils utilisent une autre unité pour l'endurance du SSD : 1 DPWD, page 4 https://download.semiconductor.samsung.com/resources/white-paper/PM1743_White_Paper_240510.pdf ou l'art de toujours embrouiller les gens

On en parlait déjà en 2021 avec le SSD CD7 de Kioxia (PCIe 5.0 x2)
eux ils utilisent aussi le DWPD : https://www.ssd.group/wp-content/uploads/2022/07/CD7-Promotion-Material_20210120.pdf (veuillez noter le confidential en bas du document :francais:)

Le DWPD, quant à lui, adopte une perspective légèrement différente et calcule le nombre de fois qu’un SSD peut être entièrement écrit, par jour, au cours de sa durée de vie garantie. https://www.kingston.com/fr/blog/servers-and-data-centers/understanding-ssd-endurance-tbw-dwpd

SSD 4600 de Micron : PCIe 5.0 x4 (jusqu’à 14,5 Go/s) et 3D NAND G9

Fermer