[User-Review] Verschiedene SATA SSDs - Und warum AMD SATA Controller zum Abgewöhnen sind

[java4ever]

Moin,

Ich hab die letzten Tage mal ein bisschen gebenchmarkt

Ich bin aktuell am Aufbereiten der Ergebnisse (Ich werde einfach den kompletten Ordner hochladen)

Testkandidaten waren:

• Micron 1300 2TB
• Crucial MX500 500GB
• Samsung 850 EVO 500GB
• Samsung 870 EVO 500GB
• Samsung SM863 1TB
• Sandisk SSD Ultra 2TB
• (Begrenzt Sandisk SSD PLUS 2TB)
• (Begrenzt Crucial MX500 2TB)

Vorher möchte ich sagen:
Das ist nur eine schnelle Benchmarkreihe, die ich gemacht habe, um Unterschiede herauszustellen.
Ich erhebe keinen Anspruch auf Vollständigkeit (bspw. ist mit 30GB Sample Size der SLC Cache moderner SSDs wie der 970 EVO PLUS nicht zwangsläufig ausgeschöpft)
Diese Tests sind aber eher auf Serveranwendungen gerichtet (fsync=1)

Erstmal möchte ich mich auf fio Tests fokussieren
Write: fio --name TEST --filename=temp.file --rw=write --size=30g --blocksize=1024k --ioengine=io_uring --fsync=10000 --iodepth=32 --direct=1
Read: fio --name TEST --filename=temp.file --rw=read --size=30g --blocksize=1024k --ioengine=io_uring --fsync=10000 --iodepth=32 --direct=1
RandRead: fio --name TEST --filename=temp.file --rw=randread --size=30g --blocksize=4k --ioengine=io_uring --fsync=1 --iodepth=1 --direct=1 --numjobs=32 --runtime=60 --group_reporting
RandWrite: fio --name TEST --filename=temp.file --rw=randwrite --size=30g --blocksize=4k --ioengine=io_uring --fsync=1 --iodepth=1 --direct=1 --numjobs=32 --runtime=60 --group_reporting
RandRW: fio --name TEST --filename=temp.file --rw=randrw --size=30g --blocksize=4k --ioengine=io_uring --fsync=1 --iodepth=1 --direct=1 --numjobs=32 --runtime=60 --group_reporting

Hardware:
System an sich: Threadripper 3960X @ Zenith II Extreme Alpha, 256GB DDR4-3600 CL16, IF 1800
Controller: LSI 9300-8i
OS: Linux Kernel 5.13.0-25

Benchmarks die jetzt folgen wurden auf Linux mit ext4 Partitionen durchgeführt

Nun hier die Tabelle:

Fazit Teil 1:

• Der AMD SATA Controller ist, wie bereits bekannt, grottig.
• Samsung EVO SSDs haben MASSIVE Probleme mit Random Write
• Enterprise SSDs (SM863) kännen Random Write einfach deutlich besser als Consumer SSDs

Fazit Teil 2 (Thema AMD vs LSI):
Wir erkennen:

• Am LSI durchgängig (bis auf die Ultra 2TB) höhere sequentielle Schreibleistung
• Etwa gleiche Leseleistung, Ultra 2TB kann 10% mehr lesen am LSI
• RandRead IOPS am LSI sind DEUTLICH höher (Bis zu 50% mehr an der SM863!)
• RandWrite IOPS am LSI sind auch besser
• RandRW Write und Rad sind euch (teilw. 40%) besser

Zusatzinfos:
Ich habe versehentlich mal die Micron 1300 an dem ASMedia Controller angeschlossen (Das Zenith hat zwei, AMD und ASMedia)
Die Ergebnisse sind katastrophal!

(Ja, das war die erste Benchmarkreihe, da fehlte RandWrite)
Ich glaube dazu braucht man nicht viel zu sagen, außer dass der ASMedia Controller (wie ja bereits bekannt) absolut katastrophale Performance liefert und ASMedia sich schämen sollte.

Ich habe mich über die Performance der Samsung EVO SSDs gewundert und habe deswegen auch einmal low level format gemacht
Hat nichts gebracht
Die SSDs haben dann nur noch 2000 IOPS, im zweiten run 7000 IOPS und dann runter auf 2000 und im dritten run dann wieder konsistent 7000 (was daran liegen dürfte, dass die SSD dann noch mit Garbage Collection beschäftigt ist)
Es liegt also meiner Ansicht nach definitiv an den SSDs, denn die Performance ist sowohl am AMD Controller als auch am LSI, der deutlich besser ist als der AMD, schlecht.

Meine persönliche Empfehlung aktuell: Die MX500 SSDs.
Wenn andere SSDs günstiger sind, sind auch die in Ordnung. Für den Desktopuser wird das eher verschmerzbar wenig Unterschied machen. Aber immerhin sind wir hier im Luxx

...Fortsetzung folgt!

 

[Holt]

