Test Corsair MP600 Pro XT im Test: Im Spitzenduell mit der Seagate FireCuda 530

M@tze schrieb:
Und welche Zigarettenmarke gibt es, die ein XT im Namen hat? Bin kein Raucher und frage für einen Freund...
Teslacigs XT ... als E-Zigaretten sogar näherer Zusammenhang als die Shimano XT. Bin Nichtraucher und mein Freund Google hat die Frage Deines Freundes beantwortet :cool_alt:
 
  • Gefällt mir
Reaktionen: M@tze
icyFranky schrieb:
Zu dem Ritzel, früher wurden halt Zigarettenpackungen als Größenorientierung daneben gestellt 🤮
Für eine Größenorientierung würde ich dann aber auch einen "üblicheren" Gegenstand nehmen als ein Ritzel, zumal es hier ja anscheinend eher um die "Industrie-Optik" ging, als um eine Größeneinordnung.
 
Könnten wir den Inhalt der Diskussion bitte wieder auf die SSDs lenken? Die XT-Kassette ist auf dem Bild, weil ich die Fotos zuhause im Keller bei dort guten Lichtverhältnissen gemacht habe, und dort gerade das Rad zur "Generalüberholung" in seinen Einzelteilen stand.
 
  • Gefällt mir
Reaktionen: Gurkenwasser, Cpt.Willard, massaker und 5 andere
M@tze schrieb:
Und auch die Zugriffszeit ist geringer (ca. 50%) als bei einer SATA SSD
Vergleicht man den relativen Sprung den die Zugriffszeiten von HDD auf Sata SSD gemacht haben, ist alles in dem Bereich, was von Sata SSD auf die "schnellen PCIe 4.0 NVMe 1.4 M.2" im Consumer Bereich gekommen ist, ein "hat sich kaum was getan".
Und nicht vergessen, die Wirkung von diesem Sprung bei den Zugriffszeiten von HDD auf SSD ist es, was "Rechner auf einen ungeahnten Feuerstuhl geschnallt hat und selbst (sehr) alten Rechnern einen sehr langen zweiten Frühling" verschafft. Natürlich auch wegen der Übertragungsrate, aber das in einem sehr viel geringerem Maße als viele meinen, wie man sieht, wenn man eine Sata SSD an einem Sata Controller der ersten Generation (Sata I / Sata-150) anschließt und von den Übertragungsraten maximal 150MB/s übrig bleiben
 
catch 22 schrieb:
Und nicht vergessen, die Wirkung von diesem Sprung bei den Zugriffszeiten von HDD auf SSD ist es, was "Rechner auf einen ungeahnten Feuerstuhl geschnallt hat und selbst (sehr) alten Rechnern einen sehr langen zweiten Frühling" verschafft.

Das habe ich ja geschrieben.

HDD -> SATA SSD, da war der Booster die Zugriffzeit, welche ohne weitere Voraussetzungen von jedem System sofort genutzt werden konnte (auch alte Laptops), selbst mit SATA1 Interface. Klar, war auf 150 MB/sec gedrosselt, aber die Zugriffszeit war trotzdem super und 150 MB/sec war damals mehr als (fast) jede HDD bieten konnte.

SATA SSD -> NVMe SSD, da ist der Booster IOPs und damit die Parallelisierung und die kann eben nicht out-of-the-box von jedem System genutzt werden. Aber wehe, wenn sie losgelassen... ;)

catch 22 schrieb:
Vergleicht man den relativen Sprung den die Zugriffszeiten von HDD auf Sata SSD gemacht haben, ist alles in dem Bereich, was von Sata SSD auf die "schnellen PCIe 4.0 NVMe 1.4 M.2" im Consumer Bereich gekommen ist, ein "hat sich kaum was getan".

Deswegen schrieb ich ja:

M@tze schrieb:
Und auch die Zugriffszeit ist geringer (ca. 50%) als bei einer SATA SSD, aber nicht der entscheidende Punkt.

Und von 100ms zu 40ms ist immer noch ordentlich, aber eben nicht mehr dass was das Kraut fett macht bzw die Performance liefert.
 
Zuletzt bearbeitet:
M@tze schrieb:
Und von 100ms zu 40ms ist immer noch
Na wenn wir die noch hätten würden wir alle noch viel lahmer sein

gute HDDs hatten 7ms Zugriffszeit bei SSDs sind wir bei 0,1 ms und drunter ...

Da sprechen wir halt von 6,9 ms Einsparung vs 0,06 ms wenn ich mal deine Einheiten passend korrigiere.

Also die Ersparnis bei der Zugriffszeit ist um den Faktor 100 geringer.
 
