[Sammelthread] Sandisk Ultra Plus im RAID0 richtig konfiguriert?

[Ch3ck3rM0n]

Hallo Leute,

ich habe seit Samstag meine neuen SSDs im Raid0-Verbund am Laufen. CrystalDiskMark hat mir seq. Read 693 MB/s und seq. Write 608 MB/s ausgegeben. Da eine einzelne Platte 530|445 MB/s liefern soll bin ich jetzt skeptisch, ob meine Werte okay sind oder nicht. Mir ist bewusst, dass Herstellerangaben nur Bestwerte darstellen, deshalb meine Frage:

Sind 693|608 MB/s okay oder müssten diese eher im Bereich 800|700 MB/s liegen?

oder

Gibt CrystalDisk vielleicht die reellen Raten aus und es stimmt was mit meinem Raid0 nicht? Wenn was nicht stimmt, woran könnte es liegen?

Restliche Systemdaten: siehe Signatur

Danke im Voraus

Gruß CM



EDIT:
Nachdem ich heute durch Zufall CrystalDiskInfo hab laufen lassen, fiel mir auf, dass eine der beiden SSDs nur mit SATA 300 angesprochen wurde. Nachdem ich kurz die Ports am Mainboard getauscht hatte lieferten die Platten plötzlich bei weitem mehr Lese/Schreib-Performance als zuvor. Somit kann ich die Platten doch wieder für ein RAID empfehlen und gebe aber den Tipp: Achtung beim Übertragungsmodus! (Siehe Screenshot)

 

[matthias80]

Hallo,

denke ist ok.
eine 1:1 Rechnung kannst eh nicht machen!
geht ja ein bisschen was durch Overhead das raid an sich ect. verloren...
raid onboard?

mfg

 

[Ch3ck3rM0n]

Jup, onboard Raid vom Intelcontroller kommend..

 

[Ismirlangweilich]

Es sollte eher der doppelte Wert der Einzelplatte dabei herauskommen. Kommt aber darauf an, welche Anbindung die Southbridge inclusive dem Controller hat.

Da du nur um die 600 MB/sec herausbekommst könnte es an deinem Asrock Board liegen. Die sparen bei solchen Anbindungen gerne mal etwas ein. Oder du hast die Platten an einem Fremdhersteller Controller angeschlossen, der mit auf dem Board sitzt und nicht an die Anschlüsse des Intel Z87 Controllers angeschlossen.

Welche Werte hast du denn mit einer einzelnen Platte? Je nach Größe der SSD weichen die Werte auch ab, zb. erreichen größere SSD höhere Datendurchsatzwerte als die kleineren Varianten der selben Serie.

 

[Ch3ck3rM0n]

Jup, onboard Raid vom Intelcontroller kommend..Das Board realisiert laut Datenblatt 6x 6Gbit/s per Z87-Chipsatz und 4x6Gbit/s per ASMedia ASM1061-Controller. Da nur der Z87-Chipsatz Raid zur Verfügung stellt, ist alles dort angeschlossen.

Die Platten sind in Größe/Wert identisch, da es die gleichen Modell sind (neu gekauft). Liegen tun die laut Hersteller bei max. read 530 | write 445 Mbit/s.

Ich bin gerade noch in der Arbeit aber in 1-2Std. lade ich nen Screenshot von AS-SSD hoch vielleicht hilft der mehr.

EDIT: So, Strippingsize hab ich die empfohlenen 128k genommen und hier noch der Screenshot:

 

[Holt]

Laut ASRock hat das Baord neben dem 6 Ports des Z87 noch "4 x SATA3 6.0 Gb/s connectors by ASMedia ASM1061", also nicht vom einem Marvell. Bis Du sicher, dass die SSDs am Z87 hängen? Dann wäre die Frage nach dem Stripping, wie groß hast Du das gewählt? Wenn das zu klein ist, leiden die maximale seq. Transderraten, denn die sollte nur etwas unter dem doppelten der Transferrate der einzelnen SSD liegen.

