Phison demonstreert PCIe 5.0-ssd-controller met snelheid tot 12,5GB/s

Controllerfabrikant Phison heeft een PCIe 5.0-controller gedemonstreerd in combinatie met een X670-moederbord van ASUS. Met een prototype-ssd worden lees- en schrijfsnelheden van zo'n 12,5 en 10GB/s gehaald. PCIe 5.0-ssd's voor consumenten verschijnen in de herfst.

Het prototype dat Phison demonstreert is gebaseerd op de PS5026-E26-controller, die de fabrikant maakt voor PCIe 5.0 x4-ssd's. Deze biedt een maximale doorvoersnelheid van 15,8GB/s, dubbel zoveel als wat ssd's met een PCIe 4.0 x4-controller maximaal halen.

Voor de praktijktest gebruikt Phison 'de nieuwste' 3d-tlc-geheugenchips van Micron en een ASUS-moederbord met de AMD X670-chipset. Dat moederbord is ook een prototype, want X670-moederborden komen pas in het najaar uit.

In CrystalDiskMark haalt de opstelling sequentiële lees- en schrijfsnelheden van ongeveer 12,5 en 10GB/s. Eind dit jaar worden de eerste consumenten-ssd's verwacht die daadwerkelijk dergelijke snelheden halen. Het AMD X670-platform krijgt 24 PCIe 5.0-lanes. Dat maakt het mogelijk om twee PCIe 5.0 x4-ssd's te gebruiken in combinatie met een videokaart die zestien lanes gebruikt.

Ook Intels komende Raptor Lake-platform zal zowel ssd's als videokaarten met de PCIe 5.0-interface ondersteunen. Hoeveel lanes het Intel-platform krijgt, is nog niet bekend. Het huidige Alder Lake-platform ondersteunt ook PCIe 5.0, maar is beperkt tot 16 lanes.

Apacer en Zotac liet vorige week weten met dergelijke ssd's te komen en begin dit jaar toonde Team Group al een PCIe 5.0-ssd. Adata liet prototypen zien van PCIe 5.0-ssd's die snelheden tot 14GB/s zouden halen. Bij de aankondigingen tot nu toe zijn nog geen details bekendgemaakt over de gebruikte controller en het geheugen.

Door Julian Huijbregts

Nieuwsredacteur

30-05-2022 • 08:51

32

Reacties (32)

Sorteer op:

Weergave:

Sorry hoor, maar met de hoeveelheid latency/responstijd die bij de moderne SSD's juist toeneemt, en de impact die de cache (SLC + DRAM) heeft, is het misschien niet een goed moment om, ook in het kader van games, even pauze te nemen met de througput, en zaken op Optane/3D-XPoint -niveau te brengen, zodat er ook wat nut bij zit zodra directstorage en aanverwanten breed gebruikt worden? Gezien de beperkte hoeveelheid lanes vanaf consumenten CPU's zie ik persoonlijk sowieso liever dat de stap naar PCIe 5.0 gebruikt wordt om 2-lane nVME drives te gaan gebruiken, zodat we de bandbreedte (die gelijk staat aan de consoles) van 4x4 kunnen gebruiken op 2x5, waardoor er weer meer SSD's direct aan de CPU kunnen (24 lanes vanaf zowel AM5 als Intel1700, waarvan 16 GPU, 4 storage, 4 PCH, en aan de PCH wil je liever niet directstorage zaken hangen omdat je dan niet direct GPU > SSD kan hoppen in een ster-topologie). De random reads zijn de laatste jaren eigenlijk heel erg gelijk gebleven, en synthetische IOPS benchmarks geven niet een volledig beeld.
Als ik de originele benchmark bekijk haalt de disk een read 4K QD1 van ocharme 62,82MB/s

https://www.techpowerup.c...-e26-controller#g295369-2

Ter vergelijking, een Samsung 980 Pro haalt er 81,26 en een Intel P5800X haalt er zonder cache (dus sustained) + 400MB/s op read 4K QD1. De P5800X is zowat het snelste wat je momenteel kan krijgen maar extreem prijzig en gericht op server markt.

Die sequentiele snelheid is al lang irrelevant geworden, sustained snelheden halen zonder cache trucjes en throttling + reactietijden, dat zijn de 2 punten waar inderdaad de winst te halen is maar dat zijn ook de 2 punten waar consumenten drives 0 vooruitgang in boeken.