M@tze schrieb:
Das habe ich ja geschrieben.
Ist ja lustig... denn ich habe noch mal genauer umschrieben, was ich geschrieben hatte...
und nur noch mal darauf hingewiesen, dass dein Einwand der erhöhten (Booster) IOPS eben nicht so viel Wirkung haben

M@tze schrieb:
Und von 100ms zu 40ms ist immer noch ordentlich,
Du liegst übrigens mit den Einheiten und Werten etwas daneben.
Festplatten hatten bei der Einführung von SSD üblicherweise 9ms (und das waren schon die Spitzen Platten, teilweise aus dem Enterprise Bereich) bis etwa 14ms (langsame Platten mit 5200RPM), wobei die meisten Platten mit etwa 11ms rumdümpelten.
Sata SSD (selbst die der ersten Generation) sind da etwa 100 mal so schnell. Deren typischen Zugriffseiten liegen bei ~0,1ms (knapp drüber, 0,11 bis 0,13 meine ich im Kopf zu haben). Und selbst wenn man diesen Wert nun noch mal halbiert, also bei etwa 0,05ms raus kommt, ist der Effekt, gefühlt wie auch Real, im Vergleich zu dem ursprünglichem Boost einfach nur lächerlich gering.

Natürlich ist eine moderne M.2 SSD mit wirklich vielen IOPS toll, vor allem wenn man parallel mehrfach auf wirklich große Datenmengen zugreift und diese bewegt, was auf einem privaten Desktop, wie auch wohl 90+% aller Büro (Office) Rechner (und vermutlich in diesem "ausufernden Maß" auch ausreichend vielen Workstation Rechnern), selten bis eher nie passiert und letztendlich vor allem zentralen Systemen (Datenserver usw.) zu gute kommt, die Zeitgleich unzählige große und kleine Datenzugriffe auf den Speichermedien abwickeln müssen.
 
Zuletzt bearbeitet:
xxMuahdibxx schrieb:
Na wenn wir die noch hätten würden wir alle noch viel lahmer sein

catch 22 schrieb:
Du liegst übrigens mit den Einheiten und Werten etwas daneben.

Ihr habt Recht, da habe ich mich bei den Zeiten komplett verhauen. Keine Ahnung wie ich gestern auf die Werte gekommen bin, hätte mir schon beim Schreiben auffallen müssen. ;)

catch 22 schrieb:
Natürlich ist eine moderne M.2 SSD mit wirklich vielen IOPS toll, vor allem wenn man parallel mehrfach auf wirklich große Datenmengen zugreift und diese bewegt, was auf einem privaten Desktop, wie auch wohl 90+% aller Büro (Office) Rechner (und vermutlich in diesem "ausufernden Maß" auch ausreichend vielen Workstation Rechnern), selten bis eher nie passiert

Das hatte ich oben versucht zu erklären. Das liegt auch auf einem Desktop PC einfach daran wie die File API die Zugriffe regelt. Entweder schön nacheinander (mehr oder weniger) oder parallel gleichzeitig und damit die IOPs auch nutzt. Ob ich da jetzt auf meinem Server im Büro Datenbankzugriffe habe oder zu Hause mein Lightroom Fotos lädt oder ein Spiel startet ist der API eigentlich egal. Hier nochmal als Zitat von pcgameshardware:

Prozessoren schicken für jeden Datenblock eine I/O-Anfrage an das Laufwerk, wobei bestehende APIs jede dieser Anfragen einzeln bearbeiten und die nächste erst abarbeiten, wenn die vorherige abgeschlossen ist. Ab einem gewissen Laufwerks-Tempo führt dies zu einem signifikanten CPU-Overhead. Direct Storage für Windows 10 soll diesen Overhead unter Einsatz des NVMe-Protokolls reduzieren, das sowohl parallele als auch gebündelte I/O-Anfragen erlaubt. Pate stand die Technik der Xbox Series X.

Wenn Du auf einer alten HDD zBsp. einen simplen Copy Job startest, wird die File API jede Datei/Verzeichnis nacheinander anfordern, da der Lesekopf auf der HDD immer nur an einer Stelle der Platte stehen kann. Wenn Du jetzt 2 Copy Jobs parallel startest, wird das ganze Ding komplett einbrechen, da die 2 Jobs immer abwechselnd von der File API Ihren Slot bekommen und der Lesekopf für jeden Job wieder hin- und her positioniert werden muss. Ich denke, das wird jeder von uns noch kennen, dass das keine gute Idee ist und man die Platte dann auch heftig arbeiten hören (Kopf wird hin und her gefahren) kann. ;)