Eine anderes Problem könnte der DMI Flaschenhals sein, denn alles was am Chipsatz hängt, auch seine PCIe Rev. 2 Lanes, muss durch das dünne Nadelöhr DMI 2, was PCIe 2 x4 entspricht, also Brutto 20Gb/s und Netto so etwa 1.6 bis 1.7GB/s! Deshalb bringen mehr als 3 SDDs im RAID 0 ja auch keine besseren seq. Transferraten mehr.

 

[Ch3ck3rM0n]

Du bist auch überall Holt ^.^ gut, dass ich nur hier und in CB gepostet hab.. aber ja stimmt, ist von ASMedia..

Ja, bin sicher, dass es am Z87 hängt, weil die restlichen Platten vom ASMedia nur mit IDE/AHCI angesprochen werden können bzw. im Bios eingestellt werden kann..

Stripping wie gesagt 128k vom System als empfohlener Wert..

Jup, des mit dem Nadelöhr ist mir bekannt, darum auch nur zwei Platten (sollten ja nur meine alte SSD + VelociRaptor ersetzt)..

 

[Holt]

Hauptsächlich bin ich hier und bei CB, das reicht auch und wird mir manchmal schon zuviel.

Wenn es ein Marvell mit 4 SATA 6Gb/s Port gewesen wäre, dann wohl der 9230, der kann auch RAID 0 und sogar SSDs im RAID 0 trimmen (aber nur mit dem Mircosoft Treiber) und dann würde diese Werte auch gut passen, der kann nicht viel mehr als 750MB/s, halt was zwei PCIe Rev. Lanes so an Bandbreite Netto erlauben. 128k Stripping sollten auch passen. Benche mal mit ATTO und stell den Screen rein, vielleicht passiert bei Dir ja das gleiche wie in dem Review von zwei UP 256GB im RAID 0 bei tweaktown.com. Da schwankten die Werte bei den unterschiedlichen Zugrifflängen auch sehr, es gab also keine saubere Linie der Schreib- und Leseraten über die verschiedene Zugriffslängen.

- - - Updated - - -

TRIM funktioniert? Das hat Du mit TRIMCHECK getestet?

 

[Ismirlangweilich]

Mach mal einen Benchmark mit ATTO. Die Herstellerangaben für SSD beziehen sich eigentlich ausschließlich auf den ATTO Benchmark.

 

[Holt]

Das gilt zwar für fast alle SSDs, aber nur bei den Sandforce macht es wegen der Datenkompression und der extrem komprimierbaren Testdaten von ATTO einen sehr großen Unterschied. Es geht mir hier darum, wie die Transferraten bei den verschiedenen Zugriffslängen aussehen. Die Ultra Plus hat ja nur einen Controller mit 4 Kanälen, da kommt es dann bei einem RAID 0 halt eher zu Konflikten beim Zugriff, weshalb ich diese SSD nun wirklich nicht für ein RAID 0 ausgesucht hätte.

 

[Ch3ck3rM0n]

Ich hab den TrimCheck mal durchlaufen lassen und laut diesem ist Trim aktiv im RAID.. Angehängt hier der ATTO Benchmark, bringt aber auch nicht viel mehr positiveres..



Was meinst du mit 4 Kanälen?

 

[Holt]

Die Ultra Plus hat einen Controller mit nur 4 NAND Kanälen verbaut, den Marvell 9175, bei dem es sich offenbar um eine entsprechend abgespeckte Version des 9174 handelt. Damit können die internen Zugriffe, so eine SSD ist ja schon ein RAID 0 über diese NAND Kanäle, natürlich nicht über so viele NANDs verteilt werden und mehr Kanäle sind besser als mehr Dies im Interleave an einem Kanal. Das ist eben eine Budget SSD und Sandisk hat da am Controller gespart, denn irgendwie müssen sie ja auch einen Kostenunterschied zur Extreme II erreichen, die das High-End Modell im Consumer SSD Sortiment von SanDisk ist.

 

