MX500 und EVO 970 halten sich nicht an die Spezifikationen. Ist das normal ?

Alaerock

Mitglied
Mitglied seit
Sep 11, 2020
Beiträge
21
Bewertungspunkte
5
Punkte
3
Hallo Zusammen, ich habe einen Rätsel was ich nicht kapiere, entweder sind die SSD Hersteller Betrüger oder irgendwas stimmt nicht in meinem System:
Ich nutze 2 SSD eine NVMe 970 EVO 500GB für das System im dualboot Windoof + linux mint, wobei windoof nur zum zocken oder die Firmware von SSD's zu aktualisieren.

Nun zum Rätsel, ich wollte in meinem Auto die NAVI-Karte updaten mit einem 7Zip Datei von 15 GB, und dabei wollte ich testen ob die SSD's wirklich halten was die versprechen. Ich habe 3 Tests gemacht in dem die 7zip (15 GB) Datei hin und her kopieren und zwischen die SSD's:

Test 1) eine einfache Kopie auf die selbe NVMe 970, und dabei startet das kopieren sehr schnell über 2 GB/s und dann nach 5 Sekunden (gefühlt), fehlt der Wert drastisch sogar bis zu 143 MB/s. Ich dachte ich lese nicht richtig, dies habe ich mehr fach ausprobiert unter Windoof und linux gleiches Ergebnis. WAS SOLL DAS ?

samsung evo 970 test.png

Test 2) gleicher Test mit der MX500, auf beide OS's ebenfalls fängt das kopieren mit fast 500MB/s und dann wieder nur noch die Hälfte nach 5 Sekunden. Das ist echt enttäuschend. wozu gibt man soviel Geld aus


crucial copy test.png

Test 3) Dieses mal Kopie von MX500 zum EVO 970, da ist der wert fast stabil geblieben auf 482 MB/s

crucial to samsung 970 evo.png


Alle SSD's haben 10% freier nicht genutzter Speicher für die Controllers, 54 GB für die EVO und 105 GB für die MX500

Das ganze wird genutzt in:
- MSI MPG x570 Gaming edge wifi (letzter Bios)
- Ryzen 3600
- GTX 1080
- RAM 32GB 3200 MHZ
- 500GB EVO 970 - dualboot
- MX500 1TB
- kein OC

Ich bedanke mich schon mal für euren Input, ich bin sehr gespannt.
 
Was Du da erzeugst ist gemischte Lese- und Schreiblast, das zwingt die Dinger deutlich flotter in die Knie als nur eines von beiden und letzteres ist die Basis für die Angaben. Diese Werte erreichst Du also nur, wenn Du ZWEI Datenträger benutzt, also von A nach B kopierst. Und das ist auch ganz normal, kein Grund zur Panik.

Willst Du da mehr, musst du deutlich tiefer in die Tasche greifen und kommst eher in Enterprise-Gefilde oder gar zu Intels Optanes... die blenden nicht so mit theoretischen Maximalwerten sind dafür aber fast nicht kleinzukriegen (performancemäßig/ IOPS).
 
Was Du da erzeugst ist gemischte Lese- und Schreiblast, das zwingt die Dinger deutlich flotter in die Knie als nur eines von beiden und letzteres ist die Basis für die Angaben. Diese Werte erreichst Du also nur, wenn Du ZWEI Datenträger benutzt, also von A nach B kopierst. Und das ist auch ganz normal, kein Grund zur Panik.

Willst Du da mehr, musst du deutlich tiefer in die Tasche greifen und kommst eher in Enterprise-Gefilde oder gar zu Intels Optanes... die blenden nicht so mit theoretischen Maximalwerten sind dafür aber fast nicht kleinzukriegen (performancemäßig/ IOPS).
Lese- und Schreiblast habe ich nicht daran gedacht. Das erkärt das verhalten. Allerdings dass die Performance so drastisch in die Knie geht, hat mich echt überrascht, vor allem bei dem EVO, von über 2 GB/s auf nur noch 143 MB/s, sogar schlechter als die mx500.
Ich werde auf jedefall in die Zukunft darauf achten was ich kaufe. Vielen Dank @Besterino für die Aufklärung.
 
