Crucial MX500 im Test: Evolution eines Klassikers

[HWL News Bot]

In den letzten knapp vier Jahren hat sich eine bestimmte SSD zu einem immerwährenden Tipp im Forum gemausert, auch wenn wir sie nie im Test hatten: Die Crucial MX500. Doch wer nun denkt, dass wir bei Hardwareluxx heute einen Oldie testen, liegt falsch: Unser Testexemplar kommt mit einer stattlichen Gesamtkapazität von 4 TB, aktualisiertem Controller und verändertem NAND. Im Gegenzug verringert Crucial den verfügbaren DRAM. Ob also die Weiterentwicklung des Klassikers glückt, oder ob die MX500 ihren Status als beliebte Empfehlung verliert, klären wir mit unserem Test.
... weiterlesen

 

[RcTomcat]

"Nur 512 GB DRAM", "Im Belastungstest sehr wir abschließend"
Ein paar Fehler im Text.
512GB DRAM wären sicherlich top

Danke für den Test

 

[Botcruscher]

Als Datenplatte zu ertragen. Trotzdem irgendwo am falschen Ende gespart. 2x2TB sind günstiger, deutlich schneller und haben insgesamt 4GB RAM. Sata Slots sind eh genug da.

QLC ist und bleibt Müll. Für den Preis im Gesamtpaket nicht mal für Sparanwendungen interessant. Dagegen mit der MX zu Gewinnen wirft Fragen zur BX auf.

 

[mattiii]

Datenplatte und Games drauf.

 

[Ein Lamm borg I nie]

Eine Gegenüberstellung zur SanDisk Ultra 3D / WD Blue 3D in 4 TB wäre hier der eigentlich interessante Vergleich gewesen.

870 QVO hat QLC, 870 Evo deutlich teurer ... ja, das wusste man irgendwie schon vorher.

 

[geist4711]

interessant für mich wären daten zu zugriffszeiten gewesen, DIE machen eher mal den unterschied, als die kopierleistungen, weil,
was nutzten mir gigabitweise datenübertragungen, wenn das raussuchen, also zugriffszeiten immer schlechter werden?
gerade bei vielen kleineren dateien wie bilder- oder musik-sammlungen zb, machen die zugriffszeiten meine ich, dann ehr mehr aus als die schnelle datenübertragung selbst dabei, auch weil eh kaum ausgenutzt wird, zb wenn man sich dateigrössen unterhalb 30MB je datei bewegen.

 

[Holt]

Die Zugriffszeiten werden wegen des geringen DRAM Caches unterschiedlich ausfallen, je nachdem ob der nötige Teil der Mappingtabelle gerade schon im DRAM Cache steht oder erst nachgeladen werden muss.

 

[Elmario]

Wäre es bei gegebener Prämisse nicht sinnvoll gewesen, auch ein älteres Modell der MX500 zu vergleichen?

 

[Luckz]

Hier wird völlig ignoriert, dass die höhere Latenz nicht unbedingt am RAM liegt, sondern der Controller eventuell schlicht und einfach zu viele TB Speicher (bzw CEs) dran hat. Bei https://www.realhardwarereviews.com/crucial-mx500-4tb-review/4/ wird darauf ausführlich eingegangen.

 

[Holt]

Hier wird völlig ignoriert, dass die höhere Latenz nicht unbedingt am RAM liegt, sondern der Controller eventuell schlicht und einfach zu viele TB Speicher (bzw CEs) dran hat.

Das kommt noch oben drauf, aber der DRAM Cache einer SSD ist vor allem für die Verwaltungsdaten und da vor allem für die Mappingtabelle und deshalb i.d.R. auch proportional zu Kapazität, idealerweise 1GB RAM pro 1TB Kapazität. Die MX500 4TB hat nur ein Achtel davon und kann daher nicht die ganze Mappingtabelle in DRAM halten (sondern eben nur genug für einen Adressraum von rund einem Achtel) oder muss sie anderes organisieren, etwas mit einer gröberen Auflösung von nur 32k statt 4k, in beiden Fällen fällt die Performance bei den 4k IOPS ab, weil sie entweder oft Teile der Mappingtabelle aus dem NAND nachladen muss oder eben intern mit 32k arbeitet und bei 4k Lesend dann 32k aus dem NAND gelesen und davon nur 4k weitergereicht werden, wobei ich ersteres vermute, da SMI ja 1GB RAM pro 1TB Kapazität empfiehlt:

