Leserartikel Test des TRIM Supports der Marvell 91xx-Controller

Holt schrieb:
Da hatte ich einen kurzen Denkfehler und Du wohl auch. Der Unterschied ist, dass 80*1024*1024 = 83.886.080 (Kilo)Byte Flash installiert sind, aber nur 156.301.488 LBAs a 512 Byte 80.026.361.856 Byte zur Verfügung stehen. Der Unterschied ist für Verwaltungsdaten und Spare Area.

Stimmt, Anand spricht im Text von verbauten GigaBinärByte, in der Tabelle benutzt er aber nicht GiB als Abkürzung, wie es es richtig wäre, sondern GB.
Im X25-M Handbuch (kennste wah? ;) ) steht ja auch nur die Kapazität des vom User adressierbarem Bereichs in GB und nicht die tatsächlich verbaute Kapazität in GiB.

Jetzt ergibt das ganze dann auch mehr Sinn.

Wenn ich nun rechne sinds bei der X25-M 80GB G2 5.872.984.064 Byte bzw. 11.470.672 Sektoren nicht adressierbar, also für die Sparearea. Das sind 1.433.834 Pages oder 5.600,91... MB, "Windows-MB" ;) .
Und somit wird 6,83..% des verbauten Flashs als Spare verwendet, wie der gute Anand auch schreibt, nur Abkürzungen hatte er, wie gesagt, nicht richtig gehabt.


Holt schrieb:
Wenn man die SSD mit Randomschreibbzugriffen füllt, dann landen die Daten natürlich viel durchmischter im Flash und beim anschliessenden seq. Beschreiben während des Benchens muß der Controller ohne TRIm dann halt öfter auch noch Daten kopieren, schreibt also langsamer. Mit TRIM braucht er natürlich nichts zu kopieren, er weiß ja dann schon, dass die Daten alle ungültig sind und wird so schnell wie jetzt auch schreiben.

Beim Beschreiben der SSD ohne TRIM nach einem langem Random Write oder sequenziellem Write über die gesamte Kapazität arbeitet die SSD sehr verschieden. Was ich eigentlich sagen wollte, war dass ich mit sequenziellem Beschreiben meiner SSD wohl viel an PE-Zyklen gespaart habe.
 
Also, dein Thema heisst "Test des TRIM Supports der Marvell 91xx-Controller"

Ich plane, mir auch eine SATA3 Erweiterungskarte zu holen für meine SSD. Nun eine klitzekleine Frage von mir dazu:

Unterstützt der Marvell 88SE9123 TRIM in Verbindung mit dem Marvell Treiber - ja/nein?
 
Meine Ergebnisse, sowie dieser Artikel legen das nahe. Man könnte also "Ja!" sagen. ;)

Ich will hier im Thread keine Kaufberatung betreiben, deswegen nur ein Hinweis: Aber schau dir vorher genau an, welche SSD du mit einem Marvell kombinierst denn dieser zum Teil deutlich langsamer als native SATA-Ports aktueller Mainboards wie z.B. die Southbridge SB850 von AMD oder der P67 PCH von Intel.
 
Killermandarine, da der Marvell nur mit einer PCIe Lane angebunden wird, sollte man sich vorher genau überlegen ob man für die Karte auch in einen entsprechend schnellen Slot zur Verfügung hat. Die ASUS U3S6 löst das, indem dort ein Lane Multiplexer vier Lanes zu zwei zusammenführt und der Controller auch bei langsamen PCIe Lanes so mehr Bandbreite bekommt. Karten wie die ASRock SATA3 PCIe x1 Karte kann man nur bei AMD (ab 700er Chipsatz) oder Intel ab SandyBridge in einem PCIe x1 Slot sinnvoll betreiben, dann bei allen vorherigen Chipsätzen nur die Lanes der Graka schnelle Rev. 2 Lanes waren, auch wenn Intel die immer mit 500MB/s beworben hat, wobei man aber die 250MB/s in jede Richtung einfach zusammengezählt hat.
 
Ich glaube nicht dass man mit der kleinen Datenmenge (und dann auch noch sequenziell) einen aussagekräftigen TRIM Test durchführen kann. Da wird wohl eher die GC einsetzen und das Ergebnis verfälschen.

Hier mal meine Vorgehensweise beim Test der TRIM Funktionalität der Samsung 470 Series SSD:

Der TRIM-Test

Die Technik
Wenn im Betriebssystem eine Datei gelöscht wird, dann wird diese nur aus einem Index gelöscht und nicht mehr angezeigt. Auf der HDD oder SSD ist diese aber noch physikalisch vorhanden. Das ist auch der Grund, warum es so einfach ist, Dateien nach dem löschen wiederherzustellen. Diese Praxis hat aber bei SSDs einen Nachteil im Gegensatz zu HDDs.

Bei einer HDD wird dieser belegte Platz einfach irgendwann überschrieben. Bei einer SSD muss aber bereits belegter Platz immer zuerst gelöscht werden, bevor dieser Platz neu belegt werden kann. Aufgrund der Funktionsweise der SSDs sind immer mehrere Zellen und Blöcke zu noch größeren Einheiten zusammengeschlossen. Den sogenannten Erase Blocks.

