Leserartikel Crucial P5 2TB NVMe SSD Stresstest

[I'm unknown]

Crucial P5 2TB NVME SSD im Leser(stress)test​

Nachdem die anderen beiden Tests bereits seit einigen Tagen online sind, könnt ihr hier noch meine Erfahrungen mit der Crucial P5 2TB lesen. Ich möchte mich bei der Redaktion und Micron bedanken für den Test einer der Auserwählten zu sein.

Hinweis: Die technischen Daten findet ihr in meinem Test nicht nochmal, das hat die Redaktion im eigenen Test hier schön zusammengefasst: https://www.computerbase.de/2021-05/crucial-p5-ssd-test/

Als Hauptthema hatte ich mir den Vergleich mit einer sehr gut gefüllten Samsung 970 Evo Plus 1TB ausgesucht, es wird jedoch auch Temperaturdiagramme geben (welche ursprünglich nie geplant waren).

Bei den Testvorbereitungen gab es einige Überraschungen, mit denen ich nicht gerechnet hatte, wer interessiert ist kann gerne den Thread dazu lesen: https://www.computerbase.de/forum/threads/performanceprobleme-mit-dd-und-nvme-ssd.2021409/

Impressionen​

Schlichte Verpackung

Ebenso schlichte, aber seriös auftretende SSD

Auf der Rückseite gibt es nicht viel zu sehen

Schön zu sehen sind die Kernkomponenten welche alle zum Markeninhaber von Crucial gehören: Micron

Testsystem​

• Asus Crosshair VI Hero (X370 Chipsatz)
• Ryzen 7 3700X @Stock
• 4x16 GB DS @3200 MHz (XMP)
• Samsung 970 Evo Plus 1TB @ Samsung NVME Treiber 3.3
• Crucial P5 2TB @ MS NVME Treiber
• Windows 10 20H2 (10.0.19042.867) noch ohne dem Aprilupdates welche wegen Performanceproblemen in den News waren
• Ubuntu 21.04 (USB-Livesystem)

Messungen​

Die Transferraten und CPU-Auslastung wurden unter Linux mittels iostat geloggt, die Temperatur mit nvme-cli - jeweils 1x pro Sekunde.

Auszüge aus der man-Page für die Einheiten:

• r_await
  • The average time (in milliseconds) for read requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.
• w_await
  • The average time (in milliseconds) for write requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.
• aqu-sz
  • The average queue length of the requests that were issued to the device.
• %util
  • Percentage of elapsed time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100% for devices serving requests serially. But for devices serving requests in parallel, such as RAID arrays and modern SSDs, this number does not reflect their performance limits.
• rsec/s (rkB/s, rMB/s)
  • The number of sectors (kilobytes, megabytes) read from the device per second.
• wsec/s (wkB/s, wMB/s)
  • The number of sectors (kilobytes, megabytes) written to the device per second.
• %user
  • Show the percentage of CPU utilization that occurred while executing at the user level (application).
• %nice
  • Show the percentage of CPU utilization that occurred while executing at the user level with nice priority.
• %system
  • Show the percentage of CPU utilization that occurred while executing at the system level (kernel).
• %iowait
  • Show the percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.
• %steal
  • Show the percentage of time spent in involuntary wait by the virtual CPU or CPUs while the hypervisor was servicing another virtual processor.
• %idle
  • Show the percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request.

%util habe ich mit 10 multipliziert, damit entspricht 1000 100% in den Diagrammen!

Bei nvme-cli wurden die Werte der Samsung mittels nvme smart-log /dev/nvme0n1 | grep ^temperature >> nvme0_temp.log und die der Crucial mit nvme micron vs-temperature-stats /dev/nvme1n1 >> nvme1_temp.log aufgezeichnet. Compsite Temperatur stimmt bei allen Messwerten der P5 exakt mit dem Sensor #1 überein.

Ausgangssituation​

Die Firmware ist aktuell und für die Crucial ist der MS NVME Treiber in Verwendung.

Zustand der P5 direkt nach dem Einbau

Zustand der 970 Evo+ zu diesem Zeitpunkt

Einbauposition und verwendete Kühler​

Eine SSD im NVME Slot vom Board (direkt an die CPU mit PCIe 3.0 x4 angebunden) und mit einem Icy Box M.2 Kühler versehen. https://www.amazon.de/gp/product/B077MRDK16

Die andere SSD befand sich in einer PCIe zu NVME Adapterkarte mit Kühler und wurde im PCIEX8_2 Slot vom Board verbaut, welche dann von der GPU Lanes abgezweigt hatte und dadurch ebenfalls mit PCIe 3.0 X4 direkt an die CPU angebunden war https://www.amazon.de/gp/product/B07RWCGP1S

Füllstatus der 970 Evo+​

Klonvorgang 970 Evo+ auf neue P5​

Verbaupositionen:

• NVME: P5
• PCIe NVME Adapter: 970 Evo+

Wie schon erwähnt wollte ich das Temperaturverhalten nicht prüfen, wegen des Verhaltens entschloss ich mich bei den weiteren Tests dazu das zumindest zu loggen.

Mittels dd wurde die fast volle 970 Evo+ auf die nagelneue P5 bitgenau kopiert:

Die Transferraten dabei hatten mich zum Ende hin soweit verwundert dass die weiteren Tests auch Temperaturdiagramme enthalten – das wollte ich ursprünglich gar nicht mit aufnehmen.

Beim Schreiben von 1TB auf die P5 bricht die Transferrate teils deutlich ein und die Warteschlange steigt.

Bei der 970 Evo+ ist mein Problem von maximal 1,8 GB/s lesender Transferrate aus dem verlinkten Thread zu sehen.

CPU-Auslastung während des Klonvorgangs

Status nach Klonvorgang​

Ergebnis nach dem Klonen in GParted angezeigt

GParted hat die GPT an die neue Zielgröße angepasst

Die Lesevorgänge stammen aus der Testvorbereitung

Partitionsübersicht (die Testpartition wurde unter Windows erstellt und formatiert)

Füllstand der P5 nach dem Klonvorgang

Benchmarks nach Klonvorgang​

Profil "Default"

Profil "NVME"

Klonvorgang von 970 Evo+ auf leere Partition von P5 (T: „Test (P5)“)​

/dev/nvme0n1/p6 vor Klonvorgang (entspricht Laufwerk T: „Test (P5)“ unter Windows)

Vor dem Test habe ich die Partition mit ext4 formatiert, um eventuelle Performanceprobleme mit dem Userland-NTFS Treiber zu umschiffen.

Die Schreibrate bricht zum Teil extrem ein und w_await sprengt die Skala des Diagramms

Status nach Image von 970 Evo+ auf leere Partition​

Die SSD ist nun prozentual genauso gefüllt wie die 970 Evo+ zu beginn.

Benchmarks der gefüllten P5 vs voller 970 Evo+​

Vor diesem Test startete ich die Windows Datenträgeroptimierung auf C (Windows 10 P5) sowie D (Daten P5) und der Controller auf der P5 bekam mehrere Stunden Leerlauf um evtl. offene TRIM und/oder Aufräumvorgänge zu beenden.

Die doppelt so große SSD muss auch doppelt so viele Daten im Test schreiben, das war Absicht.
Zu den Partitionen habe ich leider vergessen einen Screenshot zu erstellen, Laufwerk T ist nun der 41,5 GB freier Speicher auf der P5, zu sehen etwas weiter oben in der GParted Übersicht.

Verbaupositionen der SSDs jeweils im NVME-Slot vom Board

Crucial P5 2TB				Profil "Default"	Profil "NVME"
Samsung 970 Evo Plus 1TB				Profil "Default"	Profil "NVME"

Benchmarks mit Bitlocker-Verschlüsselung (256 Bit AES)​

Da ich auch noch die Dauerleistung der 970 Evo Plus betrachten möchte habe ich nur die 41,5 GB Partition mit Bitlocker verschlüsselt.

Profil "Default"

Profil "NVME"

Klonen von den ersten fünf Partitionen der P5 zurück auf die 970 Evo+​

Einbaupositionen:
NVME: Samsung 970 Evo+
PCIe Adapter: Crucial P5

Um einen Vergleich der Stressbelastbarkeit zwischen den beiden Laufwerken ziehen zu können entschloss ich mich die Wiederherstellungspartition, EFI-Partition, Windows (C: ) und Daten (D: ) und die MS-Reserved (wird unter Windows nicht angezeigt) von der P5 zurück auf die 970 Evo Plus zu schreiben. Mir war wichtig zu prüfen ob es ähnlich starke Einbrüche auch bei der Samsung gibt.

Diese Partitionen wurden mit den Inhalten der Daten aus der P5 überschrieben.

Skriptgesteuert, da nur die Inhalte der Partitionen, nicht jedoch die GPT kopiert werden sollte.

Das letzte viertel sieht komisch aus, da ich jedoch nur 1x pro Sekunde messe und die Daten so stark schwanken vermute ich einen weniger starken Einbruch im Schnitt als bei der P5.

Fazit​

Zusammenfassend gibt es aus meiner Sicht ein paar Punkte welche angesprochen werden sollten:

1. Die P5 ist eine gut, aber keine herausragende SSD:
   Bei sehr kleinen Daten (<256KB) ist die Schreibrate im Vergleich zur Leserate deutlich geringer. Außerdem sind deutliche und anhaltende Einbrüche beim dauerhaften Schreiben zu beobachten.
2. Je mehr belegt ist, desto mehr sinkt die Leistung bei dauerhaften Schreibvorgängen:
   Dieses Verhalten kann man besonders an den Klonvorgängen sehen: Der erste wurde noch in ca. 1000 Sekunden abgeschlossen, der zweite dauerte über 2000 Sekunden.
3. Preis/Leistung
   Die P5 ist kein Schnäppchen, daher sehe ich die Einbrüche beim Stresstest als größeren Minuspunkt an.
4. Nichts desto Trotz ist die P5 eine SSD welche durchaus empfehlenswert ist wenn nicht dauerhaft sehr viel darauf am Stück geschrieben wird. Das sieht man auch an den Benchmarks unter Windows nach den Klonvorgängen, die Leistung bleibt zum großen Teil erhalten.
5. Temperaturverhalten
   Sollte nie in den Test, ich kenne leider auch nicht das Verhalten vom Controller ab welchen Schwellen eine Drosselung einsetzt, es sieht für mich aber eher so aus als ob der SLC-Cache am Ende ist - andernfalls hätte bei Durchgang 1 die Drosselung früher einsetzen müssen (wie gesagt, ich habe dabei keine Temps aufgezeichnet).

Daher kann ich nur raten genau das eigene Anforderungsprofil zu prüfen bevor eine NVME SSD der gehobenen Klasse angeschafft werden soll. Für dauerhaftes Schreiben sehr großer Datenmengen gibt es bessere Laufwerke (und je nach Anwendungsfall muss man deutlich tiefer in die Tasche greifen wenn man mehr Konsistenz wünscht und/oder auf RAID-Lösungen setzen).

SMART Daten nach Abschluss aller Tests

 

[tony_mont4n4]

Toller Test!

 

[MichaG]

Dem schließe ich mich an. Die Diagramme zur Schreibrate beim Klonen sind sehr interessant!

Wobei ich mich nicht traue, die zu analysieren/einzuordnen. 😅 Bei der P5 würde ich dann auch auf den ausgehenden SLC-Cache tippen. Aber was zur Hölle macht die 970 Evo+ da?!

 

[I'm unknown]

Danke!

Nach den Performanceproblemen beim Lesen mittels dd und Blocksize 1MiB (maximal 1,8 GB/s bei Partitionen die voll sind und ~3 GB/s bei der leeren Partition der P5) habe ich keine schlüssige Theorie an was das liegen könnte. Wenn ich die nächsten zwei Wochen mal Zeit habe werde ich nochmal ein Image der 970 ziehen und zurück klonen mit Messwerten alle 100 - besser noch 10 ms. Nagelt mich da aber bitte nicht drauf fest - mal schnell dazwischen schieben ist es momentan schwierig, würde aber selbst gerne wissen was das war.

Die P5 bricht bei starker Füllung ja auch deutlich ein - mangels erheblich besserem Vergleich will ich das aber weder gut noch schlecht bewerten - die Benchmarks danach zeigen ja trotz der hohen Füllung gute Werte an.

Für so ein Szenario ist eine "Pro" bzw. Enterprise Variante wie z.B. eine Optane mit Sicherheit die bessere Wahl. Ist dann allerdings eine deutlich andere Preisliga.

 

[Rickmer]

Toll gemacht. Es war vielleicht der letzte der drei Tests, aber der hat mir mit Abstand am besten gefallen. Man merkt, dass du dir echt Mühe gemacht hast und nicht nur das Minimum um die SSD behalten zu dürfen.

Für so ein Szenario ist eine "Pro" bzw. Enterprise Variante wie z.B. eine Optane mit Sicherheit die bessere Wahl. Ist dann allerdings eine deutlich andere Preisliga.

Optane ist jetzt schon ein Extrembeispiel

Mich würde insbesondere ein Vergleich interessieren mit einer entry-level Enterprise SSD wie z.B. der Samsung SSD PM983 1.92TB (auch in u.2) oder einer gebrauchten Intel P4500 / 4510 oder vergleichbar, die tauchen ja schonmal recht günstig bei ebay auf.

 

[Zeitwächter]

Toll gemacht. Es war vielleicht der letzte der drei Tests, aber der hat mir mit Abstand am besten gefallen. Man merkt, dass du dir echt Mühe gemacht hast und nicht nur das Minimum um die SSD behalten zu dürfen.

Jo, ich finde auch dass er unter den drei Testern (mich eingeschlossen) mitunter den meisten Umfang in den Tests hat.
Aber ich denke das liegt nicht daran, dass andere aufs Nötigste abgezielt haben sondern einfach an den vorhandenen oder fehlenden Erfahrungen und Know How. An diesem Artikel habe ich erkannt, wie umfangreich man einen Test darstellen kann und wie viel ich selber auch teils nicht wusste, bzw nicht mal dran dachte zu berücksichtigen...

Dennoch würde ich bspw meinen Lesertest auch nicht mit diesem hier vergleichen wollen - die Zielgruppen sind aus meiner Sicht hierfür unterschiedliche.
Mein Leserartikel zielt es auf die Nutzung der Crucial P5 SSD aus der Sicht eines einfachen Users/Gamers.
(mehr Gamingvielfalt hätte ich gerne eingebracht, leider herrscht da eine Einschränkung durch die eigene Spielebibliothek)
Ich denke ein einfacher User/Gamer würde sich mit dem Verständis der ganzen Diagrammen und Screenshots aus diesem Artikel etwas schwer tun

 

[silenter72]

Jo, ich finde auch dass er unter den drei Testern (mich eingeschlossen) mitunter den meisten Umfang in den Tests hat.
Aber ich denke das liegt nicht daran, dass andere aufs Nötigste abgezielt haben sondern einfach an den vorhandenen oder fehlenden Erfahrungen und Know How. An diesem Artikel habe ich erkannt, wie umfangreich man einen Test darstellen kann und wie viel ich selber auch teils nicht wusste, bzw nicht mal dran dachte zu berücksichtigen...

Dennoch würde ich bspw meinen Lesertest auch nicht mit diesem hier vergleichen wollen - die Zielgruppen sind aus meiner Sicht hierfür unterschiedliche.
Mein Leserartikel zielt es auf die Nutzung der Crucial P5 SSD aus der Sicht eines einfachen Users/Gamers.
(mehr Gamingvielfalt hätte ich gerne eingebracht, leider herrscht da eine Einschränkung durch die eigene Spielebibliothek)
Ich denke ein einfacher User/Gamer würde sich mit dem Verständis der ganzen Diagrammen und Screenshots aus diesem Artikel etwas schwer tun

Dem schließe ich mich an.