Echter het reactietijd probleem zit hem niet in de PCIe lanes, bij consumenten drives zit de bottleneck in de drives zelf, bij de P5800X zit het hem in de manier waarop je de drive aanstuurt als in de P5800X heeft de neiging om CPU bottlenecked te zijn. Dan negeer ik nog als je iets van mirror raid of dat soort drives over het netwerk wilt aansturen, daar is ook dringend het een & ander nodig om latency omlaag te krijgen zoals NVMe-oF.
Exact wat ik bedoel. Lanes is enkel en alleen nuttig om de beschikbare bandbreedte te verhogen. Door het NAND (rauwe flash snelheid) en de controller (stukken NAND als SLC gebruiken, DRAM) is er een factor snelheid te bepalen. NAND is sequentieel erg snel (tot de cache vol is bij MLC nand...), maar heel afhankelijk van volle pages schrijven/lezen, en transacties hebben bovendien een redelijke hoeveelheid kosten. Bij MLC is dat een stuk hoger dan SLC, en stacked NAND weer hoger dan... platter NAND. Hoewel een SSD nog steeds in responstijden van milliseconden praat, is dat puur op wat je met een game/random workflow wilt hebben nog steeds absurd hoog, en dit is waardoor random reads laag blijven, en zelfs met alle bandbreedte van PCIe 5.x je nog steeds "maar" 60mb haalt. Vandaar dat ik ook opper:

Laten we wat lanes vrij maken, want de hoeveelheid scenarios waarbij we werkelijk 4 nodig hebben, zeker op consumer grade, is aan het afnemen. Kijk naar dit artikel, bijvoorbeeld: https://nl.hardware.info/...-amds-smartaccess-storage (HW.info: niet elke NVME SSD geschikt voor Smart Access Storage, AMD's DirectStorage implementatie).

Het komt er op neer dat daar waarschijnlijk een cache/dram/controller vraagstuk achter zit: kan de SSD een "game" workload (laten we eerlijk zijn, ondanks dat games meestal enorm veel grote archives gebruiken, de meeste load is random, textures, stukjes shader code, etc...) streaming aan zonder enorme pre-caching in snellere tiers zoals DRAM of VRAM. Om de SSD die rol te laten vervangen (wat directstorage/smart access storage etc, laadtijden = assets van trage storage naar snelle storage, directstorage "geen laadtijden" = aanname dat permanente storage snelle storage ís) moet je naast puur de mogelijkheid om een 20GB file in één keer te kunnen lezen, ook de mogelijkheid hebben om 20.000 1MB files ad-hoc te kunnen lezen zonder dat de seektimes/stall zo hoog wordt dat je ineens maar 40MB/sec haalt (wat nog 40 files/seconde is, maar XPoint/RAM doet het sneller).

En daar gaat geen hoeveelheid lanes mee helpen. Dus daarom roep ik: "doe me maar een SSD die wat lanes bespaart zodat ik meer SSD's kan aansluiten" totdat we werkelijk snelle SSD's hebben.
RTX IO & AMD's Smart Access Storage gaat vooral over het decomprimeren van de gigantische datastroom via de GPU. Alles om de CPU te ontlasten en op die manier de laadtijden te verbeteren. De bandbreedte is hierbij secundair maar dankzij deze techniek is de bandbreedte verhoging wel welkom omdat hij door het gebruik van de GPU nu ook hanteerbaar is. Het werd de CPU allemaal te veel :)
Is het niet eerder de 4K benchmark die zijn relevantie begint te verliezen? Als ik kijk naar Outriders dan is die game 44GB op 166 files. Sterker nog 99.8% van alle data zit in één van de 59 'pakchunck' bestanden.

Wanneer je de GPU een decompress kunt laten doen dan is er AFAIk alleen maar meer reden om je game op deze manier te verschepen.
Een bandbreedte van 12,5GB/s komt overeen met DDR3-1600, dat wilt zeggen dat die drives sequentieel op weg zijn om de bandbreedte van je RAM in te halen.

Toch is RAM véél sneller omdat de latency gigantisch laag is. Met 4K QD1 read test je latency, dat is namelijk het enigste wat ons nog tegenhoud om een ondersheid te maken tussen vluchtig geheugen (RAM) en persitent geheugen (NVMe, SSD, HDD)

