Asus Z87 pro + 2x Samsung evo 250Gb Raid 0

conspectumortis

Lt. Commander
Registriert
Juni 2013
Beiträge
1.222
Hallo,

ich bin am überlegen mir eine weitere Samsung Evo 250Gb ssd zu kaufen um meine geringe SSD Kapazität aufzustocken.
Eine Samsung Evo 500Gb kostet mir zuviel und ich verkaufe ungern meine 250GB SSD, weil ich damit verlust machen werde. Natürlich könnte ich eine SSD fürs Windows System nutzen und eine für sone Art backup, aber das will ich nicht.
Und natürlich könnte man eine Festplatte kaufen, ich hab aber schon eine und die ist mir definitiv viiiiel zu laut, auch wenn sie in meinem Schallgedämmten Gehäuse eingebaut ist.

Meine Frage ob jemand ein ASUS Z87 pro Mainboard mit 2x Samsung EVO SSD im Raid 0 am laufen hat.

1. Welcher von beiden controlern wird eingesetzt ? (wobei nur der Intel controler mit bestimmten Softwareversion glaub Trim unterstützt)
2. Welche Bios Version wird genutzt ?
3. Welcher Intel Raid Treiber wird eingesetzt (wenn Intel Raid controler genutzt wird) ?
4. Welche Stripesize ist eingestellt ?
5. Wenn eine Stripesize von > 64 eingestellt ist ,wie groß war ca. der Kapazitätsverlust bei gleich installiertem System, im Vergleich zu ner 4er Einstellung ? (Selber berechnen ist ein Ding der Unmöglichkeit bei soviele unterschiedlichen großen Dateien)
6. Wie sieht die 4k performance aus ?

Und bitte keine "Raid 0 ssd ist unsinnig" und "brauchst du nicht" Antworten, das hilft mir nicht bei meinen Fragen =)

Gruß
conspectumortis
 
Zuletzt bearbeitet:
Auch wenn du gesagt hast das du es nicht hören willst, aber Raid 0 SSD ist unsinnig!
 
Du willst es nicht hören, aber ein SSD Raid0 ist wirklich Blödsinn. (Zugriffszeiten werden länger.)

Der Intel Controller unterstützt Trim, wenn EINE SSD und ein oder mehrere Arrays aus Festplatten im Raid laufen, ein Raid aus mehreren SSDs wird nicht mit trim unterstützt.

Frage beantwortet?
 
Zuletzt bearbeitet:
@Nitewing

http://www.anandtech.com/show/6161/...ssd-arrays-on-7series-motherboards-we-test-it

Trim geht anscheinend nur bei SSD Raid 0 arrays. Soweit bin ich schon, aber nicht weiter. Deshalb meine Fragen =)

Edit: Zugriffszeiten sind glaub auch abhängig wie man die Stripesize einstellt, deswegen auch die Frage.
Soweit ich das verstanden habe kommt es auch drauf an welche SSDs man benutzt, deshalb die spezifische Frage nach den Samsung SSDs + Board.
Natürlich kann man bestellen, testen und wieder zurückschicken. Aber das geht auf Kosten des Verkäufers, das ist auch nicht Sinn der Sache.
Deshalb nochmal die Frage an die Leute die Erfahrung mit dieser Hardware haben.
 
Zuletzt bearbeitet:
Danke AdoK.

Hab bereits ein paar dieser Beiträge gelesen, ich schau mir mal alle anderen nochmal an.
Hoffe ich finde das was ich finde.


Gruß

Edit: Leider nix dabei, was mir hilft. So allgemeine Fragen und Antworten sind mir klar, aber vielleicht meldet sich jemand der mir auf spezifisch gestellte Fragen beantworten kann.
 
Zuletzt bearbeitet:
ok, dann haben sie es hinbekommen. Trotzdem unsinnig. Im übrigen waren Kapazitätsverluste bei meinen HDD Arrays immer zu vernachlässigen. Die Stripesize wirkt sich im übrigen immer gleich aus. Kannste also Googlen, ich würde aber bei Deinem Setup ein 64er nehmen...
 
@Nitewing

Das war meine größte Befürchtung, dass die Stripesize mir zuviel Kapazität wegnimmt.
Eine Datei die nur 1Kb bspw. hat, wird bei mir bisher auf dem Datenträger mit 4 gespeichert und bei 64 > dachte ich mir, da windows und auch andere Programme viele kleine Dateien nutzen, dass da soviel weggeht...

