SSD PCIe 5.0 : les contrôleurs Phison et Silicon Motion dépassent les 14 Go/s
Et ma clé USB dépasse péniblement les 30 Mo/s...
Au fil des années, les SSD ne cessent de gagner en vitesse et en capacité avec la densification des puces de NAND et l'amélioration des contrôleurs. La dernière norme actuellement utilisée est le PCIe 5.0, capable de proposer jusqu'à 16 Go/s pour des SSD x4. Des SSD et des contrôleurs existent déjà, mais de nouveaux modèles sont en approche avec des performances améliorées.
Comme chaque année, le Flash Memory Summit est l'occasion de plusieurs annonces de la part des constructeurs sur leurs dernières nouveautés. SK hynix présentait par exemple la première puce de NAND avec plus de 300 couches.
Phison revient une nouvelle fois avec son contrôleur PCIe 5.0 E26, déjà présenté l'année dernière. Le fabricant exposait alors les résultats d'un test maison sur CrystalDiskMark, avec jusqu’à 12,36 Go/s en lecture et 11,79 Go/s en écriture.
L'E26 de Phision grimpe à plus de 14 Go/s en lecture
Cette année, Phison grimpe plus haut et se rapproche des limites théoriques du PCIe 5.0 en x4 (16 Go/s pour rappel) puisqu'il est question de plus de 14 Go/s en lecture et de 12,5 Go/s en écriture. Pour rappel, ce contrôleur prend en charge huit canaux avec un débit maximum de 2 400 MT/s (ou mégatransferts par seconde) pour chacun d'entre eux.
Le SSD en question (dont nous n'avons pas plus de détails techniques) était équipé d'un système de refroidissement Frore Systems comprenant deux AirJet Minis. Ces derniers prennent la forme de petits rectangles de 27,5 x 41,5 mm avec une épaisseur de 2,8 mm seulement.
Sous les deux AirJets Minis et le radiateur en cuivre, le SSD avec contrôleur E26.
Ils proposent un refroidissement actif, avec un niveau de bruit de 21 dB selon le constructeur. Le débit d'air n'est que de 0,21 CFM, c'est très peu. Pour comparaison, un ventilateur de 12 cm Noctua est entre 30 et 60 CFM, contre 5 à 6 CFM pour un modèle de 4 cm. Il faudra voir si c'est suffisant pour calmer durablement les ardeurs d'un SSD M.2 en PCIe. Ils ont en effet fortement tendance à chauffer et alors à baisser leurs performances.
En plus de dépasser les 14 Go/s sur CrystalDiskMark, ce SSD est selon Phision capable d'atteindre « plus de 1 000 Mo/s de performances sur le test stockage de PCMark 10 ». Il s'agit selon le fabricant d'une « première mondiale pour un SSD M.2 basé sur de la NAND ».
SM2508 : jusqu'à 14 Go/s, 2,5 millions d'IOPS et 3,5 watts
Silicon Motion répond également présent au Flash Memory Summit avec un contrôleur SM2508 lui aussi capable d'atteindre 14 Go/s, aussi bien en lecture qu'en écriture. Il prend toujours en charge huit canaux, mais chacun jusqu'à 3 600 MT/s cette fois-ci. Le constructeur promet jusqu'à 2,5 millions d'IOPS en lecture aléatoire, contre 2,4 millions en écriture.
Pas de benchmark cette fois-ci pour appuyer ses dires, mais un simple communiqué de presse. Le contrôleur prendra en charge les puces de 3D NAND en TLC et QLC (respectivement trois et quatre bits par cellule), pour une capacité totale du SSD de 8 To au maximum. La consommation du contrôleur est de 3,5 watts et NVMe 2.0 est de la partie.
Commentaires (32)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 10/08/2023 à 07h27
3,5 Watt ! Ca comment à sérieusement consommer du courant ces petites bêtes.
Le 10/08/2023 à 08h33
D’autres contrôleurs PCIe 5.0 montent à 10watts, mais la les 3,5W on ne pas si c’est la valeur crête
Le 10/08/2023 à 11h34
Je trouve cela pas beaucoup, comparé à la conso globale de mon PC qui, en jeu, est à environ 650W
Le 10/08/2023 à 12h06
Et encore, quand je vois ce que ça donne avec des APU AMD, avec VK3D/DXVK + FSR sous Linux… J’ai un laptop pro type Thinkpad X13 AMD Gen 2, qui consomme grand max 25 à 35w à fond les ballons, chauffe peu, avec des jeux qui tournent en 1080P@30fps dessus qui ne le devraient pas, pour une conso ridicule. J’arrive à un rendu à mi chemin entre une PS4 et une PS5, me suffisant pour mes usages.
Au niveau conso énergétique, ces outils ont permis une avancée folle en matières de FPS/watt, très loin des grosses alim de PC gaming…
Le 10/08/2023 à 21h20
Oui évidemment. Mais ca commence a chauffer et a consommer, avec chaque génération qui promet des debis encore plus élevé.
Le 10/08/2023 à 08h02
Les performances sont alléchantes, mais si ça commence à faire du bruit, chauffer et consommer trop d’électricité, c’est moins intéressant.
Le 10/08/2023 à 08h09
Je trouve pour ma part assez dommage qu’avec la densification des flash (3 bits/cell, c’est 8 états et 7 niveau de comparateur de charge ; 4b/c, on monte à 16 états/15 niveaux) on ne trouve pas sur les SSD les configurations (one-time, pour la vie du module) dispo/normalisées en eMMC:
-Applications grand public, on privilégie la capacité avec un fonctionnement des flash nominal.
-Applications industrielles, on privilégie la fiabilié (TBW rapporté à la capacité dispo) et durée de rétention des données (fatalement plus facile d’éviter les bits qui changent avec la déchare naturelle des cellules avec 1 niveau de comparaison de charge stockée que 15) avec un fonctionnement de type 1 bit/cell de ces flash multi-bit/cell (dit pLSC, ou pseudo SLC).
Certes, on tombe au tiers ou au quart de la capacité, mais c’est pour multiplier par 10⁄15 les caractéristiques de fiabilité. Chose impossible à atteindre même en sous partitionnant (ou alors pas vraiment au tiers ou au quart de la capacité dispo… mais au dixième au moins!), vu qu’on se paie toujours la gestion multi-niveaux.
Manière de bénéficier des prix des flash grand public tout en se rapprochant des fiabilités des SLC devenues hors de prix.
Le 10/08/2023 à 08h14
J’ai signalé la typo mais elle m’a bien fait rigoler
Le 10/08/2023 à 08h31
3,5W auxquels il faut ajouter la conso de système de refroidissement: jusqu’à 2W…
5,5W c’est la moitié de la conso de mon serveur Proxmox avec une 20aines de service qui tournent dessus dons un Gitlab, Nextcloud, Plex, Prometheus, … c’est abusé.
Pour du composant de ce type, que j’appellerais “passif”, quand il n’y a pas d’I/O, soit ce que fait un NVMe 99,9999% du temps, la conso devrait être proche de 0, juste de quoi le réveiller si besoin.
Le 10/08/2023 à 08h35
Simple curiosité : quelle est la configuration de ta machine qui fait tourner ton Proxmox ?
Je suis curieux d’une si faible conso de ta machine pour tourner de tels services. Les performances sont là ? :)
Le 10/08/2023 à 08h50
Comme Furanku, je suis épaté qu’une machine qui consomme seulement 10-12 W puisse faire tourner un serveur plex. le décodage vidéo est coûteux en opérations/transistors, donc en consommation.
Le 10/08/2023 à 11h52
Faut psa oublier le reste du SSD, même si le gros de la conso sera le contrôleur (et le refroidissement)
Je crois que la lecture est mauvaise du commentaire précédent ;)
C’est ce qu’il dit :
Le 10/08/2023 à 08h45
Bof, je suis pas d’accord. Je pense sincèrement que très peu de NVMe seront usé a plus de 5% alors qu’ils seront remplacé pour une capacité plus grosse. Donc la fiabilité pour du grand public, c’est pas super important.
Et plus grosse capacité de stockage = plus de stockage de fichier statique. Donc clairement, 1 ou 64 bits par cellule, ca ne changera rien au final, certaine cellule n’auront été écrite qu’une fois pour toute la vie du NVMe pour stocker la photo de tonton gégé ou du film de vacances.
Exemple perso (qui ne représente pas grand chose, mais permet de quantifier un peu), mon PC pro, utilisé au moins 8h par jour, avec quelques VMs, des containers Docker, que j’utilise depuis 4 ans (03/07/2019 exactement), NVMe type “Grand public” de 512Go:
A ce rythme là, il pourrait tenir 40 ans… Pour le même prix, j’aurais préféré un NVMe usé à 50% avec 1 ou 2 To de capa à la place. Surtout qu’avec plus de capa, j’aurais moins supprimé/ré-écrit certaines donnée comme des ISO ou du cache d’image docker.
Le 10/08/2023 à 08h59
HP Prodesk 400 g3 (USFF)
2 x Intel® Celeron® CPU G3900T @ 2.60GHz (1 Socket)
RAM: 16 GB
SSD NVMe EMTEC X300 256Go pour l’OS
SSD SATA Samsung 860 EVO 4TB pour les data
Coté perf, c’est parfait pour mon “cloud perso”.
Il faut penser à mettre le plugin de génération en background des miniatures pour Nextcloud (trop lent de le faire en temps réel si beaucoup de photo)
Pour le Plex, le CPU devrait pouvoir transcoder plusieurs flux en h264 sans soucis. Perso, je n’en ai pas besoin et j’ai pas envi de faire tourner de LXC en privilégié, donc pas testé.
Conso: 10-11W relevé au wattmetre à la prise 230V idle (99,99% du temps avant que je mette gitlab). Depuis que j’ai mis gitlab, qui utilise 10~15% de CPU en permanence, j’imagine que ca a du monter un peu.
Je me tate à changer pour une machine plus récente avec un CPU N100 qui ont l’air vraiment économique coté électrique.
Le 10/08/2023 à 09h04
Merci pour ces info
J’ai également une Proxmox qui fait tourner du Plex, *arr et autres. Mais je tourne par contre sur quelque chose de plus véloce (mon ancien PC upgradé en RAM + stockage)… mais malheureusement ça se sent sur la conso élec (~12€/mois) :/
Par contre j’aurais pas équivalent au même prix chez n’importe quel hébergeur. Donc bon.
Mais ça fait réfléchir.
Le 10/08/2023 à 09h03
Je ne fais pas de transcode, mais de toute façon tu ne transcode pas 24⁄7, ce qui compte, c’est la conso idle qui représente 99% du temps, quand la machine ne fait rien.
Par exemple, j’ai aucun problème à ce que ma pompe à chaleur consomme 2000W quand elle tourne, car elle produit quelque chose. Par contre, une ancienne barre de son que j’ai testé qui consommait 7W en veille à ne rien faire, bah je l’ai rendu direct.
Le 10/08/2023 à 09h18
Chez moi, la conso est le critère n°1. Quelque soit la perf, si ça consomme, ça rentre pas chez moi :)
Petite alimentation (de laptop pour le Prodesk) mais sinon j’aurai un PicoPSU. SSD only, aucun HDD (environ 5W par bête en moyenne), CPU basse conso (Celeron) en version portable (T).
Pour le Plex, j’ai 13 contacts qui l’utilise (famille, amis, collègues, …) mais c’est leur TV qui décode directement, donc meilleur qualité final, pas besoin que le transcoder bufferise, mais je n’ai que des contenus encodé proprement en h265/DD ou DTS uniquement, pas de pièges avec des codec chelous que les TV ne décodent pas, ca juste marche.
Le 10/08/2023 à 09h37
Pour ma part j’ai une approche différente… Tout est encodé via x265/VBR directement; et j’ai lancé un simple partage SMB.
Le tout sur un simple NUC Celeron 3965U + 8Gb de ram & SSD, et les HDD sont présents sur ports USB.
Consommation énergétique très réduire du coup.
Le 10/08/2023 à 12h04
Effectivement, du coup, ça empire encore plus le bilan! Pour moi, ces NVMe typé grille-pain, c’est no-way.
J’avoue que j’ai eu du mal a comprendre le commentaire avec les parenthèses à rallonge. :)
Le 10/08/2023 à 13h37
Le 10/08/2023 à 12h08
Je trouve pas l’approche si différente, le contenu est encodé en h265, comme chez moi, et c’est le client qui décode directement. Ton NUC ne transcode pas.
Le dossier qui contient les média est accessible via Plex et un apache-httpd en mode Index sur le net, et via SMB en plus coté LAN.
Le 10/08/2023 à 13h45
Ca n’oblige pas le client à avoir la bande passante suffisante pour lire la vidéo au format d’origine ?
Le 10/08/2023 à 13h52
Si, mais avec TV Plex pour des media de 2h de 10Go, on est large. Après, c’est sure que pour regarder Avatar 2 sur son mobile dans le RER, bon bah c’est mort :) suffit de récupérer le fichier et de regarder en offline.
Le 10/08/2023 à 14h22
Sauf qu’il faut tenir compte de la gestion d’usure (qui va égaliser l’usure et fatalement bouger des données “statiques” du point de vue utilisateur)… et de la décharge naturelle de la cellule qui devient un problème vu que, fatalement, si on gère avec des niveaux de comparaison multiples (au lieu d’un seul placé bas, pour lequel il y a de la marge pour qu’un bit stocké à 1 passe à 0 de ce fait), les erreurs arrivent plus vite dans le temps.
Alors en réalité, la photo de tonton va être régulièrement ré-écrite ailleurs (même si la flash-translation-layer le masque) par la gestion du wear-levelling d’une part et si on ne veut pas qu’elle subisse une dégradation encore plus rapide qu’une photo sans même évoquer le négatif de l’époque argentique d’autre part.
Il est donc faux de dire que les données statiques ne sont ré-écrites qu’une fois. Du point de vue utilisateur, c’est vrai mais trompeur.
Ce sera même de plus en plus nécessaire avec le nombre de cycles d’effacements car la durée de rétention des données baisse avec ce nombre de cycles… et comme les flash n’en supportent plus vraiment 100k (comme les SLC) mais généralement désormais dans les 3k au mieux, on comprends que cette durée de rétention des données tombe vite sous l’année: Le datasheet d’une flash intégrée dans un SSD spécifie généralement une durée de rétention à son maximum (typiquement 5 à 10 ans) pour un secteur à 0 cycles d’effacement et à son minimum quand on a atteint le nb max de cycle spécifié. Ca suit assez bien, en proportion inverse, la courbe de durée d’un cycle d’effacement en fait qui n’est d’ailleurs pas linéaire (évolution plus rapide au début).
J’ai testé des flash (niveau composant, sans un contrôleur en interface) à plusieurs fois ce max, généralement cela fonctionne assez loin si on mets des timeout d’attente d’effacement très larges, mais la mauvaise surprise c’est qu’une semaine après le % de bits en erreur se compte déjà sur les doigts d’une main.
Les seules flash gérées en direct faisant exception sont celles destinées aux applications “automotive” (voir même simplement embedded, chez les bons fabricants comme Micron, qui ne vous le confirment oralement que quand on leur demande explication après avoir constaté la bizarrerie!): Elles ont en fait un wear-levelling intégré/simplifié niveau composant, avec une courbe de temps d’erase d’un même secteur en dents de scie. Montée régulière puis au lieu de continuer jusqu’à la fin, retour brutal à des données de secteur neuf (après un nb de cycle à quelques % des max spécifiés) et ainsi de suite. Ce qui marche bien tant qu’on ne teste qu’une fraction de la capacité pour vérifier qu’un fabricant ne se fout pas ouvertement de vous!
Pour un SSD (flash derrière contrôleur qui en fait une machine à lire/écrire des blocs logiques de manière très classique vu de dehors) plus que les données smart, gérées par un constructeur aimant rassurer (et éviter de provoquer lui-même des demandes en garantie!), mieux vaut AMHA se fier à une baisse de performance car la durée d’un cycle d’effacement monte aussi avec leur nombre. C’est d’ailleurs l’atteinte d’un timeout d’attente dessus qui va provoquer la fin de vie d’un secteur de flash décidée par le contrôleur (et taper dans son % de réserve, ou tout début d’évolution marque en fait qu’on a déjà tapé le gras et qu’on attaque le muscle en attendant l’os).
J’ajouterais que pour un cas d’usage media extractible de sauvegarde des photos de tonton, qui passe 99% de son temps au moins non utilisé (donc son contrôleur, cachant normalement la misère, dans l’impossibilité de le faire étant non alimenté), il vaut mieux en rester au HDD.
C’est d’ailleurs la raison pour laquelle les cartes mémoires et autre clef USB n’intègrent qu’une gestion d’usure dite dynamique et non statique: Aucun temps dispo/alimenté pour des opérations qui se font en tâche de fond.
Et aussi celle d’apparition des spécifications Ax (Applicative : A1/A2 actuellement, A2 offrant plus d’IO/s) pour les cartes uSD, qui a été faite pour l’utilisation en extension de stockage interne des smartphones donc un usage 24⁄7 malgré que ce soit un media “extractible”! Leur gestion est plus proche d’un SSD classique (gestion d’usure dite statique) et elles sont aussi une option pour les utilisateurs intensifs de Raspberry PI, qui avant elles fumaient de la SD à la chaîne et sont tout à fait conscients que la mémoire flash est par nature un media peu fiable sans une gestion complexe au dessus!
Le 10/08/2023 à 14h49
Je ne connais pas tout les secrets qui permettent d’augmenter artificiellement la durée de vie des SSD en optimisant/répartissant/ré-écrivant les cellules, mais le fait est que ça fonctionne plutôt bien.
A part un SSD DOA (dead on arrival), je n’ai jamais eu de soucis d’usure aucun de ma 15⁄20 aines de SSD achetés au fil des ans (mon plus petit étant un SSD SATA Samsung de 16Go pour donner un ordre d’idée).
Donc personnellement, je n’aurais pas peur d’acheter des SSD en PLC quand ça sera disponible pour stocker du film de vacances, pourvu que ça ne consomme rien électriquement en idle et que j’ai une capacité maximum pour le prix…
Pour les cartes SD, je suis 100% d’accord et ca fait bien longtemps que je n’utilise que des cartes industriel et automotive dans mes RPI, et plus aucun problème de stockage. Alors qu’elles mourraient au bout de 2 mois auparavant, même en faisant gaffe.
Au passage, je viens de regarder l’évolution du prix que je sais qu’il a explosé:
Sur ma facture du 31/12/2019: j’avais payé mes 3 cartes ATP AF8GSD3A-WAAXX à $4.3533 HT l’unité
Aujourd’hui, je google rapidement: 67,22€…
La AF8GUD3A-WAAXX à \(11.84 HT l'unité
La AF32GUD3-WABXM à \)7,51 HT l’unité
délirant
Le 11/08/2023 à 07h07
Bonjour,
Petite question idiote concernant les compatibilités :
Quant à la technologie d’enregistrement il me semble que en SLC il n’y a plus que les caches ; la mémoire effective n’est plus qu’en TLC ou QLC et les SSD en MLC encore trouvable sont totalement hors de prix pour les particuliers. Comme critère de choix personnellement, je regarde les perf mais aussi la durée de garantie préférence pour 5 ans (bien que j’ai des doutes sur un échange éventuel de SSD après plus de 3 ans d’usage) j’évite les QLC pour l’instant mais d’ici un moment on trouvera du HLC ou du DLC (décaLC). puis du kiloLC
Le 11/08/2023 à 09h40
Pour les 2 questions, oui car le PCIE est rétro-compatible
Le 13/08/2023 à 17h59
Le PCIe est toujours compatible toutes vitesses et toutes largeur, il s’aligne automatiquement sur le plus lent et le moins large. Pour les cartes mères sans port M.2, on peut utiliser une carte d’adaptation pour brancher un SSD M.2 sur un connecteur PCIe, quelle que soit sa version et sa largeur, ça fonctionne toujours, juste qu’on ne peut pas démarrer dessus.
Le 11/08/2023 à 19h16
Et ce n’est que le contrôleur, il faut inclure le reste du SSD.
Certains SSDs rapides montent à 10,7 W en pointe (cf Maximum Power Consumption). Et la chauffe peut être telle que ça throttle au point d’être aussi rapide qu’un… HDD.
Il faut donc les refroidir mais dans ce cas quel est l’intêret de ce format ? Surtout qu’avec nos cartes graphiques, il arrive qu’un SSD soit en dessous donc le refroidir est juste impossible sinon la plaque de cuivre de 2 mm d’épaisseur maximum pour aider à la dissipation.
Du coup je ne m’embête pas : je prends des Gen 3 (en particulier pour les ordinateurs portables), ils chauffent moins et puis 10 Go/s, à quoi bon franchement ? En plus c’est un peu moins cher.
On pourrait dire que c’est moins évolutif mais je prévois d’en faire des “grosses” clés USB le jour où je les remplace, or l’USB-C a encore du mal à aligner plus de 1 Go/s sur la plupart des cartes mères.
Le 14/08/2023 à 07h44
un M.2 en PCI-E sur un port Thunderbolt c’est bien pratique pour servir de clé USB (compatibilité avec l’USB 3.x au passage)
Du coup, les 1Go/s ils sont bien dépassés
PS : un avantage des MAC et des machines “pro” avec processeur Intel depuis quelques années.
Sur l’USB 4.0 par contre la donne change, mais c’est pas hyper rependu sur l’AMD il me semble :/
Le 12/08/2023 à 16h22
Faut quand être un peu honnête. Un SSD qui throttle au point d’être plus lent qu’un HDD, c’est qu’au bout de x Go de copie, et uniquement lorsqu’on compare du séquentiel. Un HDD qui fait du random, nativement sans throttle, ça descend sous les 1Mo/s…
Le 13/08/2023 à 18h12
Oui, c’est vrai.
Les chiffres les plus bas que j’ai lu sont 55 secondes d’écriture ou 86 de lecture, à environ 5 Go/s sans refroidissement. C’est en théorie beaucoup de Go et donc des usages bien spécifiques pour les faire tomber.