Fazit Teil 1:

• Der AMD SATA Controller ist, wie bereits bekannt, grottig.
• Samsung EVO SSDs haben MASSIVE Probleme mit Random Write
• Enterprise SSDs (SM863) kännen Random Write einfach deutlich besser als Consumer SSDs

Das die SATA Host Controller in den AMD Chipsätzen der 500er Reihe vor allem mit dem IOPS Problem haben, ist bekannt. Das eine Enterprise SSD an einem SAS Controller besser abschneidet, wäre vor allem dann kein Wunder, wenn dieser den Schreibcache der SSDs deaktiviert, denn da die Enterprise SSD eine Full-Power-Loss Protection hat, darf sie dies ignorieren und ihren Schreibcache weiterhin nutzen, da sie ja im Fall eines Stromausfalls die Daten trotzdem noch in ihr NAND schreiben kann. Die SAS HBAs/RAID Controller machen dies ja eben, weil sie i.d.R. selbst einen DRAM Cache haben der durch eine BBU vor Datenverlust bei Spannungsabfall geschützt ist und damit wäre dann unsinnig einen Datenverlust im Schreibcache der Laufwerke zu riskieren. Leider gibt es aber SSDs die keine Full-Power-Loss Protection haben und trotzdem ihren Schreibcache nutzen, wenn sie dies nicht sollten bzw. eben die Antwort auf ein sync faken und so tun als wären sie Daten schon ins NAND geschrieben, wenn sie es noch gar nicht sind.

Dies erhöht natürlich die Performance gerade bei zufälligen 4k Zugriffen gewaltig, zumal die Pagesize von aktuellen NANDs ein Vielfaches von 4k beträgt und die Controller deshalb möglichst so viele 4k Schreibzugriffe im Schreibcache sammeln, bis sie wenigstens eine Page mit den Daten vollschreiben können. Vielleicht liegt da der Grund warum die MX 500 so viel bessere IOPS schreibend hatte, denn eigentlich sind die Evo ihr da überlegen, aber vielleicht hatte es auch mit dem Pseudo-SLC Schreibcache zu tun, denn die MX500 schafft bei vollem Pseudo-SLC Schreibcache keine 481MB/s schreibend, eher maximal so 400MB/s.

Ich glaube dazu braucht man nicht viel zu sagen, außer dass der ASMedia Controller (wie ja bereits bekannt) absolut katastrophale Performance liefert und ASMedia sich schämen sollte.

Wenn es der alte 1061 ist, so wundert dies nicht, da der ja nur mit einer PCIe 2.0 Lane angebunden ist und mehr als so 400MB/s gehen da netto pro Richtung nicht drüber. Den alten ASM 1061 sollte man wirklich nur zum Anbinden von HDDs verwenden, keine Ahnung ob es noch so ist, aber am Anfang gab es bei dem Probleme beim Brennen mit optischen Laufwerken und daher oft den Hinweis im Handbuch der Mainboards, dort nur HDDs anzuschließen. Es gibt von ASMedia aber auch neuere SATA Host Controller mit bis zu PCIe 3.0 x2 Anbindung, die dürften damit auch besser performen, aber leider verbauen die Mainboardhersteller immer noch vor allem den alten 1061, vermutlich weil er eben billiger sein dürfte. Schämen sollten sich also also auch die Mainboardhersteller.

Ich habe mich über die Performance der Samsung EVO SSDs gewundert und habe deswegen auch einmal low level format gemacht
Hat nichts gebracht

Low-Level Format? Bei SSDs wäre ein Secure Erase das Mittel der Wahl gewesen, zumal es auch bei HDDs schon seit Jahrzehnten keine echten Low-Level Formats nach dem ersten und einzigen währen der Herstellung im Werk mehr gibt! Die Tools die immer noch vorgeben sowas zu machen, überschreiben nur alle Adressen mit 00 und bei einer SSD bedeutet dies, dass sie dann aus Sicht des Controller komplett vollgeschrieben ist, bis eben ein Secure Erase erfolgt oder Adressen getrimmt werden. Nur unterstützen längst nicht alle SAS Controller auch TRIM für SATA Laufwerke und dies solltest Du mal ausprobieren, ich fürchte der LSI kann es nämlich nicht.

Ggf. solltest Du also den Test noch einmal wiederholen, nachdem alle SSDs die gleichen Ausgangsbedingungen haben, also entweder komplett leer nach einem Secure Erase oder komplett voll. Denn gerade bei Consumer SSDs macht der Unterschied zwischen leer und (aus Sicht des Controllers) voll eine Menge aus und wenn Du da alles mit 00 überschrieben hast, dann ist die SSD für den Controller komplett mit gültigen Daten gefüllt und dies ist der Worst Case.

 

[java4ever]

Schämen sollten sich also also auch die Mainboardhersteller.

Weder der Controller, noch das Verbauen desselbigen ist eine Glanzleistung...