Beter nog, het bestaat al in de vorm van persistent memory of PMEM wat je in een RAM slot steekt, dat komt neer op een NVMe drive in je RAM slot, te gebruiken als RAM en/of storage (die keuze moet je maken omdat het OS nog niet overweg kan met het concept Memory = Storage). Als consument vandaag nog onbetaalbaar, het haalt ook nog niet dezelfde reactietijden als gewoon RAM maar het is wel de toekomst.

Dus om op je vraag terug te komen, de 4K / latency benchmark is niet zijn relevantie aan het verliezen, het is de belangerijkste van allemaal aan het worden.
Maar dan ga je er vanuit dat het doel van PCI gen 5 SSD's is om RAM te vervangen. Dit is echter totaal niet aan de orde. Als er al een ontwikkeling is vast te stellen dan is het dat we steeds meer CPU cache, steeds meer RAM en steeds meer VRAM gebruiken. Ondertussen is de techniek die daar wel naar toe werkte, Intel Optane, de prullenbak in gegaan. We bewegen dus juist weg van dat concept. In die context kun je RTX IO/ Direct Storage ook prima plaatsen; met hele hoge snelheden grote packs naar de GPU smijten.
Direct storage, RTX IO, NVMe-oF, VROC, VMD, RoCe, RDMA, PMEM en vermoedelijk nog een berg andere die ik net mis, waarom hebben we die nodig?

Met hele grote snelheden grote packs naar de GPU smijten noem jij het, wat ik hoor is dat hoe we storage benaderen, zowel lokaal als over netwerk, een bottleneck aan het worden is omdat het allemaal veel te latency gevoelig is. Direct storage bypast de CPU niet om meer bandbreedte te krijgen, het bypast de CPU om minder latency te hebben, om de tijd nodig om een block data van die NVMe te krijgen & het te decompressen kleiner te krijgen. Dat je dan wat minder CPU cycles nodig hebt is niet meer dan een mooie extra.

Wat doet RDMA? CPU bypassen op een netwerkkaart want dan geeft minder latency. Wat doet NVMe-OF? Storage anders aanspreken over netwerk om minder latency te krijgen. Wat doet VMD en VROC? De CPU raid controller laten spelen want NVMe in een klassieke RAID levert teveel latency op.

PCIe gen 5 heeft inderdaad weinig met dit verhaal te maken, het heeft ook weinig met games te maken gezien het niet de consument is die nood heeft aan PCIe 5. Moet je vandaag eens een server bouwen met all flash storage, 12 disks aan 8 lanes per stuk, 100/200 Gb/sec NICs aan 16 lanes per stuk.

Vandaag word je bijna verplicht om met een dual socket server te gaan werken omdat je gewoon niet genoeg PCIe 4 lanes hebt op 1 server CPU. En weet je wat er gebeurd als je in een dual socket CPU zit? Dan krijg je weer latency want disk A zit op CPU A en disk B zit op CPU B maar ze draaien in een mirror.

Maar dan kom ik bij de consumenten drives en wat zie ik? Veel show rond sequentiele snelheden waar je niets aan hebt omdat die al snel genoeg zijn terwijl de drives zelfs eigenlijk nog de grote bottleneck zijn als het op latency aankomt. Maar ondertussen wel weer met veel show technieken als RTX IO aankondigen (wat niet meer is dan Direct Storage hernoemt voor Nvidia Marketing) die moeten toelaten om van die veel lagere latency daadwerklijk gebruik te maken. Iets wat ik totaal niet zie op de server markt, daar heb ik gewone enterprise Samsung drives die sequentieel met moeite 3GB/sec halen maar op 4K QD1 wel degelijk 200MB/sec halen terwijl de eerste consumenten drive die over de 100 gaat nog uitgevonden moet worden.
Direct storage, RTX IO, NVMe-oF, VROC, VMD, RoCe, RDMA, PMEM en vermoedelijk nog een berg andere die ik net mis, waarom hebben we die nodig?