This is indeed suboptimal for a couple reasons. Mainly thought it is not enough for what SMI recommends. For their SATA controllers SMI has always used a 1GB per 1TB rule of thumb for RAM to NAND capacity ratio… and yet the 4TB capacity version of the ‘MX500’ series is using a mere 128MB per 1TB configuration.

Die Performanceprobleme wenn mehr Dies an einem Channel hängen statt mehr Channels zu haben, werden im übrigen durch immer schnellere NAND Interfaces gemindert, denn da findet ja ein Interleave statt, wie es hier dargestellt wird.

Je schneller also das Interface der NANDs ist, umso weniger stört es wenn mehr NAND Dies an einem Channel hängen, da die Wartezeit bis die Übertragung von einem anderen Die an dem Channel beendet ist, dann eben auch geringer ausfällt.

 

[Luckz]

sondern eben nur genug für einen Adressraum von rund einem Achtel

Da kann mit anderer Controller-Revision, anderer Firmware, usw, auch ein anderer Algorithmus verwendet werden. 1GB pro TB ist ja sozusagen nur das ganz stumpfe Ablegen der Mappingtabelle, ohne dass es auf Software- (=Firmware-)Seite besonders optimiert ist.
SSDs mit HMB verwenden im Vergleich zu 1GB pro TB auch nur ein paar popelige Megabytes RAM und haben damit trotzdem enorm gesteigerte Performance vs DRAMless. Der Algorithmus wird schon etwas smarter sein. (Natürlich wird eine HMB-Mappingtabelle sowieso anders ablaufen müssen, da sie ja am anderen Ende der PCIe-Verbindung stattfindet.)

 

[Holt]

1GB pro TB ist ja sozusagen nur das ganz stumpfe Ablegen der Mappingtabelle, ohne dass es auf Software- (=Firmware-)Seite besonders optimiert ist.

Eine flache Tabelle ist aber nun einmal von der Performance her die optimale Organisation einer Mappingtabelle, liews mal dies hier und die folgende Seite. Dann sollte klar sein, wieso ein direkte Mappingtabelle für die Performance optimal ist, nur eben entsprechend viel DRAM braucht. Die andere Alternative ist die Auflösung der Mappingtabelle zu verringern, statt also alle 4k nur alle 32k einen Eintrag zu machen, wie es hier beschrieben ist, aber auch dies hat Performancenachteile, wie man dort auch nachlesen kann.

SSDs mit HMB verwenden im Vergleich zu 1GB pro TB auch nur ein paar popelige Megabytes RAM und haben damit trotzdem enorm gesteigerte Performance vs DRAMless.

Nur gibt es eben bei SATA kein HMB, dies ist nur bei NVMe SSDs möglich und auch da ist der HMB relativ klein und erlaubt es nur einen Teil der Mappingtabelle zu cachen, was dann den Adressraum vergrößert über den zugegriffen werden kann, bevor Teile der Mappingtabelle aus dem NAND nachgeladen werden müssen, was entsprechend lange dauert und damit die Latenz massiv steigen lässt. Anandtech hat dies mal getestet:

Wie man sieht, reicht der Teil der Mappingtabelle im SRAM Cache gerade für einen Adressraum von 1GB aus, gerade genug um mit Benchmarks wie CDM oder AS-SSD in der Standardeinstellung tolle Werte fürs Datenblatt und Reviews zu produzieren, wo der Reviewer nur solche einfachen Benchmarks nutzt. Mit HMB steigt der Adressraum auf 32GB, damit sollten auch komplexere Benchmarks und eine Windows Installation klarkommen, so dass man auch da gut in den Reviews abschneiden kann. Wird aber regelmäßig über einen größeren Adressraum zugegriffen, dann fällt die Performance auch mit HMB genau so mies aus wie ohne, eben weil dann die Chance das der passende Teil der Mappingtabelle im SRAM oder HMB gecacht ist, immer wird und er damit immer öfter erstmal aus dem NAND nachgeladen werden muss, bevor die eigentlichen Daten gelesen werden können und genauso wird es wohl auch bei den SSDs aussehen die eine viel kleineren DRAM Cache als 1GB DRAM zu 1TB Kapazität haben. Ein kleinere DRAM Cache bringt technisch nur Nachteile, nur bei den Kosten ist er von Vorteil, aber da ist dann die Frage wie viel davon beim Kunden ankommt.