Steckt in dem Rechner jetzt eine SSD, wird die File API genau das gleiche machen, 1 File nach dem anderen. Startet man dort jetzt 2 Jobs, wird das nicht einbrechen, da bei der SSD kein Lesekopf positioniert werden muss. Natürlich geht das alles viel schneller, aber trotzdem wird die File API bei einem einzelnen Job eins nach dem anderen erledigen, da sie so programmiert ist und ihr egal ist ob da unten jetzt eine HDD oder SSD steckt. Deswegen sieht man auch (außerhalb von Benchmarks) keinen Geschwindigkeitsvorteil zwischen SATA und NVMe SSD.

Die neue API würde den Copy Job automatisch aufsplitten und mehrere I/O Requests parallel bearbeiten. Nur dadurch können die sehr hohen Lese- und Schreibleistungen bei NVMe realisiert werden. Also hat auch der normale User im Alltag davon Vorteile, nicht nur bei Datenbankzugriffen und dergleichen.
 
Novocain schrieb:
@der Unzensierte
Sehe ich ähnlich, denke auch das es mit Direct Storage erst interessant wird und das dürfte dauern (und die Frage ist dann überhaupt was es bringt), bis dahin können und sollen die Preise fallen xD
Sehe das nicht ganz so pessimistisch, weswegen ich mich auch schon eingedeckt habe. Direct Storage wird auch auf der Xbox verwendet und in w11 ziemlich schnell der Standard bei neuen Games werden. Man sieht auch schon auf der PS5 was der Unterschied ist. Wenn ein Game vorher 20-30 Sekunden zum laden benötigte, sind es jetzt nur noch 3-5 Sekunden. Man egalisiert damit also fast vollständig die Ladezeiten, daher ist die Diksussion ob und wann eigentlich obsolet. Da es sicher kommt. Ich habe mich an der Sony Empfehlung orientiert das es zwingend eine entsprechende PCie 4.0 mit hoher Geschwindigkeit sein soll für die Technik.

Der Vorteil ist vielleicht auch das wenn es am PC (entgegen der Ewartung) doch nicht so wichtig sein wird kann ich die NVME immer noch in der PS5 verwenden. Daher finde ich es recht wichtig als Gamer die freigegeben zu verwenden. Laut diverser Tests auf der PS5 sind letztlich auch PCie 3.0 NVME "okay" zumindest waren da nur wenige Sekunden Unterschied, da aber Sony explizit anderes empfiehlt wird das schon seine Gründe haben. Muss jeder selber wissen ob es den Aufpreis wert ist. Letztlich reichen den meisten normale SATAs SSDs oder eine PCIe 3.0 NVMe. Die paar Sekunden sind dann auch nicht so wichtig. Ich hab mir allerdings gedacht haste eh 5 Jahre Garantie und bevor ich mir was für PCie 5.0 kaufe kann es dauern xD

Für den üblichen Alltag der meisten User ist es natürlich sowieso völlig irrelevant, da niemand ein so schnelles Netzwerk hat und auch nicht intern in der Regel 2x PCIe 4.0.
Man kann also eigentlich nur wie in den Tests mit RAM-Disk arbeiten um den Speed abzurufen. Es limitiert sonst immer eine Seite.

Auf Dauer werden sicherlich die Preise wieder sinken, das ist wie immer mit Hardware. Allerdings gehe ich erst mal sogar von hoher Nachfrage aus, insbesondere von den PS5 verifizierten. Da decken sich viele ein.
 
Hat jemand die NVME unter nem NH-D 15 im Einsatz, bzw. kann sagen ob das passt?
 
  • Gefällt mir
Reaktionen: Cpt.Willard, Demon_666 und Jan
Die Risszeichnung hab ich mir auch angeschaut, war mir nur nicht sicher bzgl. der anderen Seite - was aber logisch ist...
 
Wird doch bestimmt genug Tests geben, einfach nen bissel abwarten.
 
Hier noch ein "Langzeittest" (na ja, 6 Monate), zur MP600 Pro XT, sehr ernüchternd:

Ich hab mir die SSD am 20.10.2022 gekauft, also ist sie jetzt ca. 6 Monate alt. Seit ein paar Wochen hat sich Windows etwas träge angefühlt, als ich dann Dateien von der SSD kopiert habe, hat sich dann herausgestellt, es liegt an der MP600.

Crystaldiskmark zeigt die vollen 7 GB/s Lesen und 6,x GB/s Schreiben, wenn ich aber etwas Alte lese, dann wird es plötzlich sehr langsam:
veryslow.png

Hier kopiere ich eine (alte) 32 GB Datei von der SSD (C:) auf eine andere SSD (F:, SATA, Samsung 860 EVO 4 TB), die Kopie läuft nur sehr langsam, zeitweise mit unter 10 MB/s. Die Ziel-SSD ist nicht schuld.

