Leserartikel Test des TRIM Supports der Marvell 91xx-Controller

[uNrEL2K]

Test des TRIM Supports der Marvell 88SE91xx-Treiber

Durch eine Anregung von Holt habe ich mich dazu entschlossen, abermals zu untersuchen, ob der Marvell 9120, sowie der Marvell Treiber Trim unterstützen. Im Netz findet man leider gegensätzliche Aussagen, eine kleine von mir durchgeführte Untersuchung lies mich auch annehmen, der Marvell Treiber könne TRIM. Ich hoffe dieser Test bringt etwas Klarheit.

PS: Wer nicht weiß, was es mit TRIM auf sich hat, liest sich am besten Holt's Erklärungsversuch durch.

Das Testsystem:

OS:Win 7 Prof x64
CPU:i5-750 Rev B1 BLCK@160Mhz, Stromsparmechanismen aktiv (C-States & EIST)
MB: GA-P55-UD3 Rev. 1 BIOS-Ver: F9
RAM: 12 GB DDR3-1333 CL 9 (Kanalbelegung: Channel A & B: jeweils 1x2GB & 1x4GB)
SSD: X25-M G2 80GB FW: 02M3
HDD: 5x hd204ui Raid 5
SATA-Controller:

• Asus U3S6 Rev 1 (Marvell 9120 FW: 1.0.0.28), Drive Cache Mode on
• P55@Raid-Mode FW: v9.5.0.1037

Treiber:

• Marvell mv91xx 1.2.0.1002 (vom 07.03.2011)
• Intel Rapid Storage Technology 10.1.0.1008

