'Silicon Motion werkt aan PCIe 6.0-ssd-controller met snelheden tot 28GB/s'

Silicon Motion werkt aan een SM8466-controller, meldt het Chinese techmedium IT Home. Deze zou gebruikt worden om PCIe 6.0-ssd's mee aan te sturen. Volgens de fabrikant ondersteunt de controller snelheden tot 28GB/s. Het gaat vooralsnog om een controller voor enterprise-ssd's.

De SM8466 zal beschikbaar komen in de Silicon Motion MonTitan-serie, schrijft IT Home. Die producten zijn vooral gericht op gebruik in datacenters. De controller wordt door TSMC geproduceerd op een 4nm-procedé, terwijl de huidige MonTitan SM8366 nog wordt gemaakt op 12nm. De nieuwe SM8466 krijgt verder een PCIe 6.0-interface met vier lanes en ondersteunt de NVMe 2.0-standaard.

Volgens een Silicon Motion-slide kan de SM8466 sequentiële leessnelheden tot 28GB/s halen, zo schrijft IT Home. De willekeurige lees- en schrijfsnelheden zouden neerkomen op 7 miljoen iops. Dat is in beide gevallen ongeveer een verdubbeling ten opzichte van de SM8366. Verder ondersteunt de nieuwe controller ssd's van maximaal 512TB, terwijl zijn voorganger tot 128TB ondersteunde.

De PCIe 6.0-standaard werd in 2022 al afgerond. De interconnectstandaard verdubbelt de snelheden ten opzichte van PCIe 5.0. Op een interface met vier lanes, zoals gebruikelijk is bij ssd's, bedraagt de theoretische snelheid van PCIe 6.0 daarmee maximaal 32GB/s. De SM8466 haalt dus iets lagere pieksnelheden. Micron ontwikkelde eerder al een datacenter-ssd met PCIe 6.0 en claimde snelheden tot 26GB/s.

IT Home schrijft dat de SM8466 volgende maand officieel wordt aangekondigd tijdens het FMW 2025 Global Flash Memory Summit. Het is niet bekend wanneer de eerste datacenter-ssd's met de controller zullen verschijnen. Het zal op zijn vroegst in 2026 of 2027 zijn: de huidige datacenterplatforms van AMD en Intel ondersteunen nog hooguit PCIe 5.0. Consumenten-ssd's zullen nog langer op zich laten wachten.

De SM8466-slide van Silicon Motion. Afbeelding via IT Home

Reacties (55)

[djwice]

@AverageNL
Wow dan is de NVMe net zo snel als DDR4-3200 (~ 26GB/s). het enige verschil is dat de toegangstijd geen 10ns maar 1/40ste milliseconde is.
En het heeft miljoenen iops.

Voor veel toepassingen waar nu geheugen gebruikt wordt voor caching is 0.025 ms toegangstijd ruim snel genoeg.

Dit heeft dus als gevolg dat je de cachelaag er tussen uit kunt halen. Je IT-architectuur versimpeld, je krijgt een hogere uptime en lagere kosten. Databases (ook NoSQL) die nu met primary key een object ophalen en uitleveren kunnen worden vervangen door simpele opslag. Dus lagere licentie kosten en minder infrastructuur complexiteit.

Gaaf!

[Reactie gewijzigd door djwice op 13 juli 2025 12:58]

[laurxp]

Het probleem is dat die 28GB/s alleen voor sequentiële toegang is. Ga willekeurig lezen en schrijven en de bandwidth gaat flink onderuit. Daarnaast heb je ook nog eens te maken met "write amplification": één byte schrijven duurt net zolang als een block van 8kB, dus zoiets als memcached voor een "views per video" counter wil je alsnog niet direct naar de SSD doen.

Ook zitten we niet meer op DDR4: DDR5 is al een aantal jaartjes de standaard, en DDR6 zal ook niet lang op zich laten wachten. De geruchten daarvoor zijn dat ze zo'n 130 GB/s kunnen doen per module, en een Epyc-server heeft natuurlijk 12 geheugenkanalen. Dat is een bandwidthtotaal van 1500GB/s - dus zo'n 50x sneller dan deze nieuwe SSD.

De switch naar NVMe SSDs heeft caching zeker een stuk minder relevant gemaakt, maar ik verwacht niet dat deze specifieke SSD het ecosysteem zal veranderen. De mensen die direct-naar-SSD kúnnen doen zullen allang overgestapt zijn, en voor de mensen de de hoogst mogelijke performance willlen is het alsnog niet snel genoeg.