Wenn ich die Datei zurückkopiere und wieder lese, ist es schnell:
reading_new0.png

Also neue SSD gekauft, Daten kopiert, das habe ich heute morgen angefangen, jetzt war es nach 13 h fertig (ddrescue mit ddru_ntfsbitmap), Durchschnittliche Geschwindigkeit 70 MB/s.

Ich hab jetzt mit Corsair mal ein Ticket aufgemacht, neueste Firmware aufgespielt (hat nichts gebracht, die SSD-Toolbox von Corsair ist ein graus). Für mich sieht das aus, als würde die SSD die Zellen nicht sauber im Hintergrund refreshen. Die SSD hat dafür täglich im Schnitt 5 h mit Strom, es sollte also kein Problem sein. Wenigstens war beim Lesen kein einziger Lesefehler dabei.

Hat hier jemand sonst eine MP600 Pro gekauft und könnte mal nach alten, großen Dateien suchen und die "wegkopieren", ob das reproduzierbar ist?

@CB habt ihr die SSD noch im Schrank liegen? Nvm: War ja geliehen.
 
Hancock schrieb:
als würde die SSD die Zellen nicht sauber im Hintergrund refreshen
Könntest Du bitte noch den SSD Read Speed Tester v. 2.04 durchlaufen lassen und die Ergebnisse posten? (Screenshot wird am Ende im Programmfolder automatisch erstellt)
 
  • Gefällt mir
Reaktionen: Jan
massaker schrieb:
Könntest Du bitte noch den SSD Read Speed Tester v. 2.04 durchlaufen lassen und die Ergebnisse posten?
Lass ich gerade laufen, scannen hat mal so 15 Minuten gedauert, wie lange ließt er dann? Alle "alten" Dateien? Dann dauert das so ca. 13 h...

Update 19:00: Programm läuft seit 9:30 h, ist ca. bei 3/4 angekommen. Ich glaub nicht, dass ich da so arg schnelle Werte bekomme...

Update: Fertig, sieht nicht so schnell aus. (Hinweis, das Image ist gecloned, daher sind manche Dateien "älter" als die SSD).
2023-04-06 21.26.44 Results for C.png

Und weil es mich interessiert, hier noch ein Scatterplot Speed über Dateialter und Histogram über alle Geschwindigkeiten:
speed_histogram.png

speed_scatter.png

Insgesamt sehr ernüchternd... Interessanterweise setzt die langsame Geschwindigkeit bei ca. 200 Tagen ein, das ist der Zeitpunkt der ersten Befüllung. Da wurden 2 TB in einem Schlag geschrieben (also was die SATA Quell-SSD hergegeben hat, mit ca. 450 MB/s). Ist da etwas mit dem Retiring von SLC zu TLC schiefgegangen? Oder hab ich einfach ein sehr kleinen Workload beim Schreiben.
BTW: Mir fällt noch etwas ein, beim Erstbeschreiben wollte ich nicht ne direkte "dd" Kopie machen, sondern "clever" vorgehen und hab mit ddru_ntfsbitmap ein bitmap für ddrescue zum Kopieren erstellt, ich habe aber das Manual nicht richtig gelesen und daher mit
Code:
ddrescuce --force /dev/sda3 /dev/nvme0n1p3 bitmap
kopiert. Dadurch habe ich im ersten Durchlauf alle Blöcke beschrieben, die leer sind und alle vollen Blöcke übersprungen... Das hab ich schnell bemerkt, und dann nochmal mit "-m bitmap" kopiert und unter Windows einmal TRIM gemacht.

Aber egal was an Writes auf die SSD geht und gegangen ist (7 TB laut SMART, also nicht mal 2 Disk writes), das ist einfach vieeel zu langsam und inakzeptabel.
 
Zuletzt bearbeitet: (Besserer Scatterplot)
  • Gefällt mir
Reaktionen: massaker und VelleX
Jetzt erst gesehen dass du die Screenshots gepostet hast.
Bei den kleinen Dateien kann man zwar schwer beurteilen wie schnell die überhaupt so laufen sollten, aber allgemein betrachtet sieht das schon sehr ernüchternd aus.
Bin ich wirklich mal gespannt wie das bei mir in paar Wochen aussehen wird. Allerdings wird die SSD bei mir größtenteils eher als Arbeitsplatte benutzt, und nicht als Datenlager. Daher werden die meisten Dateien nicht lange drauf bleiben.
Aber einige Daten werden bestimmt drauf bleiben die älter sind, daher werde ich dann auch nochmal das Programm durchlaufen lassen.
 
  • Gefällt mir
Reaktionen: Hancock
Zurück
Oben