Jap das muss ich schauen, ob 64, 128 oder vielleicht doch 32 besser sind. Erfahrungsaustausch wäre natürlich noch besser was die SSDs angeht , auch in Abhängigkeit der Performance und Zugriffszeit.

Bei mehreren Seiten habe ich gelesen, dass die 4k Performance wieder steigt und die Zugriffszeit wieder sinkt, wenn eine höhere Stripesize genutzt wird, aber welche genau bei dem Setup ist mir noch ein Mysterium.

Edit: Außerdem würde ich gerne wissen ob die Bootzeit sich auch wieder normalisiert wenn die Stripesize optimal gewählt wird oder ob das in keinem Zusammenhang steht.

Edit2: Zusätzlich war irgendwas mit dem write back cache. Manche meinten es bringe mehr wenn es bei einem Raid0 deaktiviert wird. Wie und Warum genau habe ich nicht herauslesen können.

Soweit ich lesen konnte, bei ein paar anderen mit anderem Setup, ist auch die Version des verwendeten Intel Raid Treibers ausschlaggebend.

Ich bin mir daher nicht sicher ob Raid 0 bei SSDs wirklich unsinnig ist, weil es auf soviele Faktoren ankommt die ich unmöglich ohne Erfahrungsaustausch wissen kann.
Ich vermute es ist eine ziemliche Frickelei, aber bei optimalen Settings kann ein Vorteil herausspringen. Und ich muss ja nicht das Rad neu erfinden, wenn bereits jemand eine Ahnung hat.
Ergänzung ()

Hab mir jetzt doch noch eine samsung ssd geholt von Mediamarkt, in der Hoffnung das ich richtig liege. Oo


Die nächsten Tage teste ich mal alle Treiber, Stripesize und die Aktivierung der caching Funktionen.
Vieleicht hilft es dem einen oder anderen irgendwann später.

Bisher passt alles:

- Trim ist aktiv.

- Die Windows Boot- und Herunterfahrzeit hat sich nicht verändert.
( Natürlich muss der Rechner jetzt den Raid vorher initialisieren. Das dauert ca. 2 Sekunden. )

- Zugriffszeiten sind anscheinend im normalen Bereich.
 
Zuletzt bearbeitet:
Nitewing schrieb:
Du willst es nicht hören, aber ein SSD Raid0 ist wirklich Blödsinn. (Zugriffszeiten werden länger.)
Das hängt davon ab wo das RAID realisiert ist. Vor allem (ältere) SAS Controller mit Cache erhöhen die Zugriffszeiten von SSDs gewaltig, weil die eben noch auf die Zugriffszeiten von HDDs ausgelegt waren und daher deren Cacheverwaltung eben nicht so schnell sein musst.

Aber überlege mal, was bei einem Zugriff auf eine Datei so alles passiert bis der / die LBA(s) ermittelt sind, auf die zugegriffen werden muss. Wenn man den Cluster kennt, muss noch der Offset der Partition daraufgerechnet werden und dann wird anhand der Clustergröße der LBA ermittelt. Kenne Windows den Cluster aber nicht weil er nicht im Cache steht (unbelegtes RAM wird ja als Diskcache verwendet), so muss der erst aus den ganze Metadaten ermittelt werden, also im Extremfall vom Rootdirectory aus der ganze Pfad bis zur Datei jeweils einzeln eingelesen werden, was dann jedes mal die beschrieben Schritt und den Zugriff auf das Laufwerk beinhaltet. Ob da nun noch einmal von der CPU eine Umrechnung des LBAs auf die lokalen LBAs des RAIDs erfolgt, spielt bei einem i7 nun wirklich keine Rolle mehr. Softraids sind daher heute meist schneller als die klassischen RAID Controller, da deren Kerne einfach viel langsamer sind als aktuelle CPUs.
Nitewing schrieb:
Der Intel Controller unterstützt Trim, wenn EINE SSD und ein oder mehrere Arrays aus Festplatten im Raid laufen, ein Raid aus mehreren SSDs wird nicht mit trim unterstützt.
Diese Information ist veraltet! Mit dem passenden RAID ROM im BIOS und einem aktuellen Intel RAID Treiber können auch SSDs in einem RAID 0 getrimmt werden. Bei einem RAID mit Redundanz, also z.B. einem RAID 1 oder RAID 5, geht TRIM dagegen nicht. Das ist da auch nicht so leicht, dann sonst würde es beim Lesen getrimmter Bereich auch zu Inkonsistenzen kommen, weil bei einem RAID 5 z.B. die Parity dann auch alle 00 wären und bei einem RAID 1 würden die Daten nicht stimmen, wenn eine SSD die TRIM Befehle schneller umsetzt als die andere.