Met hele grote snelheden grote packs naar de GPU smijten noem jij het, wat ik hoor is dat hoe we storage benaderen, zowel lokaal als over netwerk, een bottleneck aan het worden is omdat het allemaal veel te latency gevoelig is. Direct storage bypast de CPU niet om meer bandbreedte te krijgen, het bypast de CPU om minder latency te hebben, om de tijd nodig om een block data van die NVMe te krijgen & het te decompressen kleiner te krijgen. Dat je dan wat minder CPU cycles nodig hebt is niet meer dan een mooie extra.
Deze uitleg staat eigenlijk haaks op het hele idee achter RTX IO.
Together, the streamlined and parallelized APIs, specifically tailored for games, allow dramatically reduced IO overhead and maximize performance/bandwidth from NVMe SSD to your RTX IO-enabled GPU.

Specifically, NVIDIA RTX IO brings GPU-based lossless decompression, allowing reads through DirectStorage to remain compressed while being delivered to the GPU for decompression. This removes the load from the CPU, moving the data from storage to the GPU in its more efficient, compressed form, and improving I/O performance by a factor of 2.

GeForce RTX GPUs are capable of decompression performance beyond the limits of even Gen4 SSDs, offloading dozens of CPU cores’ worth of work to deliver maximum overall system performance for next generation games.
Het hele concept is erop gebaseerd dat de theoretische bandbreedte van gen4 zo verschrikkelijk veel cpu overhead nodig heeft, 24 cores aldus Nvidia. Met RTX IO wordt dezelfde bandbreedte met 0.5 core behaald, aldus het materiaal van Nvidia.

Het probleem dat je aankaart; het beperkte nut van steeds hogere sequentiële snelheden is dus precies hetgeen dat RTX IO gaat oplossen. Nu zien we geen verschil in bijvoorbeeld laadtijden bij hogere sequentiële leessnelheden, straks wel. Dit maakt de weg vrij voor grotere textures en grotere games. Directstorage zelf is pas maart 2022 beschikbaar gesteld dus je moet nog even geduld hebben, maar straks wordt die sequentiële snelheid ineens een stuk belangrijker.

[Reactie gewijzigd door sdk1985 op 24 juli 2024 13:50]

24 cores in gebruik voor storage omdat je NVMe drive data aan het lezen is, heel je CPU belast, uiteraard, dat zien we elke keer we een file copy doen. En nee mijn uitleg staat niet haaks op die van Nvidia, die komen overeen.

Huidig verhaal

Disk stuurt compressed data naar CPU, CPU decompressed die, CPU stuurt decompressed data door naar GPU.

Direct storage verhaal, Disk stuurt compressed data naar GPU, GPU decompressed die

Je neemt een shortcut en het voordeel van die shortcut is minder latency. De tijd nodig om van data op je disk naar bruikbare data op je GPU te gaan word kleiner. Als je latency verlaagt dat gaat je performance of je I/O performance omhoog terwijl je bandwith hetzelfde blijft. Hoe sneller texture A ingelezen is hoe sneller texture B ingelezen kan worden.

Dat die IO overhead naar beneden moet klopt maar dat komt niet omdat PCIe 4 zo verschikkelijk veel CPU overhead nodig heeft, wat maakt dat beetje CPU belasting zelfs uit, het probleem is dat die CPU cycles tijd vragen en tijd is latency.
Dat is dus specifiek voor de Queue Depth 1, en erger nog: ook maar 1 queue. Dan is het probleem dus dat je weinig werk aanbiedt aan de controller. Je meet de performance effectief dus als 4K/latency. Ja, logisch dat zo'n latency meting weinig verband heeft met de PCIe bandbreedte. Je ziet in de Q32T16 test dat je bij genoeg queueing de bandbreedte veel beter benut, en je tegen de grenzen van het NAND aan gaat lopen.
Je reactie is bijna onleesbaar, en bevat een foutje. AM5 heeft 28-lanes voor en dus 24-lanes voor GPU en Storage.
(ik lees overigens sites waar men het heeft over 24-lanes voor Storage en GPU en sites waar men het over 28 lanes totaal heeft, de laatste slides van AMD zijn niet echt duidelijk op dit punt, dus het kan best 24 totaal zijn....)

Gevonden: There's a bit of confusion about the CPU's PCIe 5.0 configuration. We've seen 24 and 28 lanes mentioned. Could you clarify?
There are 28 total lanes from the CPU, all Gen 5, of which 4 are peeled off for downlink to the chipset and the remaining 24 are available to the user. On X670 Extreme that means graphics operates at x16 Gen 5 or x8/x8 Gen 5, and there's one M.2 NVMe x4 Gen 5. On the X670 (non-Extreme) only the M.2 NVMe slot is required to be Gen 5, the top slot for graphics will optionally be Gen 5. On B650, only M.2 storage will be Gen 5. Of course, other components, like companion controllers or additional NVMe devices, can connect to Gen 5 on the CPU.

