NVME SDD Schreibrate sehr niedrig

Blaze1987

Lieutenant
Registriert
Sep. 2008
Beiträge
997
NVME Solid State Disk Schreibrate sehr niedrig

Hallo zusammen,

bei meinem DELL XPS 15 verwundert mich die AS SSD sequentielle Schreibrate.

Eigentlich sollte diese weitaus höher liegen.


Im Bios ist der RAID Modus aktiviert, da dies die Vorgabe von DELL ist für die NVME PCIe SSD (dies war auch im Auslieferungszustand so).


Der Intel Raid Treiber wurde während der sauberen Installation im Setup hinzugefügt.

Die SSD wurde in drei Bereiche partioniert. An sich besitzt die SDD GPT Table.


Hier ein paar Infoscreens:

SDD Bench .jpgToshiba NVME THNSN5512GPU7 NV.jpgIntel RST Status.jpgIntel Raid Treiber.jpg


Hat einer eine Idee?

- Eventuell den Intel RST Treiber deinstallieren?
- Partionierung schuld?
- Firmware der Toshiba schuld?


Danke euch & LG
 
Zuletzt bearbeitet: (Rechtschreibfehler da T9)
Die Partitionierung kann es nicht sein. Schaut aus wie ein Firmware oder Treiber Problem, vielleicht ein Bug. Falls du jeweils die neuste Firmware & Treiber Version hast, versuch mal ein downgrade, wenn es möglich ist.
 
Klar kann es die Partitionierung sein.
Durch das Partitionieren teilst du ja den Speicher in "pyhsikalisch" abgetrennte Bereiche.
Das ist bei eines SSD absoluter Nonsens

Eine SSD verwendet beim Lesen und Schrieben gleichzeitig mehrere ihrer Speicherchips, um die Geschindigkeit zu erhöhen.
Sie macht intern sowas sie RAID 0.
Wenn jetzt eine Partition auf z.B. 2 von 8 verfügbaren Chips aufgeteit ist, geht da die Performance verloren.
Außerdem kann hier Wear Leveling auch nicht gescheit funktionieren.

Eigentlich sollte bekannt sein, dass man eine SSD nicht partitioniert.
 
kann es sein das du einen NVMe Treiber noch installieren mußt für das NB?
 
freshprince2002 schrieb:
Eine SSD verwendet beim Lesen und Schrieben gleichzeitig mehrere ihrer Speicherchips, um die Geschindigkeit zu erhöhen.
Sie macht intern sowas sie RAID 0.
Wenn jetzt eine Partition auf z.B. 2 von 8 verfügbaren Chips aufgeteit ist, geht da die Performance verloren.
Außerdem kann hier Wear Leveling auch nicht gescheit funktionieren.

Die Aussage passt überhaupt nicht.
Wenn Du Dich auf das interne Raid einer SSD beziehst (die Aufteilung der Schreib- und Lesezugriffe auf mehrere Chips),
dann passiert dies maximal im KB-Bereich (Blockgröße die durch den internen Controller vorgegeben ist), wenn nicht sogar noch darunter.
Die Partitionen sind aber mehrere Gigabyte groß. Ausser falschem Alignment kann da nicht viel passieren.
Nur durch das Alignment kann Performance verloren gehen, nicht durch die Anzahl der Partitionen.

An TE:
Ist die Geschwindigkeit bei C: (Bitlocker) und S: (ohne Bitlocker) identisch?
Welche CPU ist verbaut?
Die Verschlüsselung kann durchaus auch ein Nadelöhr sein, vor allem beim Schreiben.
 
Ich habe mit dem kleineren Dell XPS 13 (2016) bereits mehrere Erfahrungen gemacht, die nicht gerade berauschend sind. Zu Beginn (Dezember/Januar) haben die Geräte nicht wirklich funktioniert. Andauernd kam es zu Abstürzen, Bluescreens und auch die NVMe-SSDs haben Probleme gemacht.

Mittlerweile hat Dell glücklicherweise vieles verbessert und die Geräte laufen nun relativ stabil und zuverlässig. Mein Rat an dich: Aktualisiere das BIOS und sämtliche Firmwares, die angeboten werden. Installiere die neusten Treiber und lade sie von der Dell-Website herunter.
 
Willi-Fi schrieb:
NVMe supportet noch keinen Raid....

Immer die Aussage im Zusammenhang setzen:
1. Das SSD-Interne Raid hat nichts mit dem externen Protokoll zu tun.

2. Man kann problemlos mehrere NVMe-SSDs (auch PCIe3 x4) zu einem bootbaren Raid verbauen. Das NVMe Protokoll wird dann als Layer unterhalb der RSTe-Software/Treiber genutzt.