[Ismirlangweilich]

Anscheinend sind die Herstellerangaben für diesen Typ SSD stark übertrieben. Gut das du es nachgeprüft hast, eventuell hilft das anderen bei der Kaufentscheidung.

 

[Holt]

Das hat damit nichts zu tun. Der Intel RAID Treiber dürfte die einzelnen Zugriffe auf die Teile parallel absetzen, sonst würde er bei sehr kurzen Strippingsizes auch nicht so gute sequentielle Transferraten erzielen. Damit kommt aber die Ultra Plus nicht so gut klar, das ist bekannt und der Hersteller gibt ja auch nur die maximale seq. Transferraten bei langen Zugriffen (maixmal 4 bei ATTO) und die maximal IOPS mit 4k und einer hohen QD (meist 32) an. Bei einem RAID 0 können dann aber eben offenbar mehr parallele Zugriffe auftrauchen und die sind natürlich auch länger als 4k, nämlich meist so lange die das Stripping und damit damit kommt die Ultra Plus nicht so gut klar, was eben auch am Design mit einem 4 Kanal Controller liegt. Der reicht für eine Budget SSD im Prinzip ja, man sollte für ein RAID 0 nur eben auf sowas achten, wenn man die SSD auswählt.

Sonst bekommt man eben genau solche Ergebnisse, was leicht hätte vermieden werden können, aber manche User propagieren hier ja aus idiologischen Gründen bestimmte SSDs und verteufeln andere, was einer optimalen Auswahl natürlich im Wege steht.

 

[Ismirlangweilich]

Eventuell hilft es ja, das Raid Volume mit 64K oder 128K Blockgröße zu Formatieren im Windows bei einer Stripe Size von 128K.

 

[Holt]

Da schmeisst Du nun aber alles durcheinander! Blockgrößen sind bei SSD nur im NAND vorhanden und da kontruktionsbedingt, meist so 1MB oder 2MB. Das Stripping ist etwas vom RAID, was besagt wie viele Daten jeweils auf die eine und die andere Platte kommen, bevor die wieder wechseln. Was man beim Formatieren von Windows einstellt, ist die Größe der Zuordnungseinheit, auch Clustergröße genannt und die sollte man bei NTFS gefälligst bei 4k lassen, da Windows problemlos über mehrere Cluster adressiert und ein Cluster sowieso schon 8 LBAs entspricht, was die Einheit ist, mit der HDDs und SSDs adressiert werden.

Man verliert aber für jede Datei statistisch im Schnitt einen halben Cluster, so dass eine große Clustergröße zuerst mal eine gewaltige Verschwendung von Speicherplatz ist. Dann bringt ihm ein kleineres Stripping eher noch mehr Probleme weil es noch mehr parallele Zugriffe pro Daten ezeigt, weil einmal auch die kleineren Daten mit größerer Wahrscheinlichkeit über beide SSDs verteilt werden und die größeren in mehr kleine Stücke zerhackt werden, so dass noch mehr Zugriffe nötig sind. Ein Stripping von 128k passt schon und wenn, dann würde ich allenfalls eines mit 256k probieren.

 

[Ismirlangweilich]

So wie es ausschaut, hast du da was durcheinandergeworfen.

Bei meinen SSD ist die Sektorengröße physisch 512 Bytes wie bei vielen Festplatten auch. Neuere HDD haben 4K Sektoren. Was du meinst ist die NAND-Seitengröße.