conspectumortis schrieb:
Trim geht anscheinend nur bei SSD Raid 0 arrays. Soweit bin ich schon, aber nicht weiter.
So ist es, aber eben nur, wenn die Voraussetzungen stimmen.

conspectumortis schrieb:
Zugriffszeiten sind glaub auch abhängig wie man die Stripesize einstellt, deswegen auch die Frage.
Auf die Zugriffszeiten hat das Strippingsize keinen Einfluss, das bestimmt nur, ab welcher Zugriffslänge die Daten verteilt werden. Bei 64k gehen eben 64k auf die eine, die nächsten 64k auf die andere Platte. Erfolgt ein Zugriff mit 128k Länge, so kann im besten Fall, wenn der Zugriff genau auf das Stripping allignt ist, dies in genau zwei 64k Zugriffe aufgeteilt werden und im schlechtesten Fall hat man halt drei Zugriffe wie z.B. 32k + 64k + 32k. Wenn dann der RAID Controller die beiden 32k Zugriffe auf die eine Platte wieder zu einem 64k Zugriffe vereint, dann erreicht man auch mit einem kleinen Strippingsize hohe seq. Transferraten, sonst eben nicht, weil ja keine Zugriffe erfolgen, sie länger als das Stripping sind und SSD schon recht lange Zugriffe brauchen um ihre maximal seq. Transferrate zu erreichen.

Der Beschleungungseffekt eines RAID 0 tritt eben aber auch erst auf, wenn die Zugriffe wirklich deutlich länger als das Stripping sind. Bei einem 64k Zugriff und einem Stripping von 64k wird im Extrem nur ein 64k Zugriff auf eine SSD erfolgen, normalerweise aber ein Zugriffe von irgendwas zwischen 4k und 60k auf die eine, und von 60k bis 4k auf die andere SSD und da die bei kurzen Zugriffen recht langsam sind, gewinnt man dann noch gar nichts.

Da die meisten Plattenzugriffe aber i.d.R. sehr kurz sind, gerade auch die von Windows auf seine Systemdateien, gewinnt man mit einem RAID 0 aus zwei SSDs in der Praxis nur so 10% gegenüber einer einzelnen SSD. Deshalb ist es eigentlich immer vorzuziehen sich eine große SSD statt zwei kleinere zu kaufen, zumal es meist günstiger ist, die größeren dann selbst oft noch schneller sind (ok, bis zu einer Grenze und s gibt Ausnahmen, so werden die mit einem Sandforce über 240GB dann wieder langsamer) und vor allem, weil man von den größeren länger gut hat, denn für eine 500GB SSD wird man auch dann noch eine sinnvolle Nutzung finden, wenn man schon nichts sinnvolles mehr mit einer 250GB anfangen kann, auch wenn das noch ein paar Jahre hin sein wird. Aber vor kurzem war oft noch die Frage, ob man besser zwei 64GB oder eine mit 128GB SSD kauft und schon heute sind 128GB alles andere als üppig, was fängt man dann mit einer 64GB SSD noch an?
conspectumortis schrieb:
deshalb die spezifische Frage nach den Samsung SSDs + Board.
Wenn TRIM funktioniert und das sollte es wenn der richtige Treiber drauf ist und die nicht uralte ROM im BIOS haben, dann passt das, von dn oberen Überlegungen zu zwei kleinen statt einer großen SSD mal abgesehen.
conspectumortis schrieb:
Natürlich kann man bestellen, testen und wieder zurückschicken. Aber das geht auf Kosten des Verkäufers, das ist auch nicht Sinn der Sache.
Gesunde Einstellung, denn am Ende zahlen doch immer wir Kunden die Zeche, was viele leider vergessen.