Zuletzt bearbeitet :
Solche SSDs haben jeweils einen Cache-Speicher. Bei der EVO 970 sind das 512 MB, also 1/2 GB und bei der MX 500 sind es 1 GB. Diesen Speicher verwendet die SSD als Datenpuffer bei Schreib und Lesezyklen, als Speicher für häufig benutzte Dateien, für das Verzeichnis und für Verwaltungsaufgaben. Wie das genau gehandhabt wird, ist je nach Hersteller unterschiedlich.
Fangen wir mal mit Beispiel 3 an. Du gibst den Befehl, eine Datei von einer SSD zur anderen zu kopieren. Die MX500 holt einen Teil der Datei in ihren Cache. Von dort werden die Daten Packetweise über den SATA-Port und die PCIe-Lanes zu zur 970 transportiert, die Packete zuerst in ihren Cache ablegt. Von dort schreibt sie die Daten auf die SSD. Da hier alles in einer Reihe verläuft, geht es ungefähr so schnell, wie das lngsamste Bauteil schafft. Die MX 500 und der SATA-Port schaffen maximal 550 MB/s. Mit etwas Verwaltungsaufwand und möglicherweise noch anderem Datenverkehr passen die gemessenen 482 MB/s dann ganz gut. Effektiv ist es meist etwas weniger als im Idealfall.
Beispiel 2: Hier liest die MX 500 zuerst von der SSD und schreibt die Daten in ihren Cache. Das geht sehr schnell, bis der Cache gefüllt ist. Ab da muss der Controller erst wieder Daten an den neuen Platz auf der SSD schreiben um wieder Platz im Cache zu schaffen. Da er nun abwechselnd liest und schreibt halbiert sich die Datenrate ungefähr und der Verwaltungsaufwand wird grösser. Das passt mit dem Absinken auf 217 MB/s eigentlich ganz gut.
Beispiel 1: Hm, nun wird es schwierig zu sagen, was da abläuft. Am Anfang läuft es ja sehr gut, wie es den Werten der SSD entspricht. Der Cache ist sehr schnell voll, aber da fällt die Leistung ja noch nicht ab. Ich kann mir vorstellen, dass die SSD mit Verwalten des Speichers da zeitweise etwas überfordert ist und erst wieder Ordnung schaffen muss. Wie viel Platz hast du auf den einzelnen Partitions der SSD noch frei. Hast du da schon sehr viel geschrieben und wieder gelöscht, so dass viele kleine Bereiche entstanden sind, die er nun voll geschrieben hat? Je stärker die SSD gefüllt ist, um so grösser wird der Verwaltungsaufwand. Vor allem die Partition, auf die du schreibst, sollte nicht mehr als 90% belegt sein.
 
Mal mit CrystalDiskMark testen.

Würde die ZIP-Version - keine Installation - herunterladen, entpacken und ausführen.

CrystalDiskMark7_0_0h.zip SHA256 1d7429ab50072dc0ae4a418125012ce18b0fdcf11a29871f7f9f806a5dcc215b > VirusTotal

CrystalDiskMark7_0_0hShizuku.zip SHA256 24f8c1146818e032fdd2363e9f578654854d2bcb10633e14d5879453d1d49a4d > VirusTotal
Danke für den Tipp, allerdings mir ging um meine Bedürfnisse. Sprich große Menge an Dateien innerhalb die selbe Platte zu kopieren wie Backups. Obwohl ich immer ZIP Dateien genutzt hatte, hatte ich mich gewundert warum es immer so lange dauert. Aber dank @Besterino habe ich verstanden worauf ich achten soll.
Die "Patriot Viper VPP4100" scheint mir ganz gut zu sein für die angebotene Performance. IOPS 800k ziemlich gut im Vergleich zu meine IOPS 450k:
https://geizhals.de/patriot-viper-vp4100-nvme-ssd-1tb-vp4100-1tbm28h-a2138062.html?hloc=at&hloc=de
 
Ein Backup gehört immer auf eine andere Festplatte, am besten eine externe, sonst sind bei einem Ausfall ja beide Versionen weg. Dazu nutzt es eine SSD unnötig ab. (auch wenn man die EVO 970 nicht so schnell 600 mal voll geschrieben hat)
 
