SSD-Raid0 liest zu langsam

Teilzeitzocker

Cadet 2nd Year
Registriert
Jan. 2020
Beiträge
29
Hallo Community,

ich weiß nicht mehr weiter und wende mich deshalb an dieses Forum.

Es geht darum das die Leserate im Raid0 zu niedrig ist.
as-ssd-bench AMD 2+0 Stripe.R 25.02.2020 18-39-42.png


Interessant dabei ist das die Kingstonplatte (langsamere SSD) Ihre vom Hersteller angegebene Schreibgeschwindigkeit mehr als verdoppelt hat. Jedoch ist die Lesegeschwindigkeit gerade mal um ca. 30% erhöht.

Anmerkung: Ich bin Dankbar für jeden Tipp und alle Hilfestellung. Aber bitte lasst diese Kommentare über die Sinnhaftigkeit der Sache, wie man es in allen anderen Threads hierzu gelesen habe. Ich bin mir über Vor- und Nachteile bewusst. Das ist Off-Topic und erschwert die Lösungsfindung. Zudem wurde das bereits HIER diskutiert und kann bestimmt dort ergänzt werden. Danke.



Systemeinstellungen und -daten:

Raid-Controller-Setting:

Raid0
256kb cache (max. vom Raidcontroller)
4kb Sektorgröße (max. vom Raidcontroller)
read ahead
write back


Treiber:

Speichercontroller

AMD-AHCI-kompatibler RAID-Controller (Microsoft-Treiber-Signatur)
AMD-RAID-Konsole (Microsoft-Treiber-Signatur)
Microsoft-Controller für Speicherplätze

Laufwerke

Microsofttreiber

Hardware

Mainboard: Gigabyte GA-990X-Gaming
Prozessor: FX-4320 @4,6Ghz
Raid-SSD´s: Patriot Burst 240GB
Kingston A400 240GB

Windows10-Settings

375/444GB nicht belegt
Idexierung OFF
SWAP OFF
Energiemanagment "Höchstleistung"


Alle Sataports sind Sata-3

Port 0-3 sind für den Raid

Die Raid-SSD´s sind an Port 0-1 angeschlossen

Eine weitere SSD ist an Port 4 angeschlossen.




Wäre schön wenn Jemand Erfahrungen damit hat bzw. eine Idee woran es hapert.
Habe ich etwas übersehen oder vergessen?
Ist etwas falsch eingestellt?

Viele schreiben das man gleiche SSD-Modelle für einen Raid nehmen soll, allerdings ist das einzige Argument welches ich gefunden habe, das man halt nur die maximal doppelten Geschwindikeiten der langsameren Platte erreicht und das als Verschwendung empfunden wird. Mir ist das egal.

Tyvm, Hf u. Gl =)
 
Wenns auf Geschwindigkeit ankommt warum dann nicht vernünftige SSDs verwendet?
Es gibt auch Lösungen eine flotte Lese/Schreiberate zu erhalten ohne zu pfuschen.
 
  • Gefällt mir
Reaktionen: Fujiyama, I'm unknown und KenshiHH
Weil ich sparsam bin und diese SSD´s nunmal habe...

Danke, dein Kommentar hat mir viel geholfen.
 
Frage wurde das Raid0 per Mainboard Bios oder über Windows erstellt.
 
Hast mal andere Ports probiert. Könnte mir vorstellen, dass sich bei manchen Mainboards zwei Ports die Anbindung teilen (oder hab mal sowas gehört).
 
John Sinclair schrieb:
Frage wurde das Raid0 per Mainboard Bios oder über Windows erstellt.
Sollte keinen großen Unterschied machen - das Mainboard hat keinen dedizierten Raid Controller, also läuft das eh alles über die CPU

Der Software-Raid von Microsoft ist auch nicht so schlecht wie sein Ruf, siehe 2x MX500 2TB:
2020-02-25 19_44_10-Window.png


Die verursachte CPU-Auslastung während so ein Benchmark läuft ist zumindest beim R5 3600 vernachlässigbar.
 
Durch Raid 0 steigt die Zugriffszeit und damit sinkt der theoretische Durchsatz bei bestimmten Szenarien.
Weiterhin ist "MB/s" eine eher ungeeignete Einheit zum Vergleich der Performace in diesem Bereich. "IOPS" wäre dafür besser, denn zusammen mit der Latenz kommt es viel näher an die gefühlte Geschwindigkeit heran, also das, was man in der Praxis tatsächlich bemerkt.
 
  • Gefällt mir
Reaktionen: King_Rollo und Nickel
Ich habe leider nur 2 MVe SSD im Raid0 und da sind die Werte weitaus höher.

Deswegen kann ich hier wohl nicht viel helfen. Trotzdem mal hier meine Werte:

1582657188664.png
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: John Sinclair
@Asghan Danke für die Info ;) Habs in Meiner Sig geändert ^^.