conspectumortis schrieb:
Das war meine größte Befürchtung, dass die Stripesize mir zuviel Kapazität wegnimmt.
Das Stippsize kostet keine Kapazität!
conspectumortis schrieb:
Eine Datei die nur 1Kb bspw. hat, wird bei mir bisher auf dem Datenträger mit 4 gespeichert und bei 64 > dachte ich mir, da windows und auch andere Programme viele kleine Dateien nutzen, dass da soviel weggeht..
Da verwechselst Du aber Clustersize (also die Größe der Zuordnungseinheiten des Filesystems) mit dem Strippingsize. Jede Daten belegt immer einen ganzen Cluster (ganz kleine werden bei NTFS in den Metadaten gespeichert, Ausnahmen bestätigen mal wieder die Regel), aber das hat mit dem Stripping nichts zu tun, das besagt nur, wie viele Daten maximal am Stück auf einer Platte stehen.
conspectumortis schrieb:
Bei mehreren Seiten habe ich gelesen, dass die 4k Performance wieder steigt und die Zugriffszeit wieder sinkt, wenn eine höhere Stripesize genutzt wird
Wie soll den die 4k Performance steigen? Allenfalls die IOPS, also z.B. 4k_64 oder 4k QD32 steigen, weil die viele parallelen Zugriffe sich ja dann auf zwei SSDs verteilen.
conspectumortis schrieb:
Außerdem würde ich gerne wissen ob die Bootzeit sich auch wieder normalisiert wenn die Stripesize optimal gewählt wird
Die Bootzeit hängt vor allem von der Zeit für die Initialisierung der HW ab und in diesem Fall kommt dann die für das Fake-RAID dazu, aber das hat mit dem Stripping nichts zu tun.

conspectumortis schrieb:
Zusätzlich war irgendwas mit dem write back cache. Manche meinten es bringe mehr wenn es bei einem Raid0 deaktiviert wird. Wie und Warum genau habe ich nicht herauslesen können.
Das verstehe ich auch nicht ganz, aber dem größeren Puffer des RAID Treiber zusammenhängen. Der muss ja mehr puffern, weil der die Daten beim Schreiben ja aufteilen und beim Lesen dann wieder zusammenfügen muss, bevor er sie weiterreicht. Aber das er das bei deaktivieren Schreibcache dann schneller macht, kann ich mir irgendwie nicht so recht vorstellen.
 
Genau so eine Info habe ich gesucht, auch wenn es nicht spezifisch ist, das ist egal. Danke dir =)

K, also kann ich praktisch entweder nur mit anderen Treibern und/oder Aktivierung des Caches womöglich was gewinnen. Außer jetzt mit dem sequentiellen lesen / schreiben wenn ich auf Stripesize 128 gehe. Hatte das ganz am Anfang, waren so 1Gb /s lesen und ca. 950mb/s schreiben. 64k hab ich nur zu Testen drin. Die Zuordnungsgrößeneinheit habe ich wieder auf Standard gesetzt.

Ohne den 11.x Intel Raid 0 Treiber sahen alle Werte grausam aus. Also mit dem Standardtreiber von windows, wenn man windows installiert. Habs nur schnell getestet damit ich sehe was für ein Unterschied vorhanden ist.

Eine Frage habe ich noch:

Im Bild unten ist der write back cache deaktiviert, den kann ich auch nicht aktivieren, soweit ich jetzt doch sehen konnte, zumindest nicht beim Intel Storage Programm. Ich frag mich nur warum der von Haus aus ganz deaktiviert ist.

Was mir noch bleibt ist write-through und schreibgeschützt, wobei ich schreibgeschützt in diesem Zusammenhang nicht verstehe.

Welche Meinung hast du dazu ?

cache.png


Edit: K ich habs selber herausgefunden. Man muss den Schreibcache oberhalb deaktivieren dann kann man den write back wieder aktivieren.

Abartig wieviel Mehrleistung dadurch erreicht wird. Vorallem die 4k Schreibgeschwindigkeit und auch die Zugriffszeit beim Schreiben.
Dass die 4k Geschwindigkeit beim Lesen von ca. 31 mb/s auf mehr als 40mb/s gestiegen ist verstehe ich aber in dem Zusammenhang nicht.
Ich hab bei mehrmaligem Test ohne write back cache nie mehr als 31 mb/s geschafft.

neu.png

Ich bin begeistert =)

Edit 2: Was mich aber stutzig macht ist.... Als ich write back aktiviert habe, kam eine Warnmeldung, dass unter besonderen Umständen Daten verloren gehen können.
 
Zuletzt bearbeitet:
Du meinst die 359MB/s? Das schafft die SSD nicht, das passiert im RAM, also im Schreibcache. Dabei gehen natürlich immer dann Daten verloren, wenn der Schreibcache nicht auf die SSD geschrieben werden kann, also bei einem Stromausfall oder einem BSOD. Das ist das Risiko jedes Schreibcaches, weshalb die RAID Controller ja auch für gewöhnlich ein Akkupack (BBU) oder neuerdings einen paar Kondensatoren und Flash mitbringen.
 
