RAID Guide [2]

Wenn ich ein Raid 0 aus 6 Platten erstelle mit oft vorgeschlagenen 128kB Stripe Size, dann werden nur Daten welche 6x128kB=768kB übersteigen sinnvoll aufgeteilt und profitieren vom Parallelen Zugriff (95%).
Nein, nur solch große Dateien werden garantiert über alle 6 SSDs verteilt, aber jede Datei die größer als ein 4k Cluster ist, kann auf zwei bzw. ab 136k sogar über 3 SSDs aufgeteilt sein, dann es geht ja beim RAID nicht dateiweise mit der Aufteilung, sondern der gesamte Adressraum ist über die ganzen Laufwerke aufgeteilt und man weiß nie, wo in diesem Adressraum eine Datei liegt. Also schon eine mit 8k kann gerade mitten auf der Grenze liegen und daher eben je zur Hälfte auf einer und der nächsten SSD stehen. Ab wann eine solche Aufteilung nun auch einen Performancegewinn bedeutet, lässt sich schwer vorhersagen, aber eine gewisse Größe muss die Datei dafür schon haben.

Oder verstehe ich dies falsch? Des weiteren würde ich Platz verschenken, da alle Dateien welche kleiner als 768kB sind diesen Platz beanspruchen.
Nein, da es nicht dateiweise passiert, außer Du willst neben dem Stripe Size des RAIDs auch den Cluster Size des Filesystems so groß wählen, dann würde die Regel gelten, dass man statisch pro Datei eine halben Cluster verschenkt. Ich würde aber bzgl. der Clustergröße zur Standardvorgabe von NTFS von 4k raten.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Grundsätzlich hast du das mit der Stripe-Size richtig verstanden, jedoch meine ich in meinem Halbwissen, dass du auch das einbeziehen musst, was am Ende die Partitionstabelle draus macht, die ja den Speicher selbst in Sektoren unterteilt, unabhängig von der Stripe-Size.
 
Nein, nur solch große Dateien werden garantiert über alle 6 SSDs verteilt, aber jede Datei die größer als ein 4k Cluster ist, kann auf zwei bzw. ab 136k sogar über 3 SSDs aufgeteilt sein, dann es geht ja beim RAID nicht dateiweise mit der Aufteilung, sondern der gesamte Adressraum ist über die ganzen Laufwerke aufgeteilt und man weiß nie, wo in diesem Adressraum eine Datei liegt...

Ok ich verstehe, die 850 EVO 250GB hat folgende Kurve:
atto ssd 850 evo 250gb.jpg
Dann würde sich bei 1600MB/s / 6 = 266MB/s => 8KB (Read) und 16kB (Write) lohnen, je nachdem worauf es ankommt (ich würde für Steam Read bevorzugen) da alle größeren Stripesizes im DMI Limit landen . Bei den "kleinen" Stripe Sizes aber so am meisten Daten verteilt werden und überhaut eine chance auf Performance zuwachs haben.
Stimmt der Gedankengang?

MfG Basti
 
jedoch meine ich in meinem Halbwissen, dass du auch das einbeziehen musst, was am Ende die Partitionstabelle draus macht, die ja den Speicher selbst in Sektoren unterteilt, unabhängig von der Stripe-Size.
Die Partitiontabelle unterteilt zwar auch den Speicherbereich des RAIDs, aber viel relevanter ist dessen Unterteilung durch die Cluster des Filesystems, denn eine Partition ist ja sehr viel größer als der Stripe Size und geht daher immer über alle Platten des RAIDs. Innerhalb der Partition gibt es dann einen Linearen Adressraum und der ist vollkommen unabhängig davon wie groß der Stripe Size ist.