Um Zum Thema zurück zukommen, Sollten wie schon der Post von @iamunknown immer mit
den gleichen Laufwerke ein Raid gemacht werden. Egal ob es sich um Raid 0 / 1 / x handelt.
Immer die selben Laufwerke für ein Raid benutzen. Das liegt auch schon daran, das nicht alle SSD / HDD
genau die selbe Größe haben. Geschweige denn von der Geschwindigkeit.
 
  • Gefällt mir
Reaktionen: King_Rollo
Denke auch, dass es an den unterschiedlichen SSDs liegt.
Die unterschiedlichen Zellen haben evtl. trotz des gleichen Controllers ein anderes Schreib- und Leseverhalten, die jetzt zwischen den unterschiedlichen Speicherzellen abgeglichen werden muss.
 
  • Gefällt mir
Reaktionen: John Sinclair
Desweiteren sollte die neue Version von Crystal Mark genommen werden.
Diese ist über den MS Shop kostenlos zu bekommen. Weil diese :

1. Reelle Werte liefert.
2. auch als 64 Bit testet
3. die HDD Test mit z.b. 4K nicht mehr stimmen.

1582659163429.png


Selbes Laufwerk 2 x Samsung SSD 970 EVO 1 TB NVMe Raid 0 Test Vergleich Posting 8

Die alte Version von Crystal Bench hat auch noch mit 4K getestet, wurde aber umgestellt
weil die Werte nicht mehr stimmten. Finde jetzt aber nicht den Post von Crystal Bench dazu.
 
Zuletzt bearbeitet:
John Sinclair schrieb:
Frage wurde das Raid0 per Mainboard Bios oder über Windows erstellt.
Das sieht man doch oben links im Screenshot von AS-SSD im ersten Post: Es ist ein RAID0 per Mainbord und das bei AM3(+), die waren nie besonders performant und TRIM dürfte auch nicht gesehen, dazu sind es billig SSD mit den Phison S11 DRAM less Controller. Der einzige Parameter an dem man drehen könnte, wäre der Stripe Size, den sollte man möglichst hoch wählen, denn auch SATA SSDs brauchen recht lange Zugriffe um ihre maximale Transferrate zu erzielen, selbst 128k reichen dafür nicht. Daher dürften die Leseraten auch so schlecht sein.
 
  • Gefällt mir
Reaktionen: Asghan
Naja wenn du lesen willst fragt das OS den Datenträger, also das Raid 0: Gib mir mal diese Datei, sprich diese 100 Bytes.
Datenträger guckt nach wo sich denn das erste Byte befindet: Erste SSD? Nope. Zweite SSD? Jup hier bitte seit.
Datenträger guckt nach wo sich denn das zweite Byte befindet: Erste SSD? Jup, hier.
und so weiter.. Jedes Mal also Zugriffszeit einer und danach von beiden SSDs und das dauert halt.

Ja, mit read ahead kann man da bei sequenziellen Lesevorgängen etwas gewinnen aber in der Regel nur wenn der angeforderte Lesezugriff eingelesenen Daten kleiner sind als die stripe size.

Raid 0 ist halt nur beim schreiben signifikant schneller, beim lesen wäre ein Raid 1 besser und will man beides eben ein Raid 10, so zumindest der klassische Ansatz.
Man bekommt mehr IOPS erkauft dies aber immer mit einer etwas höheren Latenz/Zugriffszeit aufgrund des Raid-Overheads. Nicht umsonst haben sich Cache Methoden etabliert wo die zuletzt und/oder am häufigsten benötigten Daten/Blöcke auf einer oder (mehreren gespiegelten) SSDs befinden und dahinter dann langsamere SSDs/HDDs befinden für die restlichen Daten.

Will man diesen Overhead nicht müsstest du ein Storagesystem verwenden, dass sich für alle Blöcke merkt wo genau diese liegen. Nachteil: Dein OS bzw. dein Benchmark fragt diese "Liste" wo die Daten liegen und danach wird erst das eigentliche Storage-Backend gefragt. Latenz bis etwas gefragt wird erhöht sich, der eigentliche Abruf ist dann fixer und Schreibzugriffe ebenfalls langsamer da die Blöcke ja in diese "Liste" müssen. Lohnt also eher weniger...
 
snaxilian schrieb:
Dein OS bzw. dein Benchmark fragt diese "Liste" wo die Daten liegen
Da gibt es keine Liste, die lokalen Adressen auf den Platten kann man ganz einfach berechnen, dazu muss man nur die globale Adresse durch den Stripesize teilen und wenn bei zwei Platten der ganzzahlige Anteil gerade ist, dann steht es auf der einen Platte und ist er ungreade, steht es auf der anderen. Der ganzzahlige Anteil wird dann durch 2 (integer, also ohne Rest) geteilt, puls dem Rest der ersten Operation und dies mal dem Stripsize ergibt die lokale Adresse auf dem jeweiligen Datenträger. Wozu sollte an da eine Liste brauchen?
 