With 28 Gen 5 lanes from the CPU, 16 PEG lanes, and 4 chipset lanes, 8 lanes are left. Is it possible for motherboards to have two M.2 slots wired to the processor?
Yes, that is a possibility.

[Reactie gewijzigd door kdeboois op 24 juli 2024 13:50]

4 lanes worden gebruikt voor de chipset uplink (de verbinding tussen de chipset en de CPU). De andere 24 lanes zijn directe verbindingen tussen de CPU en de videokaart, NVMe, etc.

Het komt erop neer dat een deel van de functionaliteit van een moederbord wordt geleverd door de CPU en een deel door de chipset, en dat laatste moet allemaal over de verbinding tussen de chipset en de CPU. Zo is het meestal zo dat de eerste PCIe slot direct op de CPU is aangesloten, maar de overige via de chipset gaan. Bij meerdere NVMe's is het ook zo dat de eerste direct naar de CPU gaat (en daarom sneller is), terwijl de rest via de chipset gaan. Het kan ook zo zijn dat een deel van de USB aansluitingen direct naar de CPU gaan, maar de rest via de chipset gaan. De SATA aansluitingen gaan allemaal via de chipset, net als Ethernet en Wifi.

Over het algemeen is de hoeveelheid IO die de chipset aanbiedt een stuk groter dan de bandbreedte van de chipset uplink, dus kun je die IO niet maximaal gebruiken, al is dat in de praktijk meestal niet zo'n probleem, omdat niet alles tegelijkertijd maximaal data zal versturen/ontvangen (en zelden alle IO opties volledig benut worden).

Dit is een goede uitleg van de hoe het werkt voor AM4 en AM5:

https://www.angstronomics...h-exclusive-all-the-juicy

[Reactie gewijzigd door Ludewig op 24 juli 2024 13:50]

Mijn punt is dat AM5 wel 2x4 lanes beschikbaar heeft voor SSD's. De chipset uplink hoeft hiervoor niet gebruikt te worden. Dus 16+4+4+4 i.p.v. 16+4+4 voor AM4 en Intel1700.
Maar met latency kunnen ze niet adverteren :p Grote getalletjes zijn nu eenmaal interessanter. Wel begreep ik dat er meer directe lanes naar de CPU komen in de nieuwe generatie. Misschien dat dat iets helpt voor de latency?
Gewoon 24 lanes helaas, dat eigenlijk de bottleneck zal gaan vormen voor menig gaming PC.
Er zijn nu nul (0, zero, nada, noppes) moederborden of CPU's met 96 lanes x 3.0, dus blijkbaar is er geen acute behoefte aan een dergelijke bandbreedte in gaming PC's. En ik denk dat we PCIe 6.0 zien voordat 24 lanes PCIe 5.0 een probleem wordt. Lanes zijn maar een implementatie-detail, het gaat om het totaal aantal gigabits/s. Engineering-wise is op dit punt de keuze om naar snellere lanes te gaan, niet naar meer lanes.
Soort van, niet echt. Als we bij de NVME blijven, die gaan niet van 4 naar 2 lanes om snelheid te houden en lanes te sparen, maar meer snelheid. Als al die lanes voor pcie5.0 ssd's direct uit de cpu komen ga ik niet klagen.
Aan de ene kant heb je helemaal gelijk: In real-life zal het verschil tussen PCIe 5 en 4 in 80% van de gevallen niet merkbaar zijn. En je kunt hetzelfde zeggen van SATA SSDs t.o.v. NVME SSDs. De sequentiele leessnelheid is in de meeste gevallen niet waar de meeste applicaties hun voordeel mee doen.

