News AMDs AHCI-Treiber mit TRIM-Unterstützung

[iron_monkey]

@ Aeroloko

Wir erinnern uns, AMD hatte aber für 2-3 Tage oder kürzer den 263er und dann mal wieder den 275er in den Treiber drin, im Netz angeboten. Bei beiden, so erinnere ich mich, war TRIM für die 7xx laut "amd_sata.inf" gegeben.

Danke, tatsächlich hab ich sogar noch beide zur Auswahl bei der Treiberaktualisierung von Windows :-D

Hab es gerade ausprobiert...

Auf meinem 790FX Chipsatz dauert das Booten mit dem MS-Treiber deutlich länger, so 30 Sekunden passiert beim Windowslogo dann nichts mehr... kein Zugriff auf die SSD...

Auf meinem 740G Chipsatz bootet Win7 aber ohne Verzögerung mit dem MS-Treiber... hmm...

sehr komisch...

 

[VOODOO-KING]

ich bin eben von .269 auf .275 gewechselt und meine Atto Schreib/Lesewerte haben sich teilweise bis um 5000 verbessert. Jetzt wäre halt noch interessant zu wissen, ob Trim auch mit der SB710 aktiv ist bei Verwendung der 275er Version? Gibt's da schon neue Erkenntnisse?

MSI C45 (SB 710) + OCZ Vertex2 60GB...

 

[DoubleJ2k]

1.) Hier könnte auch was anderes auf die Platte zugreifen, man weiß also nicht, warum die LED wirklich leuchtet.

Wenn man gerade nichts am PC macht und die HDD LED "auf einmal" für mehrere Sekunden permanent leuchtet - und das reproduzierbar - funktioniert die Methode schon sehr gut.

3.) Je nach Implmentierung muß ja der Controller das Löschen der frei gemeldeten Blöcke nicht sofort ausführen. Dies ist sogar nachteilig, weil dann die SSD nach dem Löschen einer Datei erstmal beschäftigt ist und nicht sofort mit voller Performance genutzt werden kann. Wenn gerade gelöscht wird, so arbeiter der Rechner aber und man möchte jetzt keinen Leistungseinbruch. In der Praxis warten die Controller mit dem GC also ab, bis die Nutzung eine Weile ausbleibt um erst dann eine GC durchzuführen.

Nach meinem Stand (laut SandForce) löscht kein Controller die Daten sofort, sondern erst bei einem erneuten Schreibvorgang. Und auch erst beim erneuten Schreiben wird die GC aktiv, kann man bei Intel Laufwerken sehr schön sehen, wenn man einen Schreibbenchmark über die komplette Kapazität bei einem abgenutzten Laufwerk macht. Dann gibt es ganz viele Peaks mit niedriger Transferrate -> der Controller verschiebt erst andere Daten, bevor er den Schreibvorgang ausführt. Im Leerlauf sollte eine SSD keine Daten umsortieren. Das führt nämlich zu einer exorbitanten Write Amplification und ist wohl auch der Grund dafür, warum Indilinx-Laufwerke so schnell so eine hohe Zell-Abnutzung erreichen...

 

[Moros]

Nochmal eine Klarstellung zum "LED-Test":
Er funktioniert ausschließlich mit Indilinx-SSDs, da der Controller Blöcke mit nicht-validen Daten sofort freigibt bzw. löscht. Mit einer C300 oder einer SandForce-SSD funktioniert dieser Test nicht!

 

[Relict]

Hmm, gut zu wissen, doch leider sind wir damit auch wieder am Ausgangspunkt zurück. :/

 

[DoubleJ2k]

Mit einer C300 oder einer SandForce-SSD funktioniert dieser Test nicht!

Mit einer SandForce geht das auch - obwohl die Blöcke nicht gelöscht werden.

 

[Moros]

Da sieht man doch aber nichts, hab's gerade getestet.

 

[DoubleJ2k]

Bei mir klappts, soll ich ein Video machen?

 

[Bob.Dig]

Wie viele Sekunden braucht es denn bei Sandforce?
Video? Immer gerne DoubleJ.

 

[Moros]

Auf welchem System denn? Mit dem aktuellen iastor und einer XLR8 Plus auf einem EP45-UD3P geht's bei mir nicht.

 

[DoubleJ2k]

ADATA S599 3.1.0, RST 9.6, 10 GB Testdatei, LED leuchtet für ~10 Sekunden.

Habs eben gerade mehrmals hintereinander getestet, TRIM an, TRIM aus, LED brennt nur für mehrere Sekunden wenn TRIM an ist.

 

[Moros]

Kannst du's mal mit dem RST 10.1 testen? Den verwende ich. Die XLR8 Plus hat bei mir die FW 3.4.

 

[DoubleJ2k]

Auch mit dem RST 10 das gleiche Verhalten.

 

[Krik]

