5x SanDisk Ultra II 960 GB - Schreibperformance nicht identisch

  • Ersteller Ersteller DunklerRabe
  • Erstellt am Erstellt am
D

DunklerRabe

Gast
Mir sind die Ideen ausgegangen, daher wäre ich dankbar für Input!

Folgende Situation:
Fünf neue SanDisk Ultra II 960 GB eingebaut, angeschlossen an einem Adaptec 71605 (Firmware und Treiber aktuell von 06/2015) und als Raid 5 konfiguriert. Caching durch den Controller ist deaktiviert. Die Leseleistung des Arrays ist nicht beeindruckend, aber in Ordnung mit ca. 1 GB/s. Die Schreibleistung ist jedoch inakzeptabel mit ca. 100 MB/s. Es hat dann einen Moment gedauert, ich hab mit den Controllereinstellungen experimentiert, aber besser wurde es nicht, bis ich die SSDs dann gerade jeweils einzeln mal betrachtet habe.

Und dann wurde auch klar warum das Array nicht vernünftig performt, denn drei der fünf SSDs liefern nur inakzeptable Schreibleistungen. Eine ist grenzwertig schlecht und eine ist in einem Bereich, den ich akzeptieren würde. Die Firmware auf allen SSDs ist die gleiche und es gibt scheinbar auch keine aktuellere. Die Leseleistung ist bei allen gleich, im Rahmen der üblichen Schwankungen und Messungenauigkeiten.

Fällt jemanden dazu noch was ein? Ansonsten müsste ich mal Sandisk dazu befragen oder die Dinger zurückgeben.

sandiskultraii960gb.png
 
Also das ist echt seltsam. Du hast die SSDs aber dann immer am selben Port getestet, oder?
 
Nein, das waren fünf verschiedene Ports. Aber das kann ich ja schnell mal machen und die die gut performt gegen eine der schlechten tauschen.
 
Dann nimm dir jetzt eine schnelle und eine langsame und teste sie am selben Port.
Sehe gerade, ist ja alles auf einem Screenshot^^. Schon spät, sorry :evillol:.
 
Starke Qualitätsschwankungen der eingebauten Flashspeicher?
Was anderes kann ich mir im Moment kaum vorstellen.
 
@cocacola: Oder wie schon gesagt, der Port. Da warten wir doch erst mal den TE mit seinen Ergebnissen ab, bevor wir hier wild spekulieren
 
Ich habe Laufwerk D: und E: von Screenshot jetzt getauscht, das Ergebnis ist identisch. Es liegt also nicht an Unterschieden an den Ports.

Qualitätsunterschiede ja, hatte ich auch schon überlegt, aber dazu sind die Unterschiede eigentlich zu heftig. Das darf so doch niemals durch die QS gehen. Wäre aber ein Thema auf das ich SanDisk ansprechen werde, falls wir keine Lösung finden.
 
Ganz einfach: Nimm einen anderen Rechner und häng jede einuzeln rein. Dann weißt du Bescheid
 
habe in letzter Zeit auch nur Probleme mit meinen SanDisk Ultra II, so gerne ich sie habe, aber hatte in den letzten 3 Wochen 6 fehlerhafte Ultras, laufzeit zwischen 9-4 Monate, habe zwar alle in Garantie ausgetauscht, aber die hatten auch alle plötzlich massive perfomance Probleme. Werde bei gelegenheit mal sehen ob ich bei den "neuen " einen Test durchführen kann. bin gespannt was bei rauskommt.

scheint aber das die in den letzten serien fehlerhafte chargen haben
 
Ich sage jetzt mal ganz doof, für 100%-ige Sicherheit, damit SanDisk sich nicht raus redet: Teste an einem anderen PC.

Aber ehrlich gesagt können die 3 nur einen Schuss haben. Ist aber schon extrem auffällig, dass es 3 von 5 sind, aber vielleicht haben sie eine Charge versaut. Weil die 3 sind ja auch tatsächlich gleich schnell ... also langsam.
Klar, dass dein RAID 5 dann nix taugt :p.
 