Solche SSDs haben jeweils einen Cache-Speicher. Bei der EVO 970 sind das 512 MB, also 1/2 GB und bei der MX 500 sind es 1 GB. Diesen Speicher verwendet die SSD als Datenpuffer bei Schreib und Lesezyklen, als Speicher für häufig benutzte Dateien, für das Verzeichnis und für Verwaltungsaufgaben. Wie das genau gehandhabt wird, ist je nach Hersteller unterschiedlich.
Fangen wir mal mit Beispiel 3 an. Du gibst den Befehl, eine Datei von einer SSD zur anderen zu kopieren. Die MX500 holt einen Teil der Datei in ihren Cache. Von dort werden die Daten Packetweise über den SATA-Port und die PCIe-Lanes zu zur 970 transportiert, die Packete zuerst in ihren Cache ablegt. Von dort schreibt sie die Daten auf die SSD. Da hier alles in einer Reihe verläuft, geht es ungefähr so schnell, wie das lngsamste Bauteil schafft. Die MX 500 und der SATA-Port schaffen maximal 550 MB/s. Mit etwas Verwaltungsaufwand und möglicherweise noch anderem Datenverkehr passen die gemessenen 482 MB/s dann ganz gut. Effektiv ist es meist etwas weniger als im Idealfall.
Beispiel 2: Hier liest die MX 500 zuerst von der SSD und schreibt die Daten in ihren Cache. Das geht sehr schnell, bis der Cache gefüllt ist. Ab da muss der Controller erst wieder Daten an den neuen Platz auf der SSD schreiben um wieder Platz im Cache zu schaffen. Da er nun abwechselnd liest und schreibt halbiert sich die Datenrate ungefähr und der Verwaltungsaufwand wird grösser. Das passt mit dem Absinken auf 217 MB/s eigentlich ganz gut.
Beispiel 1: Hm, nun wird es schwierig zu sagen, was da abläuft. Am Anfang läuft es ja sehr gut, wie es den Werten der SSD entspricht. Der Cache ist sehr schnell voll, aber da fällt die Leistung ja noch nicht ab. Ich kann mir vorstellen, dass die SSD mit Verwalten des Speichers da zeitweise etwas überfordert ist und erst wieder Ordnung schaffen muss. Wie viel Platz hast du auf den einzelnen Partitions der SSD noch frei. Hast du da schon sehr viel geschrieben und wieder gelöscht, so dass viele kleine Bereiche entstanden sind, die er nun voll geschrieben hat? Je stärker die SSD gefüllt ist, um so grösser wird der Verwaltungsaufwand. Vor allem die Partition, auf die du schreibst, sollte nicht mehr als 90% belegt sein.
Super erklärt, und alles was du gesagt hast ist plausible. Für die Beispielen 2 und 3 passen dann wirklich die Werte mit dem Verhalten.
Bei Beispiel 1, Platz ist genug 54 GB sind unpartitioniert extra gelassen für die Performance der Platte, und die genutzte Partitionen haben fast die Hälfte frei.
Ob es daran liegt dass sehr viel auf die Platte geschrieben und gelöscht wird täglich, das wäre eine Erklärung, da ich als Software Entwickler, kann pro Tag mehrere 10 000 Datein entstehen lassen und wieder löschen Aber ich dachte das häufige trim einer Platte sollte in so einen Fall helfen und dazu lassen ich alle Schreib intesive Programmen, wie firefox nur im RAM laufen.
 
Zuletzt bearbeitet :
Ein Backup gehört immer auf eine andere Festplatte, am besten eine externe, sonst sind bei einem Ausfall ja beide Versionen weg. Dazu nutzt es eine SSD unnötig ab. (auch wenn man die EVO 970 nicht so schnell 600 mal voll geschrieben hat)
Du hast Recht, aber ich wollte nicht zu sehr ins Detail gehen. Die Backups werden von IDE's automatisch erstellt so ein art von GIT nur halt local, um jeder Zeit zu eine Local nicht gespeicherte Kopie des Codes zu zugreifen. Sollte die Platte sich verabischen, dann ist das kein Problem. Die richtigen Backups laufen dann auf die MX500 und dazu noch eine externe HDD Platte.
Danke für den Hinweis
 