[djwice]

Infrastructuur teams zijn al geswitcht of gaan dat doen naar moderne nvme opslag, niet perse inderdaad naar de ssd uit dit artikel.

Maar in de applicatie ontwerpen zie ik nog weinig architecten realiseren dan 1/40ste ms toegangstijd en miljoenen iops echt iets anders betekend ten opzichte van hdd. Dat je dus ook echt andere keuzes kunt maken in je ontwerp, omdat je nvme hebt.

In heel veel gevallen is die vertraging verwaarloosbaar op de eindgebruiker beleving en dus kun je minder complexe componenten gebruiken.
Dat zorgt voor kortere implementatie tijd en doorlooptijd van projecten en lagere beheerkosten. Als je dit goed ontwerpt. Je kunt ook ceph of andere s3 API ontsluiten om zo applicatief de voordelen van opslag én die van databases te combineren (notificaties bij wijzigingen, conditioneel schrijven (http if-headers), logs, versies, (custom)metadata etc.

[Reactie gewijzigd door djwice op 13 juli 2025 13:59]

[nhimf]

Er zijn nog genoeg systemen/applicaties waarbij de HDD nog volop in gebruik is. Daar een NVMe cache voorzetten is dan ook nog steeds hard nodig. En zolang de NVMe's per TB veel duurder zijn dan spinners zal dat ook zo blijven. Ik zie het de komende jaren nog niet veranderen. De trends waren heel positief, maar inmiddels vlakt het flink af qua gat tussen HDD en NVMe.

De SATA SSD gaat eerder verdwijnen dan de HDD, de SAS verwacht ik ook eerder te zien gaan dan de HDD.

[djwice]

Voor goot opslag zoals vele AI modellen dacht ik eerst ook: hdd, want het groeit de pan uit. Totdat ik frequent wilde lezen en zag dat het niet wachten was op de gpu of cpu maar op de hdd die de data leverd om de modellen in het geheugen te krijgen.

Ik heb de snelst beschikbare hdd, maar die leggen het extreem af tegen nvme.

[kabelmannetje]

Er is echt meer te verzinnen dan AI-modellen. Terabytes aan ruwe data, backups, enorme databases. Voor vele toepassingen zijn harddisks nog steeds de toekomst.

[djwice]

Is voor veel van die dingen de.tikd dat lezen kost niet relevant?
Zelfs backups, als je heel veel data .oet renoveren loop je op een gegeven moment uit je SLA met hdd.

[kabelmannetje]

Uhm, backups met "heel veel data" gaan naar tape, niet naar SSD. HDs zijn niet meer dan een cache hierin. SSD is daarnaast ongeschikt voor langdurige opslag van data.

Throughput van een enterprise NAS met HDs is vele malen hoger dan je in een 10GB netwerk kan halen.

[djwice]

Bij mijn overheids DC is het dan ook geen 10Gb netwerk meer

[kabelmannetje]

Ook bij dat overheids-DC, wordt er echt niet naar SSD gebackupped....

[djwice]

We lopen bij een bepaald project tegen een limiet aan zodat we het anders moeten oplossen dan tot nu toe standaard.

[kabelmannetje]

Als je niet naar tape kan backuppen, dan doe je iets verkeerd. Want een backupstrategie is verplicht in overheidsland.

[djwice]

Vraag dat aan de leverancier, die gaf aan dat het niet kon.

[kabelmannetje]

Andere leverancier dus.

[djwice]

Duurt nog een paar jaar tot contract einde.

[kabelmannetje]

Typisch overheid, contracten ondertekenen met partijen die claimen dat je geen backups naar tape kan maken.

Op een LTO-tape kan je immers minimaal 36TB kwijt. Met throughput van minimaal 400MB/s.

Dus, minimaal 14,4TB/uur backup. Ga in de praktijk gerust van dubbele netto getallen uit.

[djwice]

Wat is de restore tijd? Bij ons moet 140TB+ in 4 uur of minder kunnen worden terug gezet.
En het gaat om enkele miljarden bestanden.

[Reactie gewijzigd door djwice op 17 juli 2025 07:12]

[kabelmannetje]

Als je 140TB in een wekelijkse full backup wil bewaren, dan heb je het al snel over tape -cabinets.

Met een enkelvoudige DLT heb je het over raw 14,4 en netto al snel rond 35TB/uur. Dan zal je een cabinet met meervoudige tape readers moeten aanschaffen.

Verder kan je een continue hot backup mee laten draaien op bijvoorbeeld 20TB drives. En de diff van tape halen.

[Hansie9999]

Ik zou me ook meer zorgen maken over het feit dat als je daar nu echt contant op de SSD ook zou zitten schrijven aan 28GB/s hoe lang het duurt voor je nand chips defect zijn.

[djwice]

Zijn die chips niet veel meer durable dan hdd?

[kabelmannetje]

Nee, harddisks zijn superieur aan SSDs qua backup safety.

[Hansie9999]

Bij het schrijven zeker niet,

Kan natuurlijk wel zijn dat je ook aan 28Gbps wat meer gaat schrijven dan aan de +- 400Mbps van de HDD :)