Die Testmethodik:
Die SSD wird vom PCH (ehemals Southbridge) des Mainboards genommen und an den Marvell-Controller angeschlossen. Nach dem Systemstart und Vorbereitung wird 2 Minuten gewartet. Dann wird die SSD, welche bei mir als Systemlaufwerk im Einsatz ist unddaher zu ~75% belegt ist, mit einer ~18GB großen Filmdatei bis zum Rand befüllt (Quellaufwerk ist das RAID5). Als Kopierprogramm wird SuperCopier verwendet. Die dafür benötigte Zeit wird gestoppt (http://jumk.de/stoppuhr/) und die Schreibgeschwindigkeit wird mit dem Process Explorer der Sysinternals Suite überwacht.

Wurde der Film kopiert, wird er gelöscht (hier sollte TRIM einsetzten) und 2 Minuten gewartet, bevor der ganze Film nocheinmal kopiert wird.

Nach diesem 2ten Kopiervorgang wird TRIM OS-seitig über die Shell deaktiviert (fsutil behavior set DisableDeleteNotify 1). Danach wird der Film gelöscht und 2 Minuten gewartet, bevor die SSD erneut befüllt wird. Mit dieser Methode stellt man sicher, dass kein TRIM-Signal mehr an die SSD/den SATA-Controller-Treiber gesendet wird. Ohne die Deaktivierung von TRIM wird das Signal zwar gesendet, ob das der Treiber (von Marvell) jedoch an die SSD weiterreicht, ist ungewiss.

Damit ist der Marvell durchgetestet. Jetzt ist der PCH dran. Vorher wird aber mit der Intel Toolbox manuell getrimt. Somit kann man sich das 1. kopieren & löschen sparen, welches nur dazu dient, TRIM auszulösen, da die Toolbox die SSD, hängt sich am Marvell, nicht trimen kann.


Jetzt aber die Ergebnisse:

Die Ergebnisse sind hier als Diagramme, die die Schreibgeschwindigkeit während des Befüllens zeigen, zu sehen.
Ich habe, um die Ergebnisse festzuhalten, immer einen Screenshot über die gesamte Auflösung gemacht. Der Übersichtlichkeit wegen gibts also nicht direkt die Originalansicht meines Desktops, sondern nur auf Wunsch per Klick auf "Vollbild Desktop Screen", direkt unter dem jeweiligen Diagramm. Dort finden sich die anderen Informationen wie die gestoppte Zeit, Füllstand der SSD usw.

SSD@Marvell

1. Erstes Befüllen

Vollbild Desktop Screen


Dauer Kopiervorgang: 5:35 Minuten; 54 MB/s durchschnittliche Schreibgeschwindigkeit

Die Schreibrate hat schon in der ersten Hälfte einige Einbrüche. Komisch, denn die SSD wurde ja vor dem Anschließen an den Marvell-Controller ständig durch den Intel PCH getrimed. In der zweiten Hälfte bricht die Schreibgeschwindigkeit um die Hälfte ein und zum Schluss sogar noch weiter.




2. Zweites Befüllen (hat TRIM gewirkt?)

Vollbild Desktop Screen



Dauer Kopiervorgang: 4:58 Minuten; 60,6 MB/s durchschnittliche Schreibgeschwindigkeit

Die Schreibleistung bleibt konstant, bis zur zweiten Hälfte. Danach ist es eine Berg- und Talfahrt. Dennoch braucht die SSD 37Sekunden weniger Zeit. Ob TRIM tatsächlich ausgelöst wurde? Ein Vergleich mit dem PCH wurde guttun. Dieser folgt gleich, aber davor wird der Marvell mit deaktiviertem TRIM getestet.




3. Drittes Befüllen (Die Performance ohne TRIM)

Vollbild Desktop Screen


Dauer Kopiervorgang: 6:02 Minuten; 49,8 MB/s durchschnittliche Schreibgeschwindigkeit

Ohne TRIM performt die SSD am Marvell am schlechtesten.


SSD@PCH

1. Erstes Befüllen (hat TRIM gewirkt? )

Vollbild Desktop Screen


Dauer Kopiervorgang: 4:03 Minuten; 74 MB/s durchschnittliche Schreibgeschwindigkeit

Natürlich wurde getrimt, denn Intel unterstützt das Trimen ja seit langer Zeit und einigen Treiber-Versionen, auch wenn der PCH im RAID-Mode läuft. Die SSD darf nur kein Teil eines Raid-Verbunds sein. Man sieht daher eine gleichmäßig Schreibperformance. Der Leistungsabfall im Letzten Teil liegt wahrscheinlich mit hohen Füllstand zusammen. Ist eine SSD fasst vollständig gefüllt, verliert sie an Schreibleistung.

Vergleicht man nun diese Ergebnis mit des Marvells ("2. Zweites Befüllen (hat TRIM gewirkt?)"), fällt auf, dass der Marvell mehr Einbrüche zu verzeichnen hat. Aus diesem Ergebnis heraus auf fehlende TRIM Unterstützung zu schließen, halte ich aber für falsch, da die Ergebnisse doch eine gewisse Ähnlichkeit haben.



2. Befüllen ohne TRIM

Vollbild Desktop Screen


Dauer Kopiervorgang: 5:17 Minuten; 57 MB/s durchschnittliche Schreibgeschwindigkeit

Ohne TRIM kommt es erwartungsgemäß zu Performanceeinbrüchen. Diese treten quasi während des ganzen Kopiervorgangs auf, am Anfang jedoch nicht so stark wie im zur Mitte und Schluss. Die Performance ist etwas besser des Marvells mit deaktiviertem TRIM. Das lässt sich wahrscheinlich durch die allgemein schwächere Leistung des Marvells erklären.

Interpretation der Ergebnisse:

Die Deutung der Messwerte finde ich nicht einfach. Denn der Intel-PCH ist generell schneller als der Marvell-Controller. Somit kann man nicht einfach die Dauer der Kopiervorgänge vergleichen, und auf fehlendes oder vorhandes TRIM bei Marvell schließen. Beispielsweise schreibt der Intel mit TRIM off mit 57 MB/s, der Marvel jedoch nur mit 50 MB/s. In diesem Moment wird von beiden Controllern kein TRIM an die SSD weitergeleitet und dennoch ist die Schreibrate unterschiedlich.

Stellt man die Unterschied der Testergebnisse prozentual dar, erreicht der Marvell 8 bzw 20% mehr Leistung durch aktiviertes TRIM. Bei Intel sind es 30%.

Marvell
1. Test: 54 MB/s entsprechen 108%
2. Test: 60 MB/s entsprechen 120%
3. Test (Trim off) 50 MB/s entsprechen 100%

Intel
1. Test: 74 MB/s entsprechen 130%
2. Test: 57 MB/s entsprechen 100%



Wie man sieht, profitiert Marvell durch aktiviertes TRIM! Oder liegt es garnicht daran?



Was denkt ihr?

Tante Big Edit

Die ersten Testergebnisse waren doch nicht so eindeutig, als das sie genaue Rückschlüsse zuliesen. Aktiviertes TRIM des OS lies beide SATA Controller schneller schreiben, jedoch gab es starke Schwankungen der Messergebnisse. Der Marvell Controller war mit TRIM einmal 8%, dann wieder 20% schneller als ohne TRIM. Zudem war der Intel gleich 30% schneller.

Da die SSD bereits vorm' Befüllen zu 75% belegt war, musste sie während dem Vollschreiben immer mehr Daten schreiben, als neue dazugekommen sind. Viele Blöcke, die nur teilweise mit Nutzdaten gefüllt waren, wurden erst durch das Befüllen mit den neu hinzukommenden Daten der Filmdatei, komplett aufgefüllt. Waren die Pages der Blöcke ohne Nutzdaten nicht schon vor dem Befüllen gelöscht, so kam es zu dem aufwändigen Read-Delete-Modify-Write. Die Daten des zu beschreibenden Blockes wurden also in den Cache gelesen, der Block wurde gelöscht und erst dann wurden die Filmdaten + die bereits vorhandenen Nutzdaten wieder auf die leeren Pages geschrieben und haben somit den Block diesmal komplett aufgefüllt. Zu dem kopierten Film mussten also viele bereits vorhandene Daten nochmal neu geschrieben werden. Manchmal mehr (zB. Blockinhalt: 25%Nutzdaten, 75% frei), manchmal weniger (zB.75%Nutzdaten, 25% frei), denn der Füllstand ist von Block zu Block unterschiedlich (Prozentangaben sind frei erfunden, nur zur Verdeutlichung). Nach jedem Löschen der Filmdatei wurden die Daten durch die GC & das Wear-Leveling bestimmt wieder umsortiert. Das alles führte dann zu den Performanceschwankungen.

Soweit meine Auffassung Holt wird mich bestimmt korrigieren, sollte es Denkfehler geben.

Das ganze lässt sich aber umgehen, indem man eine "leere" SSD nimmt. Dadurch gibt es beim Befüllen entweder nur gelöschte Pages, also nur komplett freie Blöcke, oder eben, sollte das TRIM Kommando nicht ankommen, nur Blöcke, mit ungültigen Daten, welche erst beim Überschreiben gelöscht werden. Letzteres wäre dann einfaches Delete-Write, welches das Beschreiben etwas bremsen sollte, aber nicht stark. Sind die Pages/Blöcke frei, schreibt die SSD sofort auf den Flash. Sind noch ungültige Daten vorhanden, wird der Block vorher gesäubert durch ein Erase. Das Erase eines Blockes dauert nicht lange, in nur wenigen Millisekunden ist ein 512KB-Block der X25-M gelöscht. (In diesem Artikel von Anandtech aus 2009 sind es 2ms für MLC). Die Schreibgeschwindigkeit ohne TRIM sollte dadurch etwas leiden, aber nicht zu stark. Das wichtigste an diesem Versuch ist aber, dass jeder Test-Durchgang des selben Typs (TRIM ON bzw. TRIM OFF) von der Dauer und somit auch in der durchschnittlichen Schreibgeschwindigkeit quasi identisch sein sollte.
Auch die Einbrüche der Schreibrate wie hier sollten nicht mehr vorkommen.
Somit sollte sich diesmal ein klares Bild ergeben.

Soweit die Theorie und Analyse.
Auf zum Test Nr. 2

Das Testsystem:

hat sich etwas Verändert. Veränderungen in Rot.
Nicht das alle diese Veränderungen für das Testergebnis relevant wären, aber der Transparenz halber führe ich sie hier dennoch alle auf.

OS:Win 7 Prof x64@WD Scorpio Black (WD7500BPKT)
CPU:i5-750 Rev B1 BLCK@160Mhz, Stromsparmechanismen aktiv (C-States & EIST)
MB: GA-P55-UD3 Rev. 1 BIOS-Ver: F9
RAM: 12 GB DDR3-1333 CL 9 (Kanalbelegung: Channel A & B: jeweils 1x2GB & 1x4GB)
SSD: X25-M G2 80GB FW: 02M3
HDD: 5x hd204ui Raid 5
SATA-Controller:

• Asus U3S6 Rev 1 (Marvell 9120 FW: 1.0.0.28), Drive Cache Mode on
• P55@Raid-Mode FW: v10.5.0.916

Treiber:

• Marvell mv91xx 1.2.0.1002 (vom 07.03.2011)
• Intel Rapid Storage Technology 10.5.0.1015

Die veränderte Testmethodik:



1. Befüllen (secure erased, TRIM ON, @PCH)
Die SSD (am PCH) wird also mit einem Secure Erase komplett gelöscht und anschließend wird eine einzige Partition, über die gesamte verfügbare Kapazität angelegt, welche dann mit 2 BluRay-Isos & einer kleinen FLV-Datei befüllt wird (freier Speicher: 732KB). TRIM ist an.
Quelllaufwerk der Dateien ist wieder das Raid. Windows wird von der Western Digital ausgeführt, welche zu diesem Zeitpunkt am Marvell hängt, denn das Raid5 belegt mit der SSD zusammen alle nativen SATA-Slots des P55. Die Zeit wird gestoppt. Process Explorer zeigt den Transfer als Diagramm. Die Richtigkeit meiner Messungen/Berechnung kann anhand der Desktop Screenshots überprüft werden -> Downloadlink

Dauer Kopiervorgang: 15:17 Min:Sek
Mittlere Schreibgeschwindigkeit: 83,12 MB/s

Kommentar: Mit fast gleich bleibender Geschwindigkeit geschrieben. Keine Performance-Täler.



2. Befüllen (TRIM ON, @PCH)
Die zuvor kopierten Dateien werden gelöscht und nach 5 Minuten erneut auf die SSD geschrieben.

Dauer Kopiervorgang: 15:15 Min:Sek
Mittlere Schreibgeschwindigkeit: 83,31 MB/s

Kommentar: Selbes bild wie bei 1. Nur ein kurzer Einbruch, dessen Ursache ungewiss ist. Aber ansonsten deckt sich das Ergebnis mit den Erwartungen. Da nach dem Löschen der Dateien TRIM eingesetzt hat wurden alle Blöcke restlos geleert, und die SSD konnte wieder mit Fullspeed beschrieben werden.



3. Befüllen (TRIM OFF, @PCH)
TRIM wird deaktiviert, die zuvor kopierten Dateien werden gelöscht und nach 5 Minuten erneut auf die SSD geschrieben.

Dauer Kopiervorgang: 16:01 Min:Sek
Mittlere Schreibgeschwindigkeit: 79,32 MB/s

Kommentar: Die Kurve ist genauso gerade wie mit TRIM, aber sie liegt tiefer. Wie erwartet. Die Blöcke werden zwar erst unmittelbar vor dem Beschreiben geleert, aber keine alten Daten müssen in den Cache geholt werden bzw dann auch wieder auf den Flash zurückgeschrieben werden. Das Resultat des deaktiviertem TRIM und unmittelbarem löschen der Blöcke ist also eine um 3-4 MB/s verminderte Schreibleistung / ein 46 Sekunden längerer Kopiervorgang. Anfangs kann die SSD wahrscheinlich noch den Spare nutzen, um leere Blöcke direkt zu beschreiben. Dieser Bereich macht aber nur einen Bruchteil der verlangten Kapazität aus, weshalb wie eben bereits festgestellt, die Schreibleistung sinken muss, da viele Blöcke, welche direkt vom Nutzer ansprechbar sind, dennoch erst vor dem Beschreiben gelöscht werden.



4. Befüllen (TRIM OFF, @PCH)
Die zuvor kopierten Dateien werden gelöscht und nach 5 Minuten erneut auf die SSD geschrieben. TRIM ist immer noch aus.

Dauer Kopiervorgang: 15:57 Min:Sek
Mittlere Schreibgeschwindigkeit: 79,65 MB/s

Kommentar: Das selbe Spiel wie bei Punkt 4. Da TRIM immer noch aus ist und im Prinzip der selbe technische Ablauf wie bei 4. wiederholt wird, auch nicht weiter verwunderlich. Dauer & Geschwindigkeit sind quasi gleichwertig wie bei 4.



5. Befüllen (TRIM ON, @PCH)
TRIM wird wieder angeschaltet, die zuvor kopierten Dateien werden gelöscht und nach 5 Minuten erneut auf die SSD geschrieben.

Dauer Kopiervorgang: 15:18 Min:Sek
Mittlere Schreibgeschwindigkeit: 83,03 MB/s

Kommentar: Und somit ist die Schreibgeschwindigkeit wieder so hoch wie vorher. Der mysteriöse Einbruch ist wieder da. Naja, was soll man dazu sagen




Nun wird die SSD, nach einem Secure Erase, an den Marvell angeschlossen. Die Western Digital wandert an den PCH, wo zuvor die SSD dran hing.

Diesmal verzichte ich auf einige Diagramme, da sie nicht von den bisherigen Unterscheiden und somit nur Platz verschwenden. Stattdessen wird habe ich die Miniaturansicht verwendet, welche mit klick auf die Großansicht leitet.


1. Befüllen (TRIM ON, @marvell, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL)
Anschließend wird die SSD befüllt. TRIM ist an, immer noch.

Dauer Kopiervorgang: 15:32 Min:Sek
Mittlere Schreibgeschwindigkeit: 81,79 MB/s

Kommentar: Der Marvell schreibt minimal langsamer als der Intel. soweit so gut.



2. Befüllen (TRIM ON, @marvell, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL)
Die zuvor kopierten Dateien werden gelöscht und nach 5 Minuten erneut auf die SSD geschrieben. TRIM ist an.

Dauer Kopiervorgang: 15:26 Min:Sek
Mittlere Schreibgeschwindigkeit: 82,32 MB/s

Kommentar: Die Leistung bleibt erhalten. Ein gutes Zeichen für die Existenz der TRIM-Fähigkeit des Marvell-Treibers. Bleibt die Leistungs weiterhin bestehen?



3. Befüllen (TRIM ON, @marvell, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL)
Die zuvor kopierten Dateien werden gelöscht und nach 5 Minuten erneut auf die SSD geschrieben. TRIM ist an.

Dauer Kopiervorgang: 15:33 Min:Sek
Mittlere Schreibgeschwindigkeit: 81,70 MB/s

Kommentar: Ja, die Leistung bleibt bestehen. TRIM ist da Wie sieht es mit OS-setitig deaktiviertem TRIM aus?



4. Befüllen (TRIM OFF, @marvell, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL)
TRIM wird deaktiviert, die zuvor kopierten Dateien werden gelöscht und nach 5 Minuten erneut auf die SSD geschrieben

Dauer Kopiervorgang: 16:13 Min:Sek
Mittlere Schreibgeschwindigkeit: 78,34 MB/s

Kommentar: Man sieht mehr (Zitat mit Dauer & Speed) oder weniger deutlich (Diagramm) einen kleinen, aber deutlichen Leistungsverlust durch deaktiviertes TRIM. Wird TRIM nun wieder aktiviert, sollte die Leistung wiederhergestellt sein.



5. Befüllen (TRIM ON, @marvell, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL)
TRIM wird wieder aktiviert, die zuvor kopierten Dateien werden gelöscht und nach 5 Minuten erneut auf die SSD geschrieben

Dauer Kopiervorgang: 15:24 Min:Sek
Mittlere Schreibgeschwindigkeit: 82,49 MB/s

Kommentar: Und so ist es auch. Zur Verifizierung folgen noch zwei Durchläufe.



6. Befüllen (TRIM ON, @marvell, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL)
Die zuvor kopierten Dateien werden gelöscht und nach 5 Minuten erneut auf die SSD geschrieben

Dauer Kopiervorgang: 15:34 Min:Sek
Mittlere Schreibgeschwindigkeit: 81,61 MB/s

Kommentar: Leistung satt dank TRIM



7. Befüllen (TRIM OFF, @marvell, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL)
TRIM wird wieder deaktiviert, die zuvor kopierten Dateien werden gelöscht und nach 21:13 Minuten erneut auf die SSD geschrieben (Hatte verpennt die Dateien rechtzeitig zu kopieren. Dieses Missgeschick hat aber keinen Einfluss auf das Ergebnis)

Dauer Kopiervorgang: 16:17 Min:Sek
Mittlere Schreibgeschwindigkeit: 78,02 MB/s

Kommentar: TRIM aus = langsamer



Zusammenfassung der Testergebnisse:

Intel PCH

nach secure erase 15:17 83,12 MB/s
2tes Befüllen TRIM ON 15:15 83,31 MB/s
3tes, TRIM OFF 16:01 79,32 MB/s
4tes, TRIM OFF 15:57 79,65 MB/s
5tes, TRIM ON 15:18 83,03 MB/s

Durchschnitt TRIM ON 15:16 83,15 MB/s entsprechen 105% oder 100%
Durchschnitt TRIM OFF 15:59 79,49 MB/s entsprechen 100% oder 95,6%


Marvell 9120, Treiber: Marvell 88se91xx 1.2.0.1002 WHQL

nach secure erase 15:32 81,79 MB/s
2tes, TRIM ON 15:26 82,32 MB/s
3tes, TRIM ON 15:33 81,70 MB/s
4tes, TRIM OFF 16:13 78,34 MB/s
5tes, TRIM ON 15:24 82,49 MB/s
6tes, TRIM ON 15:34 81,61 MB/s
7tes, TRIM OFF 16:17 78,02 MB/s

Durchschnitt TRIM ON 15:30 81,98 MB/s entsprechen 105% oder 100%
Durchschnitt TRIM OFF 16:15 78,18 MB/s entsprechen 100% oder 95,3%

Endgültiges Fazit:

Ich denke diesmal kann man ein eindeutiges Fazit formulieren und mit Sicherheit sagen, dass der aktuelle Marvell-Treiber TRIM definitiv unterstützt. Ohne TRIM schreibt die SSD um 4,4% (Intel) bzw. 4,7% (Marvell) langsamer als mit. Durch nachträgliches aktivieren des TRIM normalisiert sich die Geschwindigkeit wieder. Beim Intel keine Überraschung, beim Marvell hat man nun endgültig Gewissheit. Vielleicht hättens auch weniger Diagramme und Messungen getan, aber ich wollte diesmal sicher gehen und mein Eifer war unbezwingbar


Anhang

Download Link Treiber: Marvell 88se91xx 1.2.0.1002 WHQL

 

[Killermandarine]

TRIM hängt nicht vom Controller ab, sondern vom Treiber..

Also unterstützt eigentlich jeder Controller Trim, wenn man den msahci Treiber verwendet.

Wo kann man sich eigentlich den Marvell Treiber runterladen?

 

[uNrEL2K]

OK, die Überschrift passt nicht ganz. Ändern lässt sich das nun leider nicht mehr.

Die gibts immer auf station-drivers.com. (Runterscrollen)

 

[HisN]

In der Fred-Übersicht rechts neben den Titel klicken. Dann müsstest Du ihn ändern können.

 

[uNrEL2K]

Ich weiß nicht, wo ich klicken soll
Kannst du einen Screenshot posten?

 

[Holt]

uNrEL2k, die Unterschiede sind in der Tat nicht so groß, als dass man es eindeutig sagen kann. Dazu kommt ein Effekt, dass die Daten beim Schreiben großer seq. Dateien auch im Flash umsortiert werden. Die Intel haben ja ein mittelmäßig agressives GC, weshalb es im Ausgangszustand sicher einige Blöcke gab, in denen noch sowohl gültige als auch ungültige Daten standen und die mußte der Controller eben bei steigendem Füllstand dann auch während des Schreibens zunehmend löschen und dabei die gültigen Daten umkopieren. Problemstisch ist weiterhin, dass Du natürlich einen großen Teil der Kapazität während des Tests garnicht gelöscht hast, klar ist ja auch Deine System SSD. Nur führt dies halt wieder zu dem Effekt, dass die SSD auch nach dem Löschen mit TRIM wieder Blöcke hat, die teilweise gültige und teilweise eben ungültige Daten enthält, aber wohl halt in einem Verhältnis, dass der Controller sie im GC eben noch nicht wieder löscht, die WA soll ja auch klein gehalten werden. Das Löschen muß er aber dann bei steigendem Füllstand wieder machen, sonst würde ihm ja die Kapazität fehlen und somit brechen auch mit TRIM die Transferraten eben wieder ein und man erkennt eben nicht, ob er vor dem Schrieben schon wußte, dass diese Pages ungültige Daten enthielten (die TRIM Befehle angekommen sind) oder ob er dies erst mit dem Überschreiben der LBAs erfahren hat (er also keine TRIM Befehle erhielt).

Ein Test über die gesamte Kapazität liefert sicher ein klareres Bild, denn nach dem Löschen aller Daten sind dann für den Controller nur noch Pages mit für ihn gültigen Daten (kein TRIM, GC kann nur wenige Blöcke löschen) oder ungültige Daten (TRIM aktiv, GC kann die ganze Kapaiztät wieder freimachen) vorhanden und wenn man nach dem Erstbefüllen ein paar GB löscht und neu beschreibt, dann sollten auch keine freinen Pages mehr vorhenden sein (SSDs haben ja immer etwas mehr Kapazität als man beschreiben kann und die Blöcke mit noch freien Pages werden ja auch möglichst nicht gelöscht).

Außerdem bin ich mir nicht sicher, ob fsutil behavior set DisableDeleteNotify augenblicklich oder erst nach einem Neustart wirkt, den hast Du aber nicht gemacht, oder?

 

[uNrEL2K]

Holt, was du schreibst, kann ich nachvollziehen. Ich werde dann mal ein Backup der SSD machen und kurzzeitig mein OS auf eine HDD verlagern. Dann wird die SSD komplett Platt gemacht und nochmal gefoltert. Aber sie wird das schon packen, die SMART-Werte speziell die Host Writes sehen noch sehr gut aus

TRIM sollte durch Fsutil mit sofortiger Wirkung an bzw. aus geschaltet werden. Ansonsten hätte die SSD am PCH nicht den Leistungseinbruch erfahren. Wäre TRIM noch aktiv gewesen, sähe das letzte Diagramm (2. Befüllen ohne TRIM) genauso aus wie das davor (1. Erstes Befüllen (hat TRIM gewirkt? )

 

[Holt]

uNrEL2k, ich bewundere ein Engagement, ganz ehrlich! Die Forumsgemeinde wird es Dir hoffentlich danken, ich auf jeden Fall. Kostet zwar ein paar PE Zyklen, aber das sollte der Lebensdauer Deiner SSD nicht merklich schaden.

 

[uNrEL2K]

Ich danke dir Holt für das Lob. Es gibt doch einige die zb die U3S6 in Verbindung mit einer C300 betreiben, für diese Leute könnten die Ergebnisse durchaus von Nutzen sein. Die Tests laufen auch mittlerweile auf Hochtouren. Zum Glück ist die Schreibleistung der Intel's konstant , sonst würden die Befüllungen noch länger dauern. Dann gibts auch bald die eindeutigen Ergebnisse.

 

[DoubleJ2k]

Die Schreibleistung einer Intel SSD ist nicht für alle Zeiten konstant. Lange genug mit Iometer draufhämmern und es gibt deutliche Einbrüche, siehe hier (unten).

Seq. Schreiben löst bei Intel außerdem die GC aus, mehrmals hintereinander ausgeführtes Schreiben gibt also immer bessere Ergebnisse - auch ganz ohne TRIM.

 

[uNrEL2K]

Ich wollte eigentlich nur einen Insider loslassen. Und Witze werden nicht erklärt. Aber ein paar Stichworte geb ich dir als Hinweis

Sandforce
Durawrite
Nach einmaligem Beschreiben

 

[DoubleJ2k]

Und wo war der Witz? Steady-State-Performance nennt man das. Oh, das gibt es bei den Intels auch.

 

[uNrEL2K]

Die Sandforces drosseln die Schreibgeschwindigkeit nach dem einmaligem Befüllen aller Pages um ca. 30 Prozent. Das lässt sich nur durch ein Secure Erase beheben, und selbst dann bleibt die Schreibperformance nur so lange erhalten, bis die alle Pages wieder einmal befüllt wurden. Das ist bei den Intels nicht so.

Wenn ich meine leere Intel SSD nehme, alle Pages frei, und sie komplett vollschreibe, die Daten lösche und das selbe noch einmal tue, so geht das Befüllen genauso schnell wie beim ersten mal, da TRIM die Intel dazu veranlasst, quasi alle Pages zu Erasen.
Machst du das mit einer Sandforce, hilft dir auch das TRIM nicht, da die Pages eben nicht erased werden, sondern erst beim erneuten Beschreiben. Das führt dann zu der Reduktion der Schreibleistung.

btw: http://lmgtfy.com/?q=Sandforce+ +Durawrite+ +Nach+einmaligem+Beschreiben
Erstes Ergebnis

 

[DoubleJ2k]

Ja, und jetzt? Ich weiß, wie SandForce-Laufwerke funktionieren. Intels zeigen das Verhalten beim seq. Schreib nicht, die 320er zeigen es aber z.B. bei random 4K write. Die Herstellerangabe erreicht man erst nach 100 Minuten Dauertest. Schreibt man dann wieder sequenziell, fällt die 4K-Leistung wieder.

Und wo der Witz war, frag ich mich immer noch. Dass die Schreibleistung bei SF einbricht gilt außerdem auch nur für inkompressible Daten. Schreib Nullen und sie erreichen praktisch immer die Herstellerangabe.

 

[uNrEL2K]

Zum Glück ist die Schreibleistung der Intel's konstant , sonst würden die Befüllungen noch länger dauern.

Eine spöttische, nicht ganz ernst gemeinte bzw. sachliche Äußerung.

Wenn du darüber nicht schmunzeln, lachen oder whatever kannst, ok. Mein Humor. Zurück zum Thema.

Ergänzung (24. April 2011)

Weitere Test im Ersten Beitrag ergänzt.

 

[Madnex]

@uNrEL2K
Was noch interessant wäre, wenn du den Marvell Kontroller mal mit dem Standard-AHCI-Treiber von Windows testen würdest. Da dieser definitiv Trim unterstützt wären die Ergebnisse vielleicht aufschlussreicher.

 

[uNrEL2K]

Ich weiß, viel Text, aber ich denke was ich beweisen wollte (Kann der Marvell Treiber TRIM?), habe ich getan. Lasse ich TRIM OS-seitig an, bleibt die Leistung am Marvell auch gleich (dank TRIM-Support des Marvell-Treibers). Erst nach mit deaktiviertem TRIM sinkt die Leistung.

 

[Holt]

Und wo war der Witz? Steady-State-Performance nennt man das. Oh, das gibt es bei den Intels auch.

Nein, das gibt es nur bei SF, solltest Du aber besser wissen, oder arbeitest Du denn nicht bei OCZ?

Das jede SSD unter bestimmten Umständen nicht immer die gleiche Leistung erbringt ist jedem hier klar, aber keine andere SSD außer denen mit SF Controller läßt sich nur mit Secure Erease wieder auf die Ausgangsschreibleistung bringen.

 

[uNrEL2K]

Holt hat mir per PM geantwortet und mit seinem Einverständnis zitiere ich ihn hier im Thread, da die Diskussion möglicherweise den einen oder anderen User interessiert.

Hallo uNrEL2K, die Unterschied sind ja wirklich erstaunlich gering aber zuverlässig reproduzierbar. Das immer wieder identische seq. Pattern beim Beschreiben dürfe die Ursache sein, warum diese Annahme wohl gestimmt hat: "Die Blöcke werden zwar erst unmittelbar vor dem Beschreiben geleert, aber keine alten Daten müssen in den Cache geholt werden".

Möglicherweise dauert ein SecureErase ungefähr genauso lange, wie sich die Zeit zum Befüllen der SSD durch deaktviertes TRIM verlängert. Aus der Erinnerung und dem Gefühl heraus ist das so . Ich schau da nochmal Der Secure Erase dauert nicht wirklich lange. Auch hat sich die Dauer des Befüllens nicht erheblich erhöht. Läuft ein SecureErase sequenziell (block nach block) oder parallel (mehrere blöcke werden gleichzeitig gelöscht)?

Ohne TRIM und vollgeschrieben hat die SSD ja im ersten Moment nur die paar hundert MB (GB sind es bei der X25 ja nicht einmal) Extrakapazität zum Beschreiben zur Verfügung und zu denen kommen dann wieder die gerade geschriebenen LBAs (bzw. die Pages auf die diese gemappt sind).

Im Moment zweifel ich sogar über die Existenz einer Spare Area bei der X25-M. Siehe hier http://www.anandtech.com/show/4202/the-intel-ssd-510-review/2
Verbaute Kapazität: 160GB bei der 160erbzw. dann auch 80GB bei der 80er Version. 80GB macht dann ~74,4GiB, so groß ist auch die Partition unter Windows. Sprich, die gesamte Verbaut NAND Kapazität ist vom Nutzer ansprechbar und somit belegt eine Partition welche über diese Kapazität verteilt ist, die gesamten verbauten Flash. Wo ist die SpareArea?

Anand foltert die SSDs deswegen wohl auch mit Random Writes, die für den Controller deutlich schlechter zu handhaben sind und daher auch die WA stark erhöhen. Das ist natürlich deutlich aufwendiger zu realisieren, da man die SSD dann bei jedem Durchlauf zweimal füllen muß, einmal mit (parallelen) Random Writes und dann zum Messen erneut.

Damit wären die Performanceverluste mit TRIM OFF wohl deutlich höher ausgefallen. Nicht gut für meine SSD .

Welchen Treiber hast Du bei den Tests am Marvell verwendet? Könntest Du das ggf. in der Liste 1-7@Marvell noch mal in die Überschrift aufnehmen?

Habs in den Überschriften ergänzt und noch einen Downloadlink als Anhang angefügt. Es war der Marvell 88se91xx 1.2.0.1002 WHQL Treiber.

 

[Holt]

Im Moment zweifel ich sogar über die Existenz einer Spare Area bei der X25-M. Siehe hier http://www.anandtech.com/show/4202/the-intel-ssd-510-review/2
Verbaute Kapazität: 160GB bei der 160erbzw. dann auch 80GB bei der 80er Version. 80GB macht dann ~74,4GiB, so groß ist auch die Partition unter Windows. Sprich, die gesamte Verbaut NAND Kapazität ist vom Nutzer ansprechbar und somit belegt eine Partition welche über diese Kapazität verteilt ist, die gesamten verbauten Flash. Wo ist die SpareArea?

Da hatte ich einen kurzen Denkfehler und Du wohl auch. Der Unterschied ist, dass 80*1024*1024 = 83.886.080 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.

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.