Es kann sein, dass die SSD grössere Aufräumaktionen im Verzeichnis etwas vor sich hin schiebt und dann gelegentlich, wenn wenig läuft angeht. Wenn dann unerwartet eine so grosse Datei daher kommt, muss die SSD sich dann doch ans Aufräumen machen, weil sonst nicht mehr genug Platz zu finden wäre. Eine Datei wird am Anfang ja nur dadurch gelöscht, dass der Eintrag im Verzeichnis unkenntlich gemacht wird und der Speicherbereich als nicht mehr reserviert markiert wird. Wenn der Platz gebraucht wird, muss sich der Controller erst mal durch das Verzeichnis wühlen und die leeren Bereiche zusammen sammeln.
Wie gesagt, genau kann ich es nicht sehen, was der 970 so zu schaffen macht. Aber wenn du so viel Dateien schaufelst, kann ich mir schon denken, dass SSD etwas Mühe damit hat.
 
Was Du da erzeugst ist gemischte Lese- und Schreiblast, das zwingt die Dinger deutlich flotter in die Knie als nur eines von beiden und letzteres ist die Basis für die Angaben. Diese Werte erreichst Du also nur, wenn Du ZWEI Datenträger benutzt, also von A nach B kopierst. Und das ist auch ganz normal, kein Grund zur Panik.
Für SATA-Laufwerke richtig, für NVMe nicht, da PCIe bi-direktional läuft. Das auf der 970 EVO nicht schneller kopiert wird hat vermutlich mehr mit Windows File Copy zu tun, und damit das Windows im Hintergrund noch andere Zugriffe auf die Platte organisiert, die das kopieren dann ausbremsen. Oder vielleicht auch damit das die Platte relativ voll ist, und dadurch das Organisieren für den Controller zunehmend kompliziert wird.
Wer sich eine leere 970 EVO zusätzlich zur OS-Platte einbaut und als erstes den gleichen Filecopy-Test macht, wird wesentlich mehr Leistung zu Gesicht bekommen. Zumal 15GB noch gut in den SLC-Cache passen.
 
Für SATA-Laufwerke richtig, für NVMe nicht, da PCIe bi-direktional läuft. Das auf der 970 EVO nicht schneller kopiert wird hat vermutlich mehr mit Windows File Copy zu tun, und damit das Windows im Hintergrund noch andere Zugriffe auf die Platte organisiert, die das kopieren dann ausbremsen. Oder vielleicht auch damit das die Platte relativ voll ist, und dadurch das Organisieren für den Controller zunehmend kompliziert wird.
Wer sich eine leere 970 EVO zusätzlich zur OS-Platte einbaut und als erstes den gleichen Filecopy-Test macht, wird wesentlich mehr Leistung zu Gesicht bekommen. Zumal 15GB noch gut in den SLC-Cache passen.
Das NVMe Test habe ich unter Linux Mint als erstes durchgeführt, was ich hauptsächlich nutze, und dann mit Windows um zu vergleichen.
Windows bietet schönere Kopier-Diagramm deshalb habe ich dessen Screenshots genutzt. Ich hab's nochmal getestet unter Linux und du hast da auch Recht, windows hatte irgendwas damit zu tun, das schlechteste Wert ist nun unter linux 609MB/s statt 143 MB/s unter Windows (noch eine bestätigung warum ich windows ungern nutze).

1600553239636.png
 
Der DRAM-Cache bei SSDs ist kein Datenpuffer für Nutzdaten sondern nur für die Mappingtabelle der Speicherzellen.
Wieviel freier Speicher ist auf den Laufwerken jeweils vorhanden? Je weniger desto kleiner der ultraschnelle SLC-Cache (das ist der Schreibcache, sitzt aber im Flashbereich)
 
Der DRAM-Cache bei SSDs ist kein Datenpuffer für Nutzdaten sondern nur für die Mappingtabelle der Speicherzellen.
Wieviel freier Speicher ist auf den Laufwerken jeweils vorhanden? Je weniger desto kleiner der ultraschnelle SLC-Cache (das ist der Schreibcache, sitzt aber im Flashbereich)
Es ist definitiv genung Speicher vorhanden fast die Hälfte plus 54GB unpartitioniert.
 