[necessaryevil]

Volgensmij is je cache ook nodig voor de levensduur van de SSD. Het is beter om kleine schrijfacties (en leesacties?) op te sparen en in één keer te doen. Misschien kan iemand anders dat nog wat verder uitleggen.

[djwice]

Het gaat hier om read cache bijvoorbeeld een varnish of een ram-cache bij je database.

De nvme schrijven kunnen veel meer lees acties aan dan de oude hdd's.

Typisch is 42% van de hele schijf elke dag schrijven geen enkel probleem als je de schijven 2 jaar foutloos wil laten werken, zelfs bij consumenten nvme's.

[Reactie gewijzigd door djwice op 13 juli 2025 20:19]

[necessaryevil]

Even los van de discussie over de invloed van cache op de levensduur van SSD's... Ik moet nog maar zien of de SSD's in de werkelijkheid langer mee gaan als harddisks, met name de SSD's voor de consumentenmarkt. Er zit meer in dan alleen het geheugen, dat is bij een harddisk ook wel zo, maar er zijn veel meer merken, bij harddisks heb je een handje vol A-merken. De controller en het nand wordt ook nogal warm.

[BlaDeKke]

Let wel dat dit enkel sequentiële snelheden zijn, of random met hoge queue depth. In de praktijk gaat deze ssd steeds vele malen trager zijn dan ddr4 ram.

[djwice]

Als je het vergelijkt met MongoDB die blokken van maximaal 64kB leest van disk en dan in geheugen laad. Als je objecten op dit soort nvme staat en je op key het object ophaalt, hoe veel vertraging heb je dan door nvme te gebruiken in plaats van mongoDB bij de een non-cached object?

En als je dan kijkt naar s3 api op je nvme en bijvoorbeeld een head-request doet om je metadata op te halen van een object i.p.v. uit een NoSQL store. Hoeveel vertraging geeft dat? Terwijl je minder complexiteit hebt.

En als je normaal een pdf serveert van storage met metadata uit een nosql, hoeveel extra snelheid, beschikbaarheid en minder kosten krijg je door de metadata op het object te hebben staan?

En wat als je bijvoorbeeld een bericht met bijlagen als warc opslaat en daar metadata op zet? En dan als http-push de meerdere files stuurt.
Een lees actie op disk, geen tabel nodig, en simpele http-server of gateway die de requests kan doen eventueel met wat script, in plaats van applicatie services.

[BlaDeKke]

Geen idee. Lijkt me een leuk experiment, dat benchmarken voor zo’n situaties. Tweakers.net, leuk ideetje?

[Reactie gewijzigd door BlaDeKke op 13 juli 2025 20:53]

[djwice]

Gewoon code er voor genereren en test draaien

[BlaDeKke]

En de hardware hebben, die waarschijnlijk niet goedkoop gaat zijn.

[djwice]

Je kunt testen met Lexar NM790 als beste getest in de best Buy Guide. Die is 6.5GB/s sequentieel schrijven en PCI 4.0. Welliswaar geen 28GB/s, maar nog geen 5x trager, dus kun je wel overzien of de vertraging relevant is of niet.

Bovendien is het dan ook vergelijkbaar met wat nu in je DC zit.

[demianmonteverd]

Als je alles goed doet, ga je de limiet raken met aantal queue's, de diepte van deze queue's en de implementatie/kwaliteit van de scheduler van de SSD (en mss zelfs van je OS). En je kunt ook nog problemen vinden in de implementatie van de SSD met betrekking tot hoe deze metadata opslaat, duurzaamheid, etc.. Het is best lastig om echt alles uit een stukje hardware te halen soms. Deel de code a.u.b., leuk project.

