Test Samsung SSD 970 Evo Plus im Test: V-NAND mit 96 Lagen für ein + an Leistung

Vermutlich. Ein offizielles Changelog gibt es wohl nicht.
 
Korrekt, ein Changelog gibt es schon seit einige Zeit nicht mehr bei Samsung. Es gilt aber wie immer wenn man keine Probleme hat sollte man nicht updaten.
 
Gut, dann werd ich mal updaten. Danke.
 
Ich habe die Evo 970 Pro 1 Tb heute in meinem Rechner verbaut. ( I78700K Asus Maximus X 16 Gb Ram) Leider erhalte ich bei Geschwindigkeitstests nur 1700 Mb im Lesen und im Schreiben, Weiß jemand woran es liegen könnte? Die Evo ist im zweiten Steckplatz des Mainboards verbaut.

Lg
 
  • Gefällt mir
Reaktionen: Solid1984 und MichaG
Danke für die Antwort. Habe sie jetzt auf den ersten Slot gebaut. ( War aufgrund des Kühler ein wenig schwerer)
Jetzt habe ich die volle Datenrate.

Gruß
 
  • Gefällt mir
Reaktionen: MichaG
@Hallo32 Sage mal, was ist mit dem Nachreichen der PCMark 8 Tests?
 
Hi,
eine Samsung 970 evo oder evo plus NVMe soll auf dem Board-seitigen M.2-Steckplatz (non-shared, 4 Lanes, PCEx 3.0 x4) eines Asus Z270 Tuf Mk 2 verbaut werden. Lt. Herstellerangaben sind da 3400 MB/S lesend / 2400 MB/S schreibend drin, in der Praxis sicher darunter. Die Hardware liegt seit Monaten komplett bereit, nun soll sie endlich mal verbaut werden (Win10pro, i7 7700, 16 GB Ram etc.).

Ein Kollege will mir seit Tagen erzählen, dass diese Raten praktisch gar nicht möglich sind (also deutlich darunter liegen sollen). Lt. diverser Tests in den online Gazetten geht es unter den eingangs genannten Voraussetzungen (1. Satz) aber in die Richtung, falls ich die richtig lese, solange nicht große bis sehr große 4K-Dateien gelesen oder geschrieben werden.

Nun zur Frage, hat jemand von Euch in seinem eigenen praktischen Betrieb die o.g. Raten selber mal erreicht, bzw. wie sind Eure Erfahrungen beim Prüfen der Schreib/Leseraten der 970 evo oder meinetwegen auch 970 evo plus?

Bleibt gesund & thx im Voraus!

PS: Falls ich hier ganz falsch bin, gebt mir bitte einen Hinweis.
 
Zuletzt bearbeitet:
@noZmo Die Antwort ist wie so oft: Kommt drauf an. Fakt ist: Die Samsung SSDs sind mit das Beste was es im Consumer Markt gibt. Ja natürlich im 4K Bereich sind die Raten niedriger, ja natürlich haben die Spectre Patches ihren Tribut gefordert. Aber: was wäre die Alternative? Bau das Ding ein, sei happy :-)
 
@DFFVB: Mach ich :-) Alternativen zur m.2 970 evo sehe ich tatsächlich derzeit auch nicht (auch die aktuellere plus-Version muss es nicht sein, weil die 970er evo im Haus ist). Selbst für den Vorgänger m.2 960er evo findet sich ein Einsatz. Anschließend kann der (nachhaltig genutzte) Veteran der Signatur nach knapp 8 Jahren (!) auch in den wohlverdienten Ruhestand ...
 
Zuletzt bearbeitet:
noZmo schrieb:
Lt. Herstellerangaben sind da 3400 MB/S lesend / 2400 MB/S schreibend drin, in der Praxis sicher darunter.
Weil man eben eine menge langer und paralleler Zugriffe braucht um auf diese hohen Transferraten zu kommen, was aber für fast alle NVMe SSDs gilt. Ausnahmen sind nur die Intel Optane und Samsung Z-SSDs deren Medien eine viel geringere Latenz als normale NANDs aufweisen.
 
Warum steht im HD Tach Screenshot eigentlich "Sequential Read Speed", obwohl das ein Schreibtest ist?

EDIT: Ich habe selbst mal einen Versuch mit HD Tach unternommen und weiß jetzt warum. Dort steht einfach immer "Read Speed", auch wenn parallel der Write Test erfolgt.

Allerdings sind die Werte echt gar nicht zu gebrauchen. Scheint wohl unter Windows 10 nicht zu laufen:
2020-09-27 13_47_09.png


Ich habe es dann mal mit HD Tune "File Benchmark" und "50GB" versucht. Schon deutlich besser, wobei die Werte immer noch 15% zu niedrig sind:
2020-09-27 13_40_11.png


CristalDiskMark zeigt dagegen korrekte Werte an:
2020-09-27 13_39_57.png