Falls das im betreffenden Rechner geht vielleicht auch einzeln an einem nativen Sata-Port testen? Vielleicht ein schlechtes Zusammenspiel zwischen Controller und (manchen) SSDs.
 
CDM1.png

Also hab grad auch zum Spaß mal meine mit CDM getestet und ich hab da komischer weiße deutlich höhere Werte als du.
Edit: Bei mir ist es BTW auch noch die Systempartition.

Welche Firmware haben deine denn genau? Die X41100RL wie meine oder die "ältere"?
 
Zuletzt bearbeitet:
@DukeStylez: Mhh interessant! Wenn du es einrichten kannst deine mal zu testen wär das natürlich super, vorallem wenn du mehrere hast!

@Hopsekäse: Hab ich schon mal gemacht, Ergebnisse waren gleich. War ein nativer SATA 6G Port vom X99 Chipsatz. Im Zweifelsfall würde ich das noch mal mit allen machen um alle Ergebnisse zu verifizieren, dazu müsste ich die SSDs aber jeweils wieder aus ihren Hot Swap Trays raus schrauben. Im Moment bereite ich den Test in einem anderen Rechner vor, da sind die selben Wechselrahmen drin. Das mach ich zuerst, weils einfacher ist.

@Gorby @Hallo32: Meine haben alle die aktuelle X41100RL.

Ich muss gerade ein paar Daten in einem anderen System umherschaufeln, dann teste ich die SSDs dort noch mal.
 
Benche doch mal mit dem AS-SSD Benchmark, da sieht man auch gleich ob das Alignment stimmt und schau ob nicht einen verschlüsselt ist oder die NTFS Datenkompression aktiviert wurde. Den Schreibcache zu deaktivieren ist auch keine gute Idee, weil das zuweilen dazu führt, dass die Controller auch den Schreibcache der SSD deaktivieren. Schau auch mal ob es für alle SSD so aussieht:

schreibcache-png.536222


Also der Schreibcache nicht von Windows deaktiviert wurde und prüfe auch wie die Einstellung zum Cache beim Controller ist. Die Unterschiede dürften von unterschiedlichen Einstellungen kommen, nicht von den SSDs selbst, wobei natürlich SSD mit einem Pseudo-SLC Schreibcache auch unterschiedlich schnell sein können, je nachdem wie viel zuletzt geschrieben und oder das Cache noch voll ist.

Könntest Du auch mal mit TrimCheck prüfen ob TRIM an dem Controller funktioniert? Beim RAID 5 wird es kaum gehen, aber bei einzelnen Laufwerken könnte es sein, vielleicht aber nur bei den Serverversionen von Windows.

Was unter der Write Penalty bei einem RAID 5 zu verstehen ist, weiß Du hoffentlich auch.
 
Zuletzt bearbeitet:
DunklerRabe schrieb:
Fällt jemanden dazu noch was ein? Ansonsten müsste ich mal Sandisk dazu befragen oder die Dinger zurückgeben.

Das erste was du überprüfen solltest ist die Schreibleistung an einem normalen SATA Port und nicht an einem Raid Controller. Sandisk wird dir vermutlich genau das als erstes erzählen.

Danach die betroffenen Platten einmal über die Sandisk Software komplett löschen und nochmal testen.
 
Zuletzt bearbeitet:
Die schnelle und langsame SSD bringen in einem anderen System an einem LSI 9341-8i in etwa die gleiche Leistung und zwar auf dem Niveau der schnellen SSD.

Die Geschichte mit der Schreibcache Richtlinie hatte ich schon geprüft, war aber trotzdem der richtige Hinweis (hoffe ich). Darauf bin ich dann gerade auch gestoßen durch den LSI Controller, denn LSI regelt das anders (besser) als Adaptec.