Lösung:

Habe nochmal die Bioseinstellungen nachgeschaut und APM (AMD Application Power Management) war deaktiviert. Ohne Diese Option scheint die CPU etwas überfordert zu sein. Bei PubG hatte es eine dauerhafte CPU-Last von 100% bis es nach 2-3min jeweils abstürzte. Deshalb hab ich mich in der Richtung auf die Fehlersuche begeben.

Aber jetzt ist alles schick.

Danke für die vielen Antworten und Konstruktiven Vorschläge.

Hier noch die neuen Benchmarks:

iops-2.png



as-ssd-bench AMD 2+0 Stripe.R 26.02.2020 01-11-41 high.png





@John Sinclair
Der Raid0 ist via Mainboard realisiert. Windows 10 läuft darauf.
CrystalDiskMark bringt mein System zum absturz. Bei der Vorbereitung zu Random 4kb gibt meine CPU auf.
Daher sind vorherige Benchmarks weiter mit AS-SSD.
Und zu den verschiedenen SSD´s in meinem Raid siehe:
Teilzeitzocker schrieb:
Viele schreiben das man gleiche SSD-Modelle für einen Raid nehmen soll, allerdings ist das einzige Argument welches ich gefunden habe, das man halt nur die maximal doppelten Geschwindikeiten der langsameren Platte erreicht und das als Verschwendung empfunden wird. Mir ist das egal.

@Aphelon
Beim umstecken des Ports ging der Raid0 nicht mehr online. Vielleicht weil Windows darauf installiert ist?

@iamunknown
Warum war das noch nie eine gute Idee?

Holt schrieb:
und TRIM dürfte auch nicht gesehen, dazu sind es billig SSD mit den Phison S11 DRAM less Controller.
DisableDeleteNotify = 0

snaxilian schrieb:
Man bekommt mehr IOPS erkauft dies aber immer mit einer etwas höheren Latenz/Zugriffszeit aufgrund des Raid-Overheads.
Die Zugriffszeiten sind immerhin 0,035ms/lesen und 0,061ms/schreiben besser als auf der 1TB-SSD im Rechner meiner Frau =)
 

Anhänge

  • iops-1.png
    iops-1.png
    33,1 KB · Aufrufe: 299
Teilzeitzocker schrieb:
DisableDeleteNotify = 0
fsutil behavior query DisableDeleteNotify zeigt nur an, ob Windows überhaupt TRIM Befehle schickt und Tools wie CrystalDiskInfo zeigen die Eigenschaften der Disks an, also ob der Controller überhaupt TRIM Befehle versteht, was bei allen aktuellen SSDs der Fall ist. Es zeigt aber nicht ob der Controller wirklich TRIM Befehle bekommt, TRIM also wirklich funktioniert. Das kann man am Besten mit dem Tool TrimCheck prüfen, man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat. Dazwischen sollte man nichts am Rechner machen und ein paar Minuten warten. Wurde TRIM nicht als funktionierend erkannt, kann man es auch erneut laufen lassen und es prüft die Daten noch einmal. TrimCheck muss auf der SSD liegen, wenn es ausgeführt wird, der User muss in dem Verzeichnis Schreibrechte haben und es darf weder verschlüsselt noch komprimiert sein.
 
@Holt

CONCLUSION: TRIM appears to be NOT WORKING (or has not kicked in yet).

Danke für die gute Erklärung.

Aber:


Defragmentierung führt TRIM aus
Bei Windows 8 und 10 erweist sich ein deaktiviertes TRIM als weniger tragisch, als es beim Vorgänger Windows 7 der Fall ist. Der Grund: Erkennen die Kachel-angereicherten Systeme eine SSD-Platte, schickt die Defragmentieren-Routine ihr den TRIM-Befehl. Ein Neuanordnen Ihrer gespeicherten Dateien findet auf einer SSD nicht statt – sie wäre ohnehin Gift für die Lebensdauer und brächte keinen Geschwindigkeitsgewinn.

Quelle





PS:
Trotzdem ist der Leistungszuwachs gut.
Meine Frau hat exakt das selbe System, außer die Festplatten.
Heute gab es in Steam ein Update zu einem Game.
20Gb komprimierte herunterladen und gleichzeitig entpacken.
Der Vergleichsrechner hat 1h länger gebraucht was ich beachtlich finde.
 
Teilzeitzocker schrieb:
Der Vergleichsrechner hat 1h länger gebraucht was ich beachtlich finde.
Dieser Unterschied kommt mit Sicherheit nicht durch dein RAID0.
RAID0 bei SSDs ist in den meisten Fällen ziemlicher Unsinn, weil man auch einfach eine schnellere SSD nehmen kann. Bei Festplatten ging das nicht bzw. nur bedingt.
 
  • Gefällt mir
Reaktionen: snaxilian und I'm unknown
Zurück
Oben