Formatiert habe ich auf 32K oder 64K, genau weis ich es nicht mehr, Stripesize auf 128K. Die Speicherplatzverschwendung hält sich dabei in Grenzen, es sind bloß einige MB weniger auf dem Systemlaufwerk. Gegenüber der 4K Blockgröße ist die Geschwindigkeit schon höher. Klar das bei Dateien kleiner 32K bzw. 64K dann Platz verschwendet wird. Aber so viele sind das garnicht mehr bei Windows 7 im Vergleich zu früheren Windows Versionen. Ziel der Aktion ist es ja den Verwaltungsaufwand für das Dateisystem zu verringern und dadurch Geschwindigkeit zu erhalten. Im übrigen schreibe ich "Block" anstelle von "Cluster" da mir die von M$ erfundene Terminologie zuwider ist.

 

[Holt]

Was Du mut Sektorgröße meinst ist die Anzahl der Bytes pro LBA und die ist bei allen SATA HDD und SSDs bisher 512 Byte (bei SCIS + SAS gibt es auch noch z.B. 520 + 528, als Extrabytes für die Prüfsummen). Die Pagessize der NANDs ist egal, die erfährt man sowieso allenfalls aus den Datenblättern der verbauten NANDs, wobei aktuelle MLC NANDs 8k oder 16k pro Page haben.

"Formatiert habe ich auf 32K oder 64K ... Gegenüber der 4K Blockgröße" Nochmal, das ist keine Blockgröße, das ist die Clustergröße oder Größe der Zuordnungseinheiten und eine Sache des Filesystems! Da mehr als 4k zu wählen bringt bei NTFS nichts und wird von Windows erst ab 16TB vorgeschlagen, dann aber auch nur 8k! Das weiter zu vergrößeren verringert nur die Fragmentierung, aber das spielt bei SSDs sowieso keine wirkliche Rolle und ob da nun steht, die Daten beginnt bei Cluster 10204 und ist 9 Cluster lange oder es steht da das sie bei Cluster 1276 und ist 2 Cluster lang, spart überhaupt nichts.

Block statt Cluster zu verwenden ist auch komplett falsch, das hat auch mit MS nichts zu tun:

Ein Block umfasst heute meistens 512 (=2^9) Bytes, auf optischen Medien (CD-ROM, DVD-ROM) 2048 (=2^11) Bytes. Moderne Betriebssysteme fassen aus Performance- und Verwaltungsgründen mehrere Blöcke zu einem Cluster fester Größe zusammen. Heute sind Cluster mit acht oder noch mehr Blöcken üblich, also 4096 Bytes pro Cluster. Die Clustergröße ist im Allgemeinen eine Zweierpotenz (1024, 2048, 4096, 8192 usw.)

 

[Ismirlangweilich]

Block (data storage) - Wikipedia, the free encyclopedia
zum Vergleich
http://en.wikipedia.org/wiki/Data_cluster

Noch Fragen?

 

[Holt]

Da steht doch genau, was ich schreibe:

the filesystem does not allocate individual disk sectors by default, but contiguous groups of sectors, called clusters.

On a disk that uses 512-byte sectors, a 512-byte cluster contains one sector, whereas a 4-kibibyte (KiB) cluster contains eight sectors.

A cluster is the smallest logical amount of disk space that can be allocated to hold a file.

Und zu einem Block steht da:

a block, sometimes called a physical record, is a sequence of bytes or bits, having a fixed length (a block size).

Nur können PCs nur mit Sektoren zu 512 Bytes umgehen, zumindest intern über den SATA Controller, weshalb die Platten mit physikalischen 4k Sektoren und SSD eben immer 512 Byte Sektoren emulieren, also 512 pro LBA adressieren.

Also genau was ich geschrieben habe, wo ist das Problem? Block ist aber heute ein gebräuchlicher Begriff mehr, Cluster aber immer noch und der stammt nicht von Microsoft, den gab es schon vorher.

 

[Ismirlangweilich]