Der LSI 9341-8i ist eigentlich ein Entry Level Modell. Der hat einen aktuellen LSI RoC, gestrichen wurde jedoch der Cache und der Support für Raid 6. Da man den Cache für SSDs sowieso nicht braucht ist der ideal für All Flash Arrays.
Wie bei den "großen" LSI Controller gibt es für den Schreibcache der Disks eine globale Einstellung "unchanged" und der Default ist enabled. Dieser Controller kann sogar ausschließlich "unchanged", eine Umgehung des lokalen Caches der angeschlossenen Disks supportet der gar nicht. Bei den Arrays sieht man das nicht, weil das Betriebssystem das nicht mehr dargestellt kriegt und auch gar keinen Einfluss darauf hat, da der Controller das übernimmt. Selbst wenn alle Laufwerke des Arrays ihren lokalen Cache enabled haben sagt Windows, dass der Schreibcache deaktiviert ist und ihn zu aktivieren ist nicht möglich. Aber eben auch nicht nötig, er ist ja schon enabled. Bei Single Drives, wie ich es gerade für den Test hatte, kann man durch den Default "unchanged" des Controllers die Einstellung aber auch über das Betriebssystem noch selbst bestimmen und weil es ein einzelnes Laufwerk ist kann Windows einem da auch noch anzeigen, dass der Schreibcache aktiv ist.
Und darüber hinaus gibt es dann die üblichen Read Ahead und Write Back Einstellungen für die Arrays, die mangels Cache am Controller aber sowieso hinfällig sind und gar nicht enabled werden können, was bei SSDs aber ja auch sowieso keinen sonderlichen Mehrwert bietet.

Adaptec benennt die Caching Einstellungen für die Disks und für die Arrays leider sehr ähnlich. Wenn man ein All Flash Array anlegen will weist der Controller darauf hin, dass Caching für solche Arrays nicht empfohlen ist und ob man "All Caching" nicht disablen möchte. Wenn man da "Nein" sagt, dann ist der Schreibcache für das Array, obwohl dieser Controller einen eigenen Cache hat, trotzdem deaktiviert und nur der Lesecache ist aktiv. Wählt man "Ja", dann wird der Lesecache auch abgeschaltet. Ich dachte das liegt daran, dass ich für den Write Cache schon global disabled vorgegeben habe. Hatte ich aber nicht, das war die Einstellung für die lokalen Caches der Disks. Und der Controller unterbindet auch bei Single Drives die Schreibcache Einstellung über das Betriebssystem.
Das habe ich nun umgestellt und baue das Raid 5 noch mal neu auf, dann schauen wir später mal ob da jetzt was geht.

Wenn die Performance dann besser ist, dann sind die drei langsamen SSDs die Baseline gewesen und die beiden schnellen sind die Ausreißer. Und nicht andersrum, wie ich zuerst dachte. Wäre dann aber interessant zu wissen warum die immer noch so schnell waren, denn die Einstellungen waren jederzeit für alle SSDs gleich.

Alignment ist übrigens korrekt und Verschlüsselung oder NTFS Kompression pfuscht da auch nicht rein. Wenn dich grundsätzlich noch interessiert wie das mit Trim aussieht kann ich das morgen noch mal prüfen. Und ja, ich bin mir der Write Penalty bei einem Raid 5 bewusst :)

@xexex: Im Zweifelsfall hätte ich das getan, wobei mir das ggf. halt auch nichts gebracht hätte. Wenn das ein obskurer Fall von "die SSDs performen halt an einem Raidcontroller nicht" gewesen wäre, was eigentlich nicht sein kann oder sollte, dann taugen die SSDs nichts und ich kann sie nicht gebrauchen. Dafür gibt es ja Standards wie SAS bzw SATA, der SSD hat es egal zu sein welcher Controller an dem Port hängt.
 
Zuletzt bearbeitet:
Welche Performancewerte hast Du nun? Mir scheint, dass das Problem für Dich gelöst ist, oder? Mich würden trotzdem mal die Werte Deines RAID-5 interessieren.

Nebenbei habe ich gerade meine 2 Wochen alte Sandisk Ultra II mal gebencht. Scheint durch die Bank weg schneller zu sein, als Deine beiden schnellsten:

CrystalDiskMark-Sandisk-Ultra-II.png
 
Zurück
Oben