@ShieTar Das ist nicht nur ein SATA-Phänomen. Auch bei NVMe-Drives geht gerne der Controller auf der SSD in die Knie... bei den Drives limitiert bei größeren bzw. gleichzeitigen Datenbewegungen FAST NIE der PCIe-Bus, sondern Controller/Zellen/Cache. Wäre sonst ja auch zu einfach und sieht man ja z.B. schon bei vielen kleinen Dateien statt einer großen... Diese Werte sind einfach Humbug bzw. Augenwischerei, helfen bei der Werbung aber haben schlicht nichts mit echten Lasten zu tun. Deshalb packt ja auch keiner mit Verstand die Consumer-Dinger in irgendwelche Kisten, die WIRKLICH IO-Last erzeugen (Datenbanken, VM-Speicher etc.).

Drum nutze ich für manche Netzwerk-Speedtests schlicht RAM-disks um das Storage-Bottleneck zu vermeiden - da ist bisweilen selbst mein Raid0 aus 4 NVMe zu lahm und außerdem hab ich davon nur eins... ;)

Nachtrag @Alaerock: für das was Du da machst, solltest Du Dich mal nach einem Filesystem mit Versionierung & Snapshots umschauen. ;) Empfehle schönes zentrales Storage mit ZFS. Das löst eigentlich alle deine Probleme. :D
 
Zuletzt bearbeitet :
Der DRAM-Cache bei SSDs ist kein Datenpuffer für Nutzdaten sondern nur für die Mappingtabelle der Speicherzellen.
Wieviel freier Speicher ist auf den Laufwerken jeweils vorhanden? Je weniger desto kleiner der ultraschnelle SLC-Cache (das ist der Schreibcache, sitzt aber im Flashbereich)
Da hast du recht. Als SLC-Cache wird der selbe Speicher genutzt, aber weniger dicht beschrieben. Dadurch ist er schneller. Ich habe mich noch nie so genau damit befasst. Es gibt eben immer noch etwas zu lernen.
Wenn mit der schnellen, platzfressenen Schreibmethode der Bereich voll wird, den der Controller dafür vorgesehen hat, dann kann er nur noch die langsame verdichtete Schreibweise nutzen und muss möglicherwiese auch erst unverdichtete Bereiche verdichten um Platz zu schaffen. Das kann natürlich zu massiven Einbrüchen bei der Leistung führen. Solange man nicht so grosse Datenmengen kopiert, ist natürlich alles kein Problem und die SSD ist schön flink. Wenn die Möglichkeiten ausgeschöpft sind kann es aber langsamer werden als man erwartet.
 
würde mich mal interessieren, ob der unpartitionierte Teil (54GB) überhaupt als Cache für die SSD nutzbar ist

Die SSDs haben alle die aktuelle Firmware drauf?
 
würde mich mal interessieren, ob der unpartitionierte Teil (54GB) überhaupt als Cache für die SSD nutzbar ist

Die SSDs haben alle die aktuelle Firmware drauf?

Ich betreibe einen Dualboot hauptsächllich um die SSD's Firmware aktuell zu halten und ab und an zu zocken.
Laut Magician ist das OP(Over Provisioning) wird genutzt Bild aktuel vonn heute 39GB + 10 GB, unter linux sieht mann aber 54 GB, keiner Ahnung warum die 5 GB nicht zu sehen hier sind.

OP_evo_970.png

Hier ist das Laufwerkszuteilen aus Linux Sicht:

1600673444534.png
43 + 11 Freier Platz wird genutzt für das over provisioning
 
Zuletzt bearbeitet :
Der SLC Cache bei der 500GB M.2 ist zwischen 4 und 22GB. Erweitere mal die Partition mit der du kopierst um die 54GB und teste nochmal. Ich vermute, dass du nur den minimalen SLC Cache von 4GB bei deinen Tests nutzt.
 
Die Unterschiede der angezeigten Partitionsgrößen erklären sich weil Windows immer noch binäre Einheiten verwendet, aber dezimale Einheiten-Namen anzeigt. Die Partitionen sind eigentlich 39 GiBi = 39*2^30 Byte und 10 GiBi = 10*2^30 Byte groß. Unter Linux werden die dezimalen Einheiten korrekt verwendet (43*10^9 und 11*10^9).
 
Oben Unten