Die Dateien werden dann über diesen linearen Adressraum verteilt und landen daher nicht perfekt am Anfang eines Strips. Man könnte es sich so vorstellen, dass man Objekte wie z.B. Münzen auf den Boden wirft, mit einem Lineal an die Wand schiebt und sich die besser cm Markierungen als die Grenzen der Strips vorstellt, an denen sich die Objekte auch nicht ausrichten werden und je nach Größe und Position belegen sie dann eben Positionen die über mehrere cm Bereiche hinwegreichen.

Ok ich verstehe, die 850 EVO 250GB hat folgende Kurve:
Anhang anzeigen 472238
Dann würde sich bei 1600MB/s / 6 = 266MB/s => 8KB (Read) und 16kB (Write) lohnen
Vorsicht! ATTO bencht in der Standardeinstellung mit 4 Overlapping I/O, die Werten müssen also nochmal so etwa durch 4 geteilt werden, sofern sie nicht sowieso schon im Bereich des Interfacelimits (welches hier mit nur knapp über 400MB/s ungewöhnlich gering ist) liegen. Vergleich das mit den 4k Lesend bei AS-SSD oder den 4k Q1T1 Read bei CrystalDiskMark und Du wirst sehen, dass eine 850 Evo bestenfalls auf so 50MB/s bei 4k Lesend kommt, wenn es wirklich nur ein I/O ist, aber niemals auf die knapp 137MB/s wie sie ATTO hier zeigt.


Bei den "kleinen" Stripe Sizes aber so am meisten Daten verteilt werden und überhaut eine chance auf Performance zuwachs haben.
Stimmt der Gedankengang?
Ja, bei kleinerem Stripe Size werden auch kleine Dateien besser über die Laufwerke des RAIDs verteilt und profitieren damit bzgl. der Geschwindigkeit. So große Dateien können aber wiederum auch leiden, da ja jeweils nur recht kurze Zugriffe auf die einzelnen Laufwerke stattfinden, was aber auch sehr von der konkreten RAID Lösung abhängt und wenn dann sowieso das DMI Limit.....

Es könnte übrigens sein, dass der SATA Host Controller im Chipsatz sogar noch weniger Bandbreite als die DMI Anbindung des Chipsatzes bietet, wundere Dich also nicht zu sehr, wenn Du es gar nicht schaffst diese 1600MB/s wirklich zu erreichen.
 
Hallo,

und danke erstmal für die vielen kompetenten und sehr anschaulich erklärten Antworten!

Ich finde den Benchmark aus dem Netz nicht so unglaubwürdig, meine 850 mit 500GB schafft zu 90% gefüllt auch nicht mehr und wer Braucht SSDs welche im leeren Zustand schöne Bechmarks abliefern aber voll nicht mal die hälfte schaffen... dann lieber gleichbleibend um die 500MB/s. Klar liegt der Q1T1 noch unter dem Atto wert. Mit QD1 würde der für die 260MB ca eine Stripesize von mindestens 64kB benötigt (nach meiner 500GB Evo hier).
Zwischenablage03.jpg
Da wir schon über Queue Depth sprechen, dies ist die Anzahl der angestellten Anfragen bezüglich Daten an den Controller (Maximum 31 bei SATA). Um so mehr anstehen um so besser kann der Controller durcharbeiten und sich selbst managen. Nun stellt sich hier doch natürlich die Frage wie viele Anfragen stellt z.B. ein Spiel bezüglich Daten an das Laufwerk, wenn das nur eine ist Profitiert man natürlich am wenigsten, das können wir aber mal wider nicht beeinflussen.

Wenn der Chipsatz eben nur weniger Durchsatz schafft, dann ist es eben so. Des weiteren würde mir natürlich das entsprechende Quell- oder Ziellaufwerk fehlen, Ramdisks gibts aber die sind im Speicherplatz ein wenig beschränkt, die NVME SSDs schaffen auf dauer auch nur knappe 1000MB/s (z.B. der Preiskracher aktuell Phison E12).

Mein Wissen sollte nun dank euch ausreichen um selbst beurteilen zu können welche Einstellungen ich wähle wenn es ans Basteln geht.


MfG Basti
 