Anderzijds gaat het toch langzaam naar hogere snelheden.
Dus deze (kleine) verbeteringen zijn toch wel weer 'iets' waard.
De SSD die PCIe 5.0 gebruikt op x4 die is misschien nog niet direct nu nodig.
Maar de fabrikanten kunnen de top off the line toch weer verkopen aan de enthousiastelingen...
En de spin-off zal vast wel weer een betere PCIe 5.0 op x2 zijn.
Zoals je terecht zegt --> Laat ze die PCIe 5.0 bandbreedte maar 'gebruiken' om bijv. meer kanalen te gebruiken.
Kortom --> Dit soort ontwikkelingen moet je volgens mij meer zien als 'continuous improvement'.
PCIe 5 met SSDs gaat voorlopig alleen op AMD socket AM5.
Intel heeft voor Alder Lake gekozen om PCIe 5 alleen voor grafische kaarten (het 1e PCIe x16 slot) uit te voeren.
Nu is PCIe 5 voor storage voorlopig een zware overkill, maar voor grafische kaarten is het al helemaal geen toegevoegde waarde.
Ik ben ook voorstander voor minder lanes per M2 slot en dan meer M2 slots.
Ligt er helemaal aan waarvoor je het gebruikt. Als je veel met data bezig bent is die verdubbeling echt wel merkbaar. Deze ssds halen volgens mij de snelheid van ddr3 geheugen. Ik als php programmeur ben best wel blij met deze upgraden want ik denk dat het inlezen van file requires ook versneld. En bij sommige requests moet ik dat toch echt 50x doen voordat die request geladen is.
Hoe kan het dat jouw I/O niet in de file cache zit?

Ik zou niet beginnen met kijken naar HW en OS performance als je PHP site traag is, daar is toch echt een andere hoofdverdachte.
Ik gebruik zelf opcache, maar merk dat bij de eerste keer na een cache reset het toch enige tijd duurt, voordat de pagina laadt. Tsja templating kan nog worden geoptimaliseerd. Nu gebruikt ie voor elke dubbele quoted string een file. Eenmaal in de opcache is het goed.
Dat is de PHP cache. Ik bedoelde eigenlijk de OS-level file cache. Het OS zou geen enkele reden moeten hebben om voor die paar bytes de SSD aan te spreken. Al je PHP code past in RAM.
Hoe zet je die daar neer dan, of doet het OS dat?
Dat is standaard en automatisch op elk modern OS. Kwestie van genoeg RAM kopen.
Ik denk dat ik al weet waarom het 10 seconden duurt voordat ie geladen is. Dank je wel. Maar ik compileer template code naar gegenereerde php classes, die eerst gemaakt moeten worden. Dit zijn complexe lists waarbij elke regel zo'n 10 templates aan tikt. Ik denk dat ik mijn update script moet uitbreiden met een optimize script, die na de cache:clear gaat draaien met dummy data. Zodat er gecompiled kan worden tijdens de update. Nadat de php classes gegenereerd zijn duurt het nog geen 100 msec.
Of een videokaart op PCIe 5 met 8 lanes.
Zelfs een RTX 3090 Ti trekt een PCIe 4 met 16 lanes nog lang niet dicht, dus aan 8 lanes PCIe5 hebben ze voorlopig nog zat.
Daardoor kan je alweer 2 NVMe x4 slots extra kwijt.
Nu is PCIe 5 voor storage voorlopig een zware overkill, maar voor grafische kaarten is het al helemaal geen toegevoegde waarde.
Juist voor de NVMe's denk ik dat het erg veel meerwaarde zal krijgen met Direct Storage. De fabrikanten zijn hier heel hard mee bezig, juist ook voor het versnellen van de videokaarten, door data direct van de NVMe naar de videokaart te pompen, zonder via de RAM te hoeven gaan.

AMD levert ook op de goedkoopste AM5 moederborden straks een PCIe 5 aansluiting voor de opslag, maar niet voor de videokaart, wat aangeeft dat zij dit erg belangrijk vinden.

[Reactie gewijzigd door Ludewig op 24 juli 2024 13:50]

Gelukkig is dat geen grafisch kaart slot maar een algemeen uitbreidingsslot. Dus iets anders erin werkt ook gewoon! Bv een PCEe naar M2 (or naar 4x M2) kaart. En die zullen er vast komen.

(Sorry, pet peeve van mij. En een die helaal iritant werd nadat sommige moederborden hun onboard (wel, op CPU/APU) output uiitzetten omdat er een RAID kaart of een andere kaart in het eerst x16 slot zat.
-

[Reactie gewijzigd door Memori op 24 juli 2024 13:50]

SSD's worden almaar sneller, maar niet veel goedkoper helaas. ~15ct/GB versus ~1.7ct bij HDDs, het gat blijft enorm.

Op dit item kan niet meer gereageerd worden.