Leider gibt es aber SSDs die keine Full-Power-Loss Protection haben und trotzdem ihren Schreibcache nutzen, wenn sie dies nicht sollten bzw. eben die Antwort auf ein sync faken und so tun als wären sie Daten schon ins NAND geschrieben, wenn sie es noch gar nicht sind.

Möglich, müsste man aber in einem nicht ganz trivialen Versuch bei der MX500 eruieren.
Generell kann man aber sagen dass Consumer SSDs, egal ob mit oder ohne deaktivierten Schreibcache, beim Power Loss Probleme machen (da gab es mal ein schönes Paper zu, das gezeigt hat, dass fsync bei Consumer SSDs wenig wert ist)

Low-Level Format? Bei SSDs wäre ein Secure Erase das Mittel der Wahl gewesen, zumal es auch bei HDDs schon seit Jahrzehnten keine echten Low-Level Formats nach dem ersten und einzigen währen der Herstellung im Werk mehr gibt! Die Tools die immer noch vorgeben sowas zu machen, überschreiben nur alle Adressen mit 00 und bei einer SSD bedeutet dies, dass sie dann aus Sicht des Controller komplett vollgeschrieben ist, bis eben ein Secure Erase erfolgt oder Adressen getrimmt werden. Nur unterstützen längst nicht alle SAS Controller auch TRIM für SATA Laufwerke und dies solltest Du mal ausprobieren, ich fürchte der LSI kann es nämlich nicht.

Danke für die Belehrung
Gemeint ist low level format / secure erase
Ausgeführt via
hdparm --user-master u --security-erase llformat /dev/sdx

Die SSDs waren alle, bis auf die SSD PLUS 2TB und die MX500 2TB, leer und entsprechend mit security-erase behandelt. Trim wurde über fstrim -av am AMD Controller durchgeführt, ist also für die Ergebnisse nicht erheblich

Ggf. solltest Du also den Test noch einmal wiederholen, nachdem alle SSDs die gleichen Ausgangsbedingungen haben, also entweder komplett leer nach einem Secure Erase oder komplett voll. Denn gerade bei Consumer SSDs macht der Unterschied zwischen leer und (aus Sicht des Controllers) voll eine Menge aus und wenn Du da alles mit 00 überschrieben hast, dann ist die SSD für den Controller komplett mit gültigen Daten gefüllt und dies ist der Worst Case.

Kannst du ja gerne machen.

Die SSDs wurden alle (Ausnahme SSD Plus 2TB und MX500 2TB, welche aber eh nicht gezeigt werden) unter identischen Ausgangsbedingungen getestet.

 

[Holt]

Möglich, müsste man aber in einem nicht ganz trivialen Versuch bei der MX500 eruieren.

Ob die SSDs sync richtig implementiert haben, erkennt man einfach unter Windows mit dem

Gemeint ist low level format / secure erase
Ausgeführt via
hdparm --user-master u --security-erase llformat /dev/sdx

Das war dann ein Secure Erase und hat nichts mit einem Low-Level Format zu tun.

die MX500 2TB

2TB? In der Liste steht sie als 500GB:

Crucial MX500 500GB

Für eine 2TB sind die 30GB natürlich viel weniger als für eine 500GB und schon die MX500 (zumindest die der ersten Serie) kann als 1TB bis zu 60GB in den Pseudo-SLC Schreibcache schreiben.

Kannst du ja gerne machen.

Wie soll ich das machen, ohne die Hardware zu haben?

 

[java4ever]

Ob die SSDs sync richtig implementiert haben, erkennt man einfach unter Windows mit dem

...mit dem?

Ob die SSDs sync richtig implementiert haben, erkennt man einfach unter Windows mit dem
Das war dann ein Secure Erase und hat nichts mit einem Low-Level Format zu tun.

Genug geklugscheißert für heute?

2TB? In der Liste steht sie als 500GB:

• (Begrenzt Sandisk SSD PLUS 2TB)
• (Begrenzt Crucial MX500 2TB)

Die SSDs wurden alle (Ausnahme SSD Plus 2TB und MX500 2TB, welche aber eh nicht gezeigt werden) unter identischen Ausgangsbedingungen getestet.

Wie soll ich das machen, ohne die Hardware zu haben?

Das letzte Mal als ich nachgeschaut habe gabs den Kram käuflich zu erwerben.

 

[Holt]

...mit dem?

Sorry, da habe ich wohl den wichtigsten Teil wieder gelöscht. Es geht mit dem AS-SSD Benchmark, einmal mit aktivem Schreibcache und einmal ohne, also indem man auf dem hier sichtbaren Bild beide Haken entfernt, bei einem Systemlaufwerk muss man dann rebooten. Die 4k Schreibend gehen dann von so 100MB/s auf einstellige MB/s Werte runter, wenn der Schreibcache korrekt implementiert ist oder bleiben praktisch unverändert, wenn das sync einfach ignoriert wird.