Ich finde den Benchmark aus dem Netz nicht so unglaubwürdig, meine 850 mit 500GB schafft zu 90% gefüllt auch nicht mehr und wer Braucht SSDs welche im leeren Zustand schöne Bechmarks abliefern aber voll nicht mal die hälfte schaffen... dann lieber gleichbleibend um die 500MB/s.
Klar will keiner eine SSD sehr lahm wird wenn sie voll ist, aber bei denen von Samsung ist dies auch nicht der Fall, da gibt es andere Kandidaten. Aber diese 500MB/s erreicht man eben nur bei sehr langen Zugriffen oder bei kürzeren Zugriffen eben mit mehreren parallelen Zugriffen.
Klar liegt der Q1T1 noch unter dem Atto wert.
Weil ATTO eben mit 4 parallelen und überlappenden Zugriffen arbeitet und ich denke nicht, dass die Einstellung auf QD1 dies wirklich ändert, dafür ist der Unterschied zu den 137MB/s aus dem anderen Bild einfach zu gering. CDM macht aber in Deinem Test wirklich nur mit einem Zugriff, die Optionen darüber machen 32 bzw 64 parallele Zugriffe.
Mit QD1 würde der für die 260MB ca eine Stripesize von mindestens 64kB benötigt (nach meiner 500GB Evo hier).
Dies kann sein, wen die RAID Lösung auch mehrere Zugriffe auf die einzelnen Laufwerke ausführt. Es ist ja nicht zwingend das immer nur ein Stripe zur Zeit gelesen wird, man könnte auch schon das nächste Stripe lesen, wenn klar ist das dies gebraucht wird oder einen längeren Zugriff über mehrere Stripes machen und die Daten im Puffer sortieren. Probiere es doch einfach aus, dann siehst Du ja wie die Performance bei welchen Zugriffslängen und Stripe Sizes ist.
Da wir schon über Queue Depth sprechen, dies ist die Anzahl der angestellten Anfragen bezüglich Daten an den Controller (Maximum 31 bei SATA).
Maximal 32, aber die Platte kann selbst auch ein tieferes Limit angeben.
Nun stellt sich hier doch natürlich die Frage wie viele Anfragen stellt z.B. ein Spiel bezüglich Daten an das Laufwerk
Eben und wenn es nicht auf SSDs optimiert ist, wird dies im Zweifel nur eine sein, denn bei HDDs bremsen sich parallele Zugriffe wegen der Kopfbewegungen gegenseitig massiv aus, so dass es bei HDDs besser ist immer einen Zugriff nach dem nächsten zu machen. Generell profitieren die meisten Spiele nur wenig von einer schnellen SSD, eben weil sie nicht darauf optimiert sind und dann speichern sie ihre Daten ja meist auch noch komprimiert ab, die müssen also auch erst noch entpackt werden und damit wird die CPU, da dies i.d.R. auch nur Singlethreaded passiert dann ihre Singlethreadperformance, zum Flaschenhals.

die NVME SSDs schaffen auf dauer auch nur knappe 1000MB/s (z.B. der Preiskracher aktuell Phison E12).
Der Phison E12 sollte laut den Reviews bei Anandtech voll auch noch reicht gut performen, im Gegensatz zum SMI 2252EM, aber bei Schreibvorgängen wird irgendwann der Pseudo-SLC Schreibcache voll sein und dann schreiben SSDs mit TLC (und erst recht die mit QLC) NAND eben deutlich langsamer.
 
Hallo, mit meinem wissen habe ich eine kleine Tabelle in Excel zur Berechnung mit den Werten aus Jdiskreport gebaut.
Keine Ahnung ob ich nun alles wirklich richtig berechnet habe... kann gerne hier weiterentwickelt werden :bigok:
Raid 0 Calculator.jpg

MfG Basti
 

Anhänge

  • Raid 0 Calculator.zip
    23,4 KB · Aufrufe: 262
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh