TEST

Test

OCZ Vector SSD mit Barefoot-3-Controller - Die OCZ Vector im Detail

Portrait des Authors


Werbung

Der Controller der OCZ Vector ist eine Eigenentwicklung des inzwischen zu OCZ gehörenden Indilinx-Teams und basiert auf einem ARM-Cortex-Prozessor. Mit dem PC verbunden wird das Laufwerk über ein SATA-6 Gb/s-Interface, mit dem NAND-Flash-Speicher kommuniziert der Controller gleichzeitig über acht Kanäle. Der in 25 nm gefertigte Speicher stammt dabei von IMFT, dem Joint Venture von Intel und Micron. Über die Haltbarkeit des Speichers macht man keine Angaben. Da OCZ ganze Wafer kauft und den Speicher selbst selektiert, kann man hier auch schwer eine Abschätzung machen. OCZ spricht jedoch von einer Schreiblast von 20 GB pro Tag über einen Zeitraum von fünf Jahren, die das Laufwerk aushalten können soll.

Der Barefoot-3-Controller (IDX500M00-BC)

OCZ verspricht, dass die Vector-Serie das bisher am ausführlichsten getestete (Consumer-)Laufwerk ist. Das schließt eine große Gruppe an Beta-Testern ein, die das Laufwerk bereits auf Herz und Nieren prüfen konnten. Außerdem soll jedes Laufwerk vor Auslieferung einem Burn-In-Test unterzogen werden. Auch will man die Qualitätsstandards für Firmware-Releases erhöhen, was beispielsweise durch längere Validierungszyklen erreicht werden soll. Das Vertrauen in die Vector drückt OCZ schließlich durch eine fünfjährige Garantie aus, das heißt, dass man hier nun gleichauf mit der Intel SSD 520 Series und Samsung SSD 840 Pro Series ist. Die Garantie gilt bei OCZ allerdings nur bis zu einer Schreiblast von insgesamt 36,5 TB – was oben genannten 20 GB pro Tag über fünf Jahre entspricht.

Cache (links), Controller (mitte) und Flash-Speicher

Die Platine der OCZ Vector ist beidseitig bestückt, wobei wir den üblichen Aufbau vorfinden: Auf der Vorderseite befinden sich neben dem Controller acht Flash-Speicher-Bausteine und ein Micron DDR3-Modul des Typs D9PFJ. Auf der Rückseite findet man weitere acht Speicher-Bausteine und ein weiteres DDR3-Modul. Insgesamt besitzt die OCZ Vector damit 512 MB Cache.

Als erstes möchten wir uns die Performance des Laufwerks unter starker Beanspruchung anschauen. Dazu haben wir wie immer ein Durchlauf mit HDTach auf dem frisch gelöschten Laufwerk durchgeführt:

hdtach-new

Was ist hier passiert? Normalerweise erwarten wir hier zwei nahezu horizontale Linien. Da der Flash-Speicher leer ist, sollte das Laufwerk über die komplette Kapazität die maximale Lese- und Schreibraten liefern können. Das ist hier jedoch nur für die Lese-, nicht für die Schreibrate der Fall. Letztere fällt nach etwas mehr als der Hälfte der Kapazität auf etwas weniger als die Hälfte ab und bleibt dort bis zum Ende. Ein weiterer Durchlauf bringt dann das erwartete Ergebnis:

hdtach-new-2

Weitere Durchläufe zeigen weiterhin das erwartete Verhalten. Wird das Laufwerk mittels Secure Erase gelöscht, lässt sich das Verhalten aus dem ersten Screenshot wieder reproduzieren. Warum sich das Laufwerk so verhält, ist nicht bekannt. Bei OCZ konnte man dieses Ergebnis bisher nicht reproduzieren, als Begründung nennt man unsere älteren BIOS- und Treiberversionen. Wie ein Treiberproblem sieht das Ergebnis für uns zwar nicht aus, da sich das Problem allerdings sozusagen von selbst löst, scheint es nicht weiter tragisch zu sein.

Dass es auch anderes gehen soll, zeigt unten stehender Screenshot, der direkt von OCZ stammt. Er wurde allerdings mit einem anderen BIOS, einem anderen SATA-Treiber und einer aktueller HD-Tach-Version erstellt. Die angesprochene Problematik tritt dort nicht auf:

hdtach ocz

 

Im nächsten Schritt lassen wir Iometer über die komplette Kapazität des Laufwerks laufen, um eine starke Beanspruchung (ohne TRIM) zu simulieren.

hdtach-used-1

Die Leserate bleibt im Wesentlichen stabil, die Schreibrate sinkt stark ab. Damit ist die OCZ Vector allerdings in guter Gesellschaft, denn auch andere (High-End-)SSDs brechen nach starker Belastung ähnlich oder sogar noch weiter ein. Das ist im Prinzip nicht weiter tragisch, denn in den wenigsten Systemen werden beide Faktoren, nämlich extreme Schreiblast und kein TRIM, gleichzeitig zusammenkommen. Falls doch, empfehlen sich für solche Aufgaben nach wie vor nur Laufwerke mit SandForce-Controller – diese kommen mit beiden Szenarien (auch gleichzeitig) sehr gut zurecht.

hdtach-used-2

Ein weiterer Durchlauf zeigt nun fast das umgekehrte Szenario: Die Schreibrate ist relativ konstant, während die Leserate eingebrochen ist. Jedoch steigt sie gegen Ende sogar noch leicht über das Ausgangsniveau. Eine einfache Erklärung für diese Ergebnisse wäre ein adaptives Verhalten des Controllers bzw. der Firmware, d.h. die Firmware passt sich dem geforderten Leistungsprofil an. Intel hat bei der SSD 320 ebenfalls adaptive Algorithmen eingesetzt, sodass die Leistung u.U. immer besser wurde, je länger das Laufwerk einem bestimmten Lastprofil ausgesetzt war.

Eine weitere mögliche Erklärung wäre der Zeitpunkt der Garbage Collection. Um eine hohe Schreibperformance zu erreichen, müssen möglichst viele leere Blöcke vorhanden sein. Steht TRIM nicht zur Verfügung (was bei den HDTach-Durchläufen der Fall ist), ist das Organisieren/Aufräumen der Blöcke deutlich aufwendiger bzw. ineffizienter, da der Controller keine Daten verwerfen kann. Bei der Intel SSD 510 konnte man sehr schön sehen, dass der Aufräumprozess stattfindet, während Schreibvorgänge ausgeführt werden. Die extrem ungleichmäßige Performance ist ein Zeichen dafür, dass der Controller ausgelastet ist - nämlich mit der Garbage Collection, d.h. dem Aufräumen der Blöcke. 

OCZ führt die Garbage Collection möglicherweise (hauptsächlich) während Lesezugriffen aus, was die schlechte Leseperformance im letzten Screenshot erklären würde. Da HDTach erst den Lese- und dann den Schreibtest durchführt, ist die Schreibperformance nach dem Lesetest und der (möglicherweise) ausgeführten Garbage Collection wieder auf Ausgangsniveau.

Welche der beiden möglichen Erklärungen bei der OCZ Vector nun zutrifft, können wir nicht mit Sicherheit sagen. Der Zeitpunkt der Garbage Collection spielt sicherlich eine Rolle, aber auch (teilweise) adaptive Algorithmen könnten eine Erklärung sein.

Quellen und weitere Links KOMMENTARE (31)