3. Allein die Anzeige bei z.B. Benchmarktools ändert sich dann von NVMe auf RSTe.
(meine Bootdevice besteht aus zwei Samsumg 950 pro im Raid0, sehe ich gerade vor mir)

4. Da im ersten Bild des TE nicht RSTe angezeigt wird, gehe ich davon aus, dass die SSD auch nativ auf die NVMe-Treiber zugreift und nicht über den RSTe-Umweg.
Die Raid-Einstellung im Bios/UEFI ist für den aktuellen SSD-Betrieb uninteressant.
Ergänzung ()

Und noch ein Hinweis zu Wear Leaveling.

Wear Leveling basiert SSD-Controllerbasiert auf unterster Ebene und wird durch den TRIM-Befehl aktualisiert:
Das Betriebssystem teilt dem Controller mit: Der Block XY wird nicht mehr benötigt, ist frei.
Der Controller markiert dies in einer internen Liste auf LBA-Ebene, sowie in einem Counter auf LBA-Ebene, wie oft dieser Block bereits beschrieben wurde.
Das ganze ist vollkommen partitionsunabhängig.
Freie Blöcke (mit Priorisierung auf dem kleinsten Counter) werden durch Remapping unabhängig von ihrer tatsächlichen Positionierung wiedervergeben. Nur der SSD-interne Controller weiß, wo sich der logische Block physikalisch befindet.
 
Zuletzt bearbeitet:
Auch hier: Reines Benchmark-"Problem" wegen FUA. In der Praxis kein Problem. Wie bei der SM951 auch schon.
Wenn du trotzdem schöne Benchmark Zahlen willst auf Kosten von möglicher Datensicherheit dann deaktiviere das "von Windows veranlasste Leeren des Geräteschreibcaches".


https://www.computerbase.de/2016-05/toshiba-ocz-rd400-test-nvme-ssd/#abschnitt_technik_im_ueberblick
Auch Toshiba und OCZ gehen mit einem eigenen NVMe-Treiber für die RD400-Serie auf Nummer sicher und versprechen dadurch eine höhere Leistung.

Kannst auch mal versuchen den "ocznvme" Treiber zu verwenden.
 
- Treiber Intel NVME: https://downloadcenter.intel.com/download/25771/-Intel-Rapid-Storage-Technology-Enterprise-NVMe-Intel-RSTe-NVMe-RAID-Driver

- Auch auf anderen Partitionen das gleiche Ergebnis (S, D usw.)

- Intel RSTE GUI war halt beim Treiber (NVME) dabei...Also sollte das NVME Protokoll nutzen

- Habe jetzt nochmal die Drive Update Utily von intel genutzt...dort gibt es keinen aktuelleren oder anderen NVME Treiber (https://www-ssl.intel.com/content/www/us/en/support/detect.html).

Bei Dell ist man noch am nachhören, ob Toshiba selbst einen zur Verfügung stellen könnte.
Ergänzung ()

KodeX schrieb:
Ich habe mit dem kleineren Dell XPS 13 (2016) bereits mehrere Erfahrungen gemacht, die nicht gerade berauschend sind. Zu Beginn (Dezember/Januar) haben die Geräte nicht wirklich funktioniert. Andauernd kam es zu Abstürzen, Bluescreens und auch die NVMe-SSDs haben Probleme gemacht.

Mittlerweile hat Dell glücklicherweise vieles verbessert und die Geräte laufen nun relativ stabil und zuverlässig. Mein Rat an dich: Aktualisiere das BIOS und sämtliche Firmwares, die angeboten werden. Installiere die neusten Treiber und lade sie von der Dell-Website herunter.


Schon alles erledigt...

Bis auf den Seq. Write Test habe ich aktuell keine Probleme / Störungen....
Ergänzung ()

Lösung:

Crystal Disk Benchmark statt AS SSD Benchmark!


SDD Bench 2 .jpg
 
Zuletzt bearbeitet: (update)
freshprince2002 schrieb:
Klar kann es die Partitionierung sein.
Durch das Partitionieren teilst du ja den Speicher in "pyhsikalisch" abgetrennte Bereiche.
Das ist bei eines SSD absoluter Nonsens
Nein., was Du da schreibst ist Nonsens, die SSDs wissen von der Partitionierung gar nichts, die kennen weder Partitionen noch Verzeichnisse noch Dateien, die kennen nur Lese- und Schreibzugriffe auf Adressbereiche.

freshprince2002 schrieb:
Eine SSD verwendet beim Lesen und Schrieben gleichzeitig mehrere ihrer Speicherchips, um die Geschindigkeit zu erhöhen.
Das passiert im kB Bereich, da interessieren GB große Partitionierungen nicht.
freshprince2002 schrieb:
Wenn jetzt eine Partition auf z.B. 2 von 8 verfügbaren Chips aufgeteit ist, geht da die Performance verloren.
Sowas wäre allenfalls denkbar, wenn eine Partition nur weniger k klein wäre, aber was wäre unsinnig und es passiert halt auch bei jeder ganz kleinen Dateien, die liegen auch nicht über alle NANDs verteilt.
freshprince2002 schrieb:
Außerdem kann hier Wear Leveling auch nicht gescheit funktionieren.
Das ist gleich total falsch, da die internen NAND Adressen nichts an die LBAs gebunden sind und wie gesagt ein Controller einer SSD von den Partitionen keine Ahnung hat, der zieht nur die LBAs auf die die Zugriffe erfolgen und weiß überhaupt nicht zu welcher Partition diese gehören.

freshprince2002 schrieb:
Eigentlich sollte bekannt sein, dass man eine SSD nicht partitioniert.
Eigentlich sollte bekannt sein, dass diese ein blöder Aberglaube ist.

Willi-Fi schrieb:
NVMe supportet noch keinen Raid....
Auch das ist Quatsch, es hängt vom System und dem Treiber ab, aber das ist bei SATA ja auch so.

Blaze1987, setze hier beide Haken:

schreibcache-png.536222
 
h00bi schrieb:
Richtig, CDM fordert kein FUA, daher ist das Ergebnis hier auch unverfälscht.
Wie ich oben schon geschrieben habe ein reines Benchmarkproblem.

Danke dir...muss mal lesen, wofür FUA steht^^

Damit geht die Lösung an deine Person :)