"Most file systems are based on a block device, which is a level of abstraction for the hardware responsible for storing and retrieving specified blocks of data, though the block size in file systems may be a multiple of the physical block size. In classical file systems, a single block might contain only a part of a single file. This leads to space inefficiency due to internal fragmentation, since file lengths are often not integer multiples of block size, and thus the last block of files will remain partially empty. This will create slack space, which averages half a block per file. Some newer file systems attempt to solve this through techniques called block suballocation and tail merging."

Das musst du auch lesen, nicht nur das herauspflücken, was dir in den Kram passt.

"A cluster is the smallest logical amount of disk space that can be allocated to hold a file. Storing small files on a filesystem with large clusters will therefore waste disk space; such wasted disk space is called slack space. For cluster sizes which are small versus the average file size, the wasted space per file will be statistically about half of the cluster size; for large cluster sizes, the wasted space will become greater. However, a larger cluster size reduces bookkeeping overhead and fragmentation, which may improve reading and writing speed overall."

Block = Cluster

Und Blocks gibts immer noch. Musst nur mal über deinen M$ Horizont hinaus gucken.

"The term cluster was changed to allocation unit in DOS 4.0. However the term cluster is still widely used." Was sagt dir das?

Der eine sagt Klo, der andere sagt Toilette, ein dritter sagt Scheißhaus. Bei M$ heißt das dann "iLoo™" und kostet einen Haufen Geld. Noch nie war scheißen so schön und so teuer.

 

[Ch3ck3rM0n]

Sorry, aber da muss ich jetzt Holt zustimmen. Ein Cluster besteht aus mehreren Blöcken. Ein Cluster ist nicht gleich ein Block. Andernfalls würde jeder Fachinformatiker - wie ich auch seit Juli 2013 bin - es falsch in der Schule gelernt haben bzw. lernen. Wenn du anderer Meinung bist bzw. mir/uns nicht glaubst, kann ich dir gerne ausm Keller mein Arbeitsblatt einscannen, wo dies sogar bildlich gut dargestellt wird. Wenn du es lieber Block nennst, kannst du dies gerne tun, aber in der Informatik ist Block ≠ Cluster! Soviel ist sogar bei mir hängen geblieben in den 2,5 Jahren Ausbildung und nur das mit den Kanälen bei den SSD-Controllern war mir neu, aber klingt logisch und verständlich.

 

[Holt]

Der eine ist Ingenieur, der andere Fachinformatiker und dem dritten ist langweilig, aber ich gebe es auf ihn zu bespaßen. Ich sehen auch nicht, wie seine falsche These ein Block wäre ein Cluster aus seinen Zitaten stützen will. Es kann natürlich mal passieren, dass ein Cluster genau einen Block umfasst, aber das ist ein Sonderfall und der berechtigt nicht zu der allgemeinen Anahme es wäre immer so. Obendrein spielt die Physikalische Sektorgröße heute keine Rolle mehr, da die Controller von HDDs und vor allem von SSDs diese verbergen und nach außen eine anderen Sektorgröße emulieren. Das sind bisher bei allen SATA Platten immer 512Byte, so viel wird pro LBA adressiert und deshalb ist es besser, das auch als LBA Große zu bezeichnen. Wie und wo das nun physikalisch auf dem Speichermedium liegt, ist dabei egal und eine ganz andere Geschichte.

Eine große Clustergröße verringert die Fragmentierung, kostet aber Platz, nur spielt die Fragmentierung bei SSDs keine wirkliche Rolle, jedenfalls um Längen weniger als bei einer HDD, Platz ist dagegen auf einer SSD immer noch um ein Mehrfaches teurer als auf einer HDD, weshalb es gerade bei SSDs totaler Unsinn ist bei NTFS eine andere Clustergröße als 4k zu wählen!

 

[Ch3ck3rM0n]

Ich hab mir mal den Begriff LBA gegoogelt und das geht schon ziemlich tief in die Festplattenmaterie aber soweit ich die Erläuterungen nachvollziehen konnte hast du selbstverständlich Recht.