Was mir gerade aufgefallen ist:

Wenn ich von der Partition D auf Partition C etwas rüberkopiere. Beim Test den ich gemacht habe waren es ca. 19Gb (guild wars 2 dat Datei), startet das Kopieren mit ca 700mb/s ( 1/3 des Kopiervorgangs) und wird dann immer langsamer bis es auf 215Mb/s runterfällt.
Das ist doch nicht normal oder ?

Edit: so 5-6Gb Dateien kopiert er in 5 - 6 Sekunden, dass müsste passen.

Und noch etwas. Hab versucht auf der Partition C trimcheck wieder durchzuführen.
Nur sagt er mir, obwohl ich noch mehr als 30GB frei habe, dass die disc space zu gering ist.

low.png
 
Zuletzt bearbeitet:
Der Explorer liest immer erstmal alles was geht ins vorher RAM ein und berechnet die Geschwindigkeit auf der Basis der gelesenen Daten. Daher zeigt er am Anfang immer eine höhere Geschwindigkeit an, wenn man von einem schnelleren auf einen langsameren Datenträger kopiert. Dann kommt bei der Evo hinzu, dass diese ja nur die 3GB, bzw. bei Dir wegen des RAID 0 dann 6GB schnell schreiben kann, danach dann nur noch mit so 250MB/s (bei der 250GB Evo), da aber die Daten auch von der gleichen SSD gelesen werden, bremsen sich die Zugriffe halt gegenseitig und wenn der Virenfinder noch über die Daten schaut, dann bremst der auch noch mal.

Trimcheck meldet den Fehler vermutlich, weil Du das Programm auf direkt C:\ gestartet hast, aber die cmd.exe nicht als Administrator gestartet wurde. Normale User dürfte aber nicht auf C:\ schreiben, was Trimcheck ja macht, weshalb es dann die Fehlermeldung ausgibt. Die müsste korrekt lauten, dass ihm das Anlagen des Testfiles nicht möglich war. Verschiebe Trimcheck also in ein Verzeichnis, wo der User unter dem Du angemeldet bis auch Schreibrechte hat und teste dort erneut, oder starte die cmd.exe "Als Administrator" (aus dem Menu der rechten Maustaste).
 
:daumen:

Vielen, vielen Dank Holt für die Infos.

Trimcheck geht nun als Admin.

Also passt soweit alles, freut mich =)
 
Sagte den TRIMcheck beim zweiten Lauf, dass TRIM funktioniert hat?
 
Jap hat funktioniert.

Was mir aber dann noch aufgefallen ist...

Wenn ich den write back cache aktiviere sagt er mir dass Trim anscheinend nicht funktioniert bzw. nicht aktiv ist.
Deshalb habe ich den write back cache wieder deaktiviert und die Standardeinstellungen für das Raid 0 Array genommen, dann hat Trim wieder funktioniert laut tool.
 
Zuletzt bearbeitet:
Ich habe mal versucht den dynamischen Speicherbeschleuniger im Raid Treiber zu aktivieren, leider ohne Erfolg. (siehe Bild unten)


Zudem wollte ich mal sehen ob sich irgendwas bei den Windows Bootzeiten ändert wenn ich die Auslagerungsdatei deaktiviere.
Jetzt startet mein System in ca. 5 Sekunden anstatt ca. 8 Sekunden und 16Gb mehr Speicherplatz auf der C Partition.

Ich schau mal welche Nebenwirkungen dabei entstehen. Irgendwo habe ich gelesen, dass manche Programm dann nicht korrekt funktionieren.

Hibernate ist nun auch deaktiviert und das Hibernate file gelöscht. Zusammen brachte mir das ca. 25Gb freien SDD Speicher mehr.
Ruhezustand werde ich erstmal nicht mehr benutzen.

Zudem wurde mir in einem anderen Thread gesagt, dass der Ruhezustand nicht förderlich sei in Kombination mit einer SSD. ( anderes Problem mit dem System)
Was dran ist lese ich hier irgendwann mal nochmal nach.

Edit: Bei Gelegenheit versuche ich mal einen anderen Intel Raid Treiber. 64k Stripesize haben sich als effektivsten herausgestellt.
dynamisch.png
 
Zuletzt bearbeitet:
Zurück
Oben