Natürlich Danke an allen...
Ergänzung ()

Habe alles soweit schon korrekt eingestellt.

@ Holt: Wie immer vielen Dank für deine professionellen Hilfen & Erklärungen. Du bist & bleibst der SSD Junk no 1 für mich.
 
FUA sind NVMe Schreibbefehle unter Umgehung des Schreibcaches der SSD, die befehlen dem Controller die Daten direkt ins NAND zu schreiben und erst dann zu melden, dass der Schreibvorgang abgeschlossen ist. Es ist damit nicht nur ein Benchmarkproblem, denn auch andere, reale Programme nutzen ja diese Befehle und Du solltest daher sehen, dass Du auch beim AS-SSD eine gute Schreibperformance erzielst.
 
Dieser Thread ist (leider) mal wieder ein gutes Beispiel wie Hilfe nicht aussehen sollte. Wenn man von der Materie keine Ahnung hat, dann lieber mal nicht antworten. Der Fragesteller wird durch solche falschen Aussagen nur verunsichert und andere müssen das dann erst wieder mühsam richtigstellen. So etwas muss nicht sein.
 
@Holt: Na ja, aber wenn der AS SSD halt gruselig langsame Schreibgeschwindigkeiten erreicht, und der CrystalDiskMark hingegen eine relativ hohe Geschwindigkeit ... was soll man dann machen?

Wir haben hier in der Firma einen neuen Dell PC (Precision 3620) und hier ist halt so eine SM951 SSD verbaut ... im AS SSD erreicht sie beim Sequentiellen schreiben nur ca. 20 mb/s ... bei 4K sogar nur unter 1 MB/s ...

Was könnte ich hier testen? Ob ich nun Schreibcache an oder ausmache für die SSD, da ändert sich nichts oder fast nichts im AS SSD Benchmark.



 
Zuletzt bearbeitet:
Wieso wird denn der iaStorA für die SSD verwendet? Das ist der Intel Treiber, daher würde ich entweder wie in Post #13 schon vorgeschlagen beide Haken setzen oder den Samsung NVMe Treiber nehmen, den findest Du bei den Samsung SSD Downloads findest.
 
AW: NVME SSD Schreibrate sehr niedrig

Habe keine Samsung sondern ne Toshiba NVME PCIe SSD verbaut... Mit den beiden Haken stellt ein workaround da, keine Lösung.... Jedoch natürlich besser als nix.

Der Intel SSD Treiber gehört zur DELL Support CD bzw. zum Image dazu. Hatte mir nur den aktuellsten von der Homepage gezogen...
 
Zuletzt bearbeitet:
Ob Workaround oder Lösung, das Ergebnis ist das Gleiche: Statt der Befehle die der SSD die Nutzung des Schreibcaches verbieten, kommen nun welche die es erlauben. Ob diese nun vom Treiber des SSD Herstellers erzeugt werden oder man den Treiber von Microsoft dazu ermuntert diese zu nehmen, macht doch keinen so großen Unterschied.
 
Zurück
Oben