Große Clustergrößen sind einfach unsinnig bei SSD, denn Fragmentierung existiert dort zwar, spielt aber im Großen und ganzen keine Rolle mehr, da keine mechanischen Teile vorhanden sind. Es kann einfach von überall ohne Geschwindigkeitsverlust bei SSDs ausgelesen werden, wo eine Festplatte einfach bei extremer Fragmentierung die Grätsche macht. Ist ja logisch, da Daten zuweit auseinander sind und ist der Lesekopf einfach überfordert mit von einem Punkt zum nächsten Hüpfen bis er alles Daten zusammen hat.

 

[Holt]

So ist es, aber bei extremer Fragmentierung kann auch die Performance einer SSD etwas leiden, denn dann wären im extremsten Fall die Dateien in Fragmenten von jeweils der Clustergröße, also 4k, unterteilt. Schau Dir die Durchsatzraten bei 4k an und vergleiche sie mit denn bei seq. Zugriffen, dann sieht Du schon einen unterschied und selbst wenn Windows und der Treiber dann die ganze Anforderungen für die Fragmente parallel stellen, was dann Transferraten wie bei 4k_64 ergeben würde, wäre es noch ein Unterschied.

Aber so eine extreme Fragmentierung bekommt man praktisch beim normalen Betrieb niemals erzeugt, schon gar nicht wenn immer erst Platz auf dem Filesystem erhalten bleibt und dann würde eine HDD schon wirklich auf dem Zahnfleisch krichen, da wäre der Performanceverlust dann aber um Zehnerpotenzen größer und extrem spürbar, während die SSD immer noch fast so schnell oder schneller als eine HDD ohne Fragmentierung wäre. Daher kann man also durchaus sagen, dass für SSDs Fragmentierung praktisch keine Rolle spielt!

 

[Ch3ck3rM0n]

PROBLEM GEFUNDEN:

Nachdem ich heute durch Zufall CrystalDiskInfo hab laufen lassen, fiel mir auf, dass eine der beiden SSDs nur mit SATA 300 angesprochen wurde. Nachdem ich kurz die Ports am Mainboard getauscht hatte lieferten die Platten plötzlich bei weitem mehr Lese/Schreib-Performance als zuvor. Somit kann ich die Platten doch wieder für ein RAID empfehlen und gebe aber den Tipp: Achtung beim Übertragungsmodus! (Siehe Screenshot)

 

[Trill]

Herrlich dieser Thread, da wird lamentiert bis der Arzt kommt, der Fehler war so einfach und doch ist keiner drauf gekommen, klasse!

 

[pajaa]

Laut ASRock hat das Baord neben dem 6 Ports des Z87 noch "4 x SATA3 6.0 Gb/s connectors by ASMedia ASM1061", also nicht vom einem Marvell. Bis Du sicher, dass die SSDs am Z87 hängen?

Es ist schlicht unmöglich, mit der Intel Console ein RAID auf Festplatten einzurichten, die nicht an einem Intel-Controller hängen.
Sicher geht auch ein controllerübergreifendes RAID, aber das ist dann ein reines Software-RAID via Windows und davon steht hier nichts.

 

[Holt]

Das ist klar, aber ich verstehe nicht, woher der SATA 3Gb/s Port kommt, denn der Z87 hat nur SATA 6Gb/s Ports und keinen einzigen SATA 3Gb/s Port und der Z87 steht in der Systeminfo des TE. Von daher kann ich diese "Lösung" nicht ganz verstehen. Hätte er einen Z77 wäre das die erste Frage, aber beim Z87 kann ein Port allenfalls auf 3Gb/s laufen, wenn er im BIOS entsprechend gedrosselt wurde.

 

[pajaa]

Ja, dem stimme ich zu. Soweit ich weiß, handeln Controller und Speichergerät den jeweiligen link speed selbstständig aus. Möglicherweise ist hier was "schiefgelaufen"?