[glennoo]

Je IT-architectuur versimpeld, je krijgt een hogere uptime en lagere kosten.

Dat ligt er volledig aan hoe je IT architectuur is opgebouwd. Als je alles in blades hebt zitten dan kan dat maar als je storage en je compute gescheiden van elkaar zijn ben je nog steeds gelimiteerd tot de tussenliggende bandbreedte. Maar hoe zou dit je uptime verhogen?

[djwice]

Typisch heeft elke infrastructuur niet 100% beschikbaarheid en is de beschikbaarheid van de meeste componenten onafhankelijk van de beschikbaarheid van je storage laag.
Als je een of meerdere lagen uit je applicatie infrastructuur wegneemt, is de beschikbaarheid van je totale systeem daarom hoger.

Beschikbaarheid is typisch het ongecontroleerde product van de componenten (vermenigvuldiging van dingen die achter elkaar staan elk kleiner dan 100%).

[Reactie gewijzigd door djwice op 13 juli 2025 13:47]

[Oudecomputer]

Maar hoe betrouwbaar is deze techniek, en wat is de kans op storingen en hoeveel andere haken en ogen zitten (kosten ) zitten hier aan. Van pci 3 -.>4 zat aardig wat extra kosten en chips om het stabiel te maken bij 5 kwam daar nog een probleem bij warmte . Ik ben benieuwd wat voor extra problemen 6 gaat brengen en hoe de Stabiliteit is.

[Xthemes.us]

Skippen aardig wat nodes daar, van 12nm meteen naar 4nm.
Dat is vergelijkbaar met een AMD Ryzen 5 2600q (12nm) Vs AMD Ryzen 5 9600 (4nm) .

[xtlauke]

Idd een flinke stap. Ws ook wel wenselijk vanwege het sterk. toenemende energieverbruik van SSD's de laatste jaren.

[Speedster]

" Ws ook wel wenselijk vanwege het sterk. toenemende energieverbruik van SSD's de laatste jaren."

Absoluut gezien wellicht wel echter in de praktijk verwaarloosbaar, of zie ik dat verkeerd?

[xtlauke]

Fair point. Dat weet ik niet zeker. Je hebt een punt dat de bijv. in een PC van een liefhebber met een 400 watt videokaart dit niet veel uitmaakt. Maar het gaat iig de verkeerde kant op. Thermal throttling begint wel degelijk een uitdaging te worden en er is steeds forsere cooling nodig, wat bijv. ook in dunne laptops een flink probleem wordt. En als deze voornamelijk voor zakelijk gebruik zijn, zoals het artikel aangeeft, waar ze 24x7 moeten draaien onder temperaturen (waarbij ze overigens weinig moeten slijten door de voltages en hitte en ws veel sneller hun einde zullen halen), dan telt het energieverbruik ws toch.

[Reactie gewijzigd door xtlauke op 14 juli 2025 09:25]

[uiltje]