Ich habe es mal an HD Tune als Bug gemeldet. Vielleicht ändern die ja mal was daran. Kann ja nicht sein, dass es sonst kein aktuelles Tool gibt um den SLC Cache zu füllen und die durchgehende Übertragungsrate zu ermitteln.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: DFFVB
mgutt schrieb:
Ich habe selbst mal einen Versuch mit HD Tach unternommen
Das ist kein Bug und Low-Level Benchmarks wie HD Tune sind für SSDs ungeeignet, da die Controller sowas wie ein Schattenfilesystem führen, die schrieben ja die Daten über die NAND Pages so verteilt, dass sie parallel sind um eine maximalen Schrieb- und später dann wieder Leseperformance erreichen. Dies gilt pro Datei, nicht aber zwangsläufig für aufeinanderfolgende LBAs wie Low-Level Benchmarks sie aber eben auslesen. Und wenn einem LBA gar keine gültigen Daten zugewiesen sind, dann kann und braucht der Controller auch keine Daten auf den NANDs zu lesen, welches sollte er auch lesen und liefert normalerweise einfach nur Nullen zurück, was natürlich schneller geht als wirklich Daten zu lesen. Die Low-Level Benchmarks wissen aber gar nicht welche LBAs wirklich belegt sind und dann gibt es entsprechend hohe Leseraten im Benchmark, die gebenchte SSD ist ja nur ungefähr zu Hälfte gefüllt. Nur beim HD Tune "File Benchmark" sollte zumindest letzteres keine Rolle spielen.

Dann kommt noch die Länge und Anzahl der parallelen Zugriffe ins Spiel, diese alten Benchmarks für HDDs benchen oft nur alle paar MB einen Bereich über 64k, so war es zumindest lange die Defaulteinstellung bei HD Tune. SSDs erreichen bei so kurzen Zugriffen aber noch lange nicht ihren vollen Leseraten, bei 4k QD1 sind es bei Deiner hier ja nur 58.42MB/s und selbst bei einem Zugriff über 1MB (SEQ1M Q1T1) sind es mit 2495,55MB/s noch immer um über 1000MB/s weniger als bei 8 parallelen Zugriffen über 1MB.
mgutt schrieb:
Ich habe es mal an HD Tune als Bug gemeldet.
Vergiss einfach Tools wie HD Tune und HD Tach für SSDs, die Reviews nutzten HD Tach ja in aller Regel auch nur um die Größe des Pseudo-SLC Caches zu ermitteln, eben um den Einbruch der Schreibraten beim sequentiellen Schreiben zu ermitteln.

Wenn Du reale erreicht werden bei den tatsächlich auftretenden Zugriffen sehen willst, dann nimm mal HWInfo64 und schau dort bei Sensors was für Durchschnittswerte über 1s wirklich erreicht werden.
 
Holt schrieb:
Und wenn einem LBA gar keine gültigen Daten zugewiesen sind, dann kann und braucht der Controller auch keine Daten auf den NANDs zu lesen, welches sollte er auch lesen und liefert normalerweise einfach nur Nullen zurück
Das erklärt bei HD Tach die Schwankungen (eigentlich nicht, da die SSD nicht mal halb voll ist = die Transferspitzen müssten ja förmlich "explodieren"), aber die Werte sind trotzdem viel zu klein. Testgröße war angeblich 32MB. Sollte ja eigentlich reichen um ordentlich zu messen.

Bei HD Tune trifft das Argument aber eh nicht zu, weil der ja wirklich eine 50GB Datei schreibt und diese dann wieder vollständig ausliest (passt auch von der Zeit). Wie groß die Blöcke sind, kann ich nicht sagen. Ist leider nicht einstell- bzw einsehbar. Ich habe bei HD Tune auch mal mit Random-Fill probiert. Macht aber keinen wirklichen Unterschied von wegen, dass der Controller leere Bereiche skipped und dann schneller antwortet:
2020-09-27 18_18_47.png


Vermutlich ist, wie du sagst, die zu kleine Blockgröße bzw fehlenden parallelen Zugriffe das Problem. Testen wir es einfach mal mit CrystalDiskMark und erhöhen die Blockgröße auf 2 bzw 8MB:
2020-09-27 18_27_43.png


Daraus kann man fast ableiten, dass HD Tune ähnlich große Blöcke verwendet. Leider kann man HD Tune nicht 2x parallel starten, weil die Testdatei immer den gleichen Namen hat ^^

Holt schrieb:
die Reviews nutzten HD Tach ja in aller Regel auch nur um die Größe des Pseudo-SLC Caches zu ermitteln, eben um den Einbruch der Schreibraten beim sequentiellen Schreiben zu ermitteln.
Mehr wollte ich auch nicht wissen. Nur was bringt es was mit HD Tach zu testen, wenn man der Anwendung nicht vertrauen kann. Dann kann man auch einfach nur schreiben "Ja xxGB SLC Cache stimmt" und das Diagramm lieber weglassen. Bei der 970 Evo / Evo Plus sieht der Wert zB noch richtig aus, aber bei der 970 Pro sollen angeblich nur 1500 MB/s möglich sein (lesen und schreiben). Mag ja sein, dass die Werte von HD Tune nicht absolut passen, aber sie sind zumindest deutlich näher an der Realität.
 