Könnte das nicht eventuell ein Effekt des Windows-Caches sein, der bei euch verschieden reagiert?

 

[DoubleJ2k]

Was soll der Windows-Cache damit zu tun haben?

 

[Aeroloko]

Interessant:

Vorweg:
Ich habe einen 710er Chipsatz von AMD.

Ich habe eine Intel Postville 80GB und das Intel tool am laufen und folgendes ausprobiert:
---------------------------------------------------------------------------------------------------

AMD_AHCI Treiber 125er

→ INTEL toolbox erwähnt SOFORT:
TRIM = This tool is not supported on the selected drive.


AMD_AHCI Treiber 263er

→ INTEL toolbox erwähnt NACHDEM ich den Optimizer ausführen möchte:
TRIM = Stopped | Cannot run the Intel SSD Optimer on RAID configurations.

Das gleiche beim 275er wie beim 263er.


Resultat:
Beim 125er blockt das Intel tool sofort ab, bei den anderen zwei sagt er nur, das er es nicht auf einer RAID Konfiguration durchlaufen lassen kann.

Was können wir daraus folgern?
Vorschläge?!

 

[ExBergmann]

Tach auch...

sagt mal, Ihr redet immer von LED-Test...kann das sein,
das es bei mir nur Leuchtet wenn die HDD sich beschäftigt?

Hab ich was falsch angeschlossen?

Beim Win-Boot...oder zugriff auf SSD, kein erleuchten...


gruss

Markus

 

[Holt]

Wenn man gerade nichts am PC macht und die HDD LED "auf einmal" für mehrere Sekunden permanent leuchtet - und das reproduzierbar - funktioniert die Methode schon sehr gut.

Die Frage ist doch, wann leuchtet die LED? Normalerweise wird sie vom MB angesteuert und kann damit nur leuchten, wenn der SATA Controller Daten von bzw. zu einer Platte überträgt. Wenn die SSD diese dann intern verarbeitet, so wird der SATA Controller dies nicht erfahren und damit die LED auch nicht ansteuern.

Nach meinem Stand (laut SandForce) löscht kein Controller die Daten sofort, sondern erst bei einem erneuten Schreibvorgang. Und auch erst beim erneuten Schreiben wird die GC aktiv, kann man bei Intel Laufwerken sehr schön sehen, wenn man einen Schreibbenchmark über die komplette Kapazität bei einem abgenutzten Laufwerk macht. Dann gibt es ganz viele Peaks mit niedriger Transferrate -> der Controller verschiebt erst andere Daten, bevor er den Schreibvorgang ausführt. Im Leerlauf sollte eine SSD keine Daten umsortieren. Das führt nämlich zu einer exorbitanten Write Amplification und ist wohl auch der Grund dafür, warum Indilinx-Laufwerke so schnell so eine hohe Zell-Abnutzung erreichen...

Das ist vor allem bei Sandforce ja der Grund, warum die Schreibraten mit dem Gebrauch unweigerlich etwas geringer wird. Aber allgemein machen SSDs das GC schon vor dem Schreiben, denn es ist Unsinn die alten Daten aufzubewahren und die Zellen damit zugemüllt zu lassen. Controller mit agressivem GC verkürzen halt die Lebensdauer, vor allem wenn kein TRIM dabei hilft die gelöschten Daten vom umkopieren auszuschlissen.

ADATA S599 3.1.0, RST 9.6, 10 GB Testdatei, LED leuchtet für ~10 Sekunden.

Habs eben gerade mehrmals hintereinander getestet, TRIM an, TRIM aus, LED brennt nur für mehrere Sekunden wenn TRIM an ist.

Demnach könnte es tatsächlich funktionieren, wenn der Controller so lange für die Übertragung der Nummern der Sektoren braucht, die von der gelöschten Datei belegt waren. Bei 10 GB und 4k Sektoren sind das 2500 Sektoradressen zu je 48bit. Sagen mal 8 Byte pro Sektoradresse, dann sind das 20k Daten, die durch TRIM übertragen werden müssen. Das Interface schafft 300MByte/s, die Übertragung der 20kByte mit den Sektoradressen dauert also also keine Millisekunde, das sieht man an der LED nicht. Selbst wenn vorher die Sektiren erst aus $BITMAP gelesen werden müssen weil die Sektorinformationen nicht im Chache stehen, dauert es nicht 10.000mal so lange.

 

[Bob.Dig]

Logik hin oder her, es ist Fakt, dass nach dem Trimmen bei manchen SSDs die HDD-LED für mehrere Sekunden dauerleuchtet.

 

[Dilopho]

Ist ja schön und gut, was hier manche für Fachwissen haben, aber vielleicht sollte man es auch mal zum Nutzen der Anderen einsetzen. Es gibt z.B. immer noch keine eindeutige Feststellung, ob etwa die Treiberversionen 263, 275 auf den 7xx Chipsätzen Trim unterstützen oder nicht.