Het begint zo echt interessant te worden om een programmeertaal te ontwikkelen die specifieke typen geheugen direct kan aanspreken. Ik heb hier nog niet heel veel innovatie op gezien. Ik had dat eigenlijk al verwacht voor 3D Xpoint phase change memory geheugen (oftewel, Intels' mislukte Optane) maar daarvoor gebeurde dat ook niet echt. Zoals we nu met data werken wordt het eigenlijk altijd eerst in geheugen geplaatst en dan naar persistent geheugen geschreven. Je zou met zulke snelheden die stap over kunnen slaan en bijvoorbeeld persistente objecten maken. We kunnen immers ook al RAM aansturen over PCIe, dus op HW niveau is het al mogelijk.

Manieren om geheugen aan te sturen zijn heel belangrijk in hoe een computer werkt.

[Reactie gewijzigd door uiltje op 15 juli 2025 03:18]

[kdekker]

Maar verreweg de meeste toegang is juist random access, niet sequentieel. Dus de marketing snelheid van de SSD is onder zeer beperkte omstandigheden te verkrijgen. DDR geheugen heeft nog steeds een lagere latency.

Overigens zie je bij multi-socket systemen ook al toegnagsverschillen als socket 1 bij DDR bank van socket 2 moete komen. Zelfs bij single-socket CPU's speelt dat al, net hoe de core vanuit de binnenkant (CCD) op de buitenkant (DDR) komt. En ook nog caches spelen een rol. Dus zo'n 'onze SSD doet 20GB+/s zegt eigenlijk niet veel, als ook niet latency en random read/write snelheden onbekend zijn. Wat @laurxp ook zegt in zijn reactie.

Ter illustratie: bij heel veel SSD's wordt met testen een score getoond voor de 4KB random reads.writes. Tussen SATA, PCIe 3, 4, 5 (van 6 heb ik nog geen getallen gezien) zie je wel toenames, maar die 4KB acties is de throughput veelal beperkt tot max een paar 100 MB/s.

Als programmeur kun je je doorgaans niet concentreren op de 'beste' configuratie in het veld, maar moet je je doorgaans conformeren aan de zwakste versie. Backwards compatibiliteit en het feit dat een klant doorgaans niet staat te springen om te investeren in nieuwe hardware, betekent meestal dat het lang duurt voordat je breed in kunt zetten op nieuwe technieken. Meestal pas nadat de support op de oude spullen vervallen is (onder voorwaarde dat je als softwarebedrijf een support life cycle op orde hebt).

[Reactie gewijzigd door kdekker op 14 juli 2025 11:41]

[Dick Ravestein]

En het toverwoord hier is "tot".

Zal in praktijk nooit gehaald worden!

[Splorky]

Ram disk?
En het zal best nog een flink aantal jaren duren voor het gemeengoed is, maar wel goed dat er alvast aan gewerkt wordt.

[Reactie gewijzigd door Splorky op 13 juli 2025 12:31]

[Damic]

In de server wereld bestaat dat als CXL hang je trager geheugen aan de pci-e bus, maar kan evengoed een hoop ssd's zijn

[Splorky]

Ahh, iets met kleppen enzo. Bedankt voor de link

[_Thanatos_]

Als ik je vraag een emmer *tot* de rand met water te vullen, kom je dan terug met een halfvolle emmer?

[Dick Ravestein]

Dat bedoel ik dus maar een 10ltr emmer kan echt gevuld worden met 10ltr en een beetje. Niet "tot" en in praktijk erachter komen dat er eigenlijk "op een normale manier" 8ltr Max in te krijgen is.

[De_Daapse]

Hoe ver zijn ze er mee?

[smitdylan]

En ik dacht dat mn memblaze sad snel was met 14GB/s steady state :/

[oks]

Lijkt me wat lang duren. Gegeven dat de Ai modellen steeds talrijker worden lijkt me het toe dat er een Grote Markt voor consumenten gaat ontstaan om dit snelle opslaggeheugen te hebben. Maar ja dan moet de gewone pc architectuur ook op de schop a la wat Apple nu doet met hun snelle shared memory architectuur. De videokaarten van nu voor de pc zijn eigenlijk achterhaald voor AI toepassingen: er is te weinig videogeheugen om grotere ai modellen privé te kunnen draaien…

[Vizzie]

Denk je echt dat er een markt gaat ontstaan voor consumenten om lokaal AI modellen te draaien waarvoor dit soort storage nodig is? Lijkt mij niet heel waarschijnlijk

[oks]

Hoezo niet? Ik doe het al en als je enigszins om je privacy geeft is dat een zeer gewenste uitkomst. Maar ja privacy kost je op dit moment inderdaad geld...

[Vizzie]

Nou met name niet omdat het gros van de mensen:

1. Veel meer geeft om gemak dan privacy en daarom geen lokale modellen gaat draaien op dure hardware; en
2. Dit totaal niet voor elkaar gaat krijgen. Waarschijnlijk niet eens begrijpt waar we het over hebben en het ook niet wil weten.

[oks]

Tjonge jonge valt wel mee. Kijk maar eens naar applicaties als Jan, LM studio kan je aardig mee wegkomen. En voor de rest: er zijn nogal wat bedrijven/overheden die een dergelijke toepassing gebruiken om er voor te zorgen dat de interne informatie wel ontsloten wordt maar niet naar de grote jongens. En zoals je Word leert gebruiken... kun je ook dit leren...

[Prince]

DDR4-3200 heeft een peak transfer rate van 25.6GB/s.
Maar we hebben RAM niet puur voor GB/s, maar vooral voor de latency.
Deze SSD controller haalt 7M IOPS.
Een DDR4-3200 (om de vergelijking hier gelijk te houden) heeft ~400M IOPS.
Latency voor SSD is in microsecondes; voor DDR4 in nanosecondes.

DDR5-6000 (wat veel hogere frequenties heeft) doet er ~750M IOPS.