mgutt schrieb:
Das erklärt bei HD Tach die Schwankungen (eigentlich nicht, da die SSD nicht mal halb voll ist = die Transferspitzen müssten ja förmlich "explodieren")
Explodieren scheint hier nur bis 1800MB/s zu gehen und dann ist da noch das Schattenfilesystem, also die Verteilung der Daten die den jeweils aufeinanderfolgenden LBAs zugeordnet sind, über die NAND Dies. Stehen die Daten auf dem gleichen NAND Die, müssen sie nacheinander gelesen werden.
mgutt schrieb:
Testgröße war angeblich 32MB. Sollte ja eigentlich reichen um ordentlich zu messen.
Selbst AS-SSD kann mit seinen 16MB langen Zugriffen aus solche SSDs lange nicht die vollen Leseraten kitzeln und dann ist noch die Frage ob damit wirklich die Länge pro Zugriff gemeint ist und ob die wirklich so bei der SSD ankommt und nicht die Zugriffe irgendwo im System aufgeteilt werden.
mgutt schrieb:
Nur was bringt es was mit HD Tach zu testen, wenn man der Anwendung nicht vertrauen kann.
Weil es nicht wirklich um die Werte auf der Y Achse geht, sondern darum zu sehen wie viele GB geschrieben werden können bis die Schreiberate einbricht.
mgutt schrieb:
Dann kann man auch einfach nur schreiben "Ja xxGB SLC Cache stimmt" und das Diagramm lieber weglassen.
Könnte man auch machen, aber ich bevorzuge es immer wenn Reviewer auch die Screenshots veröffentlichen aus denen sie ihre Informationen ableiten.
mgutt schrieb:
bei der 970 Pro sollen angeblich nur 1500 MB/s möglich sein (lesen und schreiben). Mag ja sein, dass die Werte von HD Tune nicht absolut passen, aber sie sind zumindest deutlich näher an der Realität.
Was für eine Realität? Es gibt nicht eine Realität, sondern unendlich viele, eben je nachdem wie die Zugriffe sind, also über wie viele Daten zu ein Zugriffe geht, hast du ja selbst durch Änderung der Einstellung in CDM von 1MB auf 2MB und 8MB gesehen und wie viele parallele Zugriffe tatsächlich erfolgen. Daher kann kein Benchmark für sich in Anspruch nehmen "die Realität" abzubilden, dies geht einfach nicht und die Benchmarks können bestenfalls immer nur die Transferraten für die Realität anzeigen die sie mit ihren Zugriffen selbst erzeugen. Wer mehr erwartet, muss zwangsweise enttäuscht werden!
 
Bei HD Tach ging es um die Visualisierung der Datenrate beim vollständigen Beschreiben der SSD und die Darstellung der Größe des SLC Caches.
 
Eben und dazu ist es egal ob HD Tach nun vor dem Einbruch 20s lang 3000MB/s oder 30s lang 2000MB/s schnell schreiben kann, auch wenn die SSD im Pseudo-SLC Cache maximal 4000MB/s schreiben kann.
 
@Holt

Nö, nicht ganz. Denn bei der 1TB Evo Plus wäre das auf Grund der 64KB Blocksize bei HDTach wahrscheinlich gar nicht aufgefallen, oder zb bei der 980 Pro.
Nur weil die 500GB Evo bzw Evo Plus so langsam ist bei der Schreibrate nach dem SLC Cache konnte man das hier aufzeigen.

In HD Tune Pro kann man zumindest auch beim Low Level Benchmark die Blocksize einstellen, und daher das bestimmt besser aufzeigen.

https://www.guru3d.com/articles-pages/samsung-970-evo-plus-nvme-m-2-(1tb)-ssd-review,18.html
(EDIT: Ok, hier kann zusätzlich hinzukommen, dass Guru3D wohl nur den 32MB Zone Test durchgeführt hat. Nur bei der Vollversion von HD Tach RW kann man wohl den Full Test ausführen)
1601263796970.png

https://www.guru3d.com/articles_pages/samsung_980_pro_1tb_nvme_ssd_review,16.html
1601263843168.png


Hier zb mit HD Tune Pro
http://www.cdrlabs.com/reviews/sams...ate-drive/performance-as-ssd-and-hd-tune.html
1601264124504.png


Natürlich muss man den "Benchmark" auch erst richtig einstellen, denn default ist dort auch nur 64KB Blocksize. Beim "File Benchmark" wäre das egal
https://hothardware.com/reviews/samsung-ssd-980-pro-nvme-pcie-4-review
1601264274870.png
 
Zuletzt bearbeitet:
VelleX schrieb:
Denn bei der 1TB Evo Plus wäre das auf Grund der 64KB Blocksize bei HDTach wahrscheinlich gar nicht aufgefallen
Wenn der Anfall der Schreibrate nicht auffällt, dann taugt HD Tach natürlich nicht für den Test. Generell sind HD Tune und HD Tach nicht die Benchmarks der Wahl für SSDs und die Schreib- / Leseraten die damit ermittelt werden, wenig relavant.
 
Zurück
Oben