Wenn also eine Zelle neu beschrieben werden soll, muss zuerst dieser ganze Block ausgelesen werden. Dann wird dieser komplette Block gelöscht. Danach wird der ausgelesene Erase Block in dem Bereich, wo die neuen Daten geschrieben werden sollen, modifiziert. Schlussendlich wird der modifizierte Erase Block wieder geschrieben. Das Ganze nennt sich im Fachjargon dann "read-modify-write".

Da dieser ganze Prozess sehr zeitaufwändig ist, sinkt natürlich die Performance eines SSD wenn solch ein Vorgang vorgenommen wird. Jetzt kommt das ATA TRIM Kommando ins Spiel. Beim Löschen im Betriebssystem wird dieser Befehl gleich ans SSD mitgesendet, um mitzuteilen, dass es die Bereiche als löschbar markieren kann. Wenn alle Zellen in einem Erase Block als löschbar markiert sind, kann bei einem erneuten Schreibzugriff teilweise direkt geschrieben werden bzw. entfällt das Modifizieren. Gegen Blockfragmentierung hilft TRIM natürlich nicht, deshalb ist es immer vorteilhaft wenn noch eine GC implementiert ist.


Die Ausführung
Um die TRIM-Implementierung zu testen, habe ich den TRIM-Support in Windows 7 manuell deaktiviert. Dann wurde das SSD mit dem Tool "freespacecleaner zweimal vollgeschrieben, damit alle Zellen und ein paar Reservezellen aus der Spare Area mindestens einmal beschrieben waren. Danach wurde mit dem Tool IOMeter ein 4k-64 random write Benchmark auf die volle Kapazität mit 45 Minuten Testdauer angewendet. Direkt darauf wurde die Partition gelöscht, um mit HDTune PRO eine Schreibzonenmessung durchführen zu können. Im Anschluss wurde TRIM wieder eingeschaltet und die Partition formatiert um den TRIM-Befehl für alle Sektoren an das SSD zu schicken. Als nächstes wurde die Partition wieder gelöscht um mit HDTune PRO eine zweite Schreibzonenmessung durchführen zu können.

Nach IOMeter
samsung470_hdtune_trimi6e9.jpg


Nach der TRIM Auslösung
samsung470_hdtune_trimk69m.jpg



Das Ergebnis
Wie man sieht funktioniert die TRIM-Implementierung in der Samsung 470 einwandfrei.
 
Inwiefern die GC bei diesem Versuch verfälschend sein?

Deine Methode ist gut, denn sie zeigt deutlicher, wie die Performance ohne TRIM sinkt. Ist auch kein Wunder, denn HDtune nutzt beim Write Benchmark in den Standardeinstellungen 64K Blöcke, was dann zu viel Read-Erase-Modify-Write und somit den starken Performanceeinbruch führt. Meine Testmethode ruft hingegen nur ein ein Erase-Write hervor, was zwar einen geringeren negativen Effekt auf die Leistung hat, aber genauso zuverlässig ist. (btw: 4k-64 Random Write 45 Minuten lang ist makaber ;P)

fernab davon:
Die Testergebnisse der Franzosen kann ich mittlerweile auch bestätigen.



X25-M@Marvell, TRIM OFF, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL):
Volle SSD wird halb geleert: mit WinHex 15.8 ist zu sehen, dass quasi alle Sektoren weiterhin belegt sind.

X25-M@Marvell, TRIM ON, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL):
Volle SSD wird halb geleert: ungefähr die Hälfte aller verfügbaren Sektoren sind freigemacht worden.

Das Formatieren der SSD leert übrigens quasi sämtliche Sektoren, egal ob TRIM aktiv ist oder nicht.
 
Zuletzt bearbeitet:
Hallo uNrEL2K,
erstmal danke für die Mühe und vor allem fürs korrekte veröffentlichen.
Hab auch deinen Beitrag im crucial forum gelesen und hab selbst was gefunden was es (vermutlich) bestätigt, nämlich ein Zitat einer eMail-Antwort eines Marvell-Mitarbeiters:
http://forums.legitreviews.com/about26072-20.html#p174807

Wäre toll, wenn das wer verifizieren könnte, vor allem der Unterschied Bypass / Raid Mode wäre hier interessant, wenn dort ein Unterschied besteht > Win, da der GC sich wohl bei RAID gleich verhalten dürfte wie bei Single, wenn ich richtig liege.
 
Hi Thion.
Zuerst einmal bedanke ich mich für dein Feedback.

Im Prinzip ist die Aussage ja folgenden: Läuft der Marvell im Bypass Mode (IDE o. AHCI) kann man die Microsoft IDE oder AHCI Treiber verwenden, um TRIM zu haben.

(Dass der Treiber TRIM weiterreichen muss damit es bei der SSD ankommt, ist ja bekannt.)

Läuft der Marvell im Raid Modus, muss die FW des Controllers auch mitspielen, das war damals noch nicht der Fall (Tue May 18, 2010), sollte aber durch ein Update nachgereicht werden.

Das sagt jetzt erstmal nichts darüber aus, ob der Marvell Treiber im AHCI Mode TRIM kann. Den Marvell den ich besitzte kann auch gar kein Raid, nur AHCI. Was Marvell da nachreichen wollte weiß ich nicht genau. Ob sie vorhatten, non-Member Disk TRIM-fähig zu machen oder ganze RAID-Arrays, ist für mich nicht ersichtlich.

Für mich steht aber fest: Marvell Controller im AHCI Mode mit Marvell Treiber: TRIM YES
 
Zurück
Oben