News AMDs AHCI-Treiber mit TRIM-Unterstützung

TGoP schrieb:
...
Wenn ich mir anschaue welche Tricks und Kniffe angewendet werden müssen damit das ganze nicht nur zufriedenstellend funktioniert sondern auch über längere Zeit performant bleibt kann ich mich nur wundern.

Was für "Tricks und Kniffe" meinst du denn? Mit einem aktuellen Betriebssystem muss man die SSD in keinster Weise anders behandeln als eine HDD bzw. es sind keine besonderen Einstellungen nötig.
 
Complication schrieb:
TRIM ist heute schon überholt und wird von den Sandforce basierenden Controllern mit Duraclass Technik nicht verwendet: http://www.sandforce.com/index.php?id=3

TRIM wird auch von MAC OS nicht unterstützt - bitte auch gleich anschreiben.

TRIM als überholt zu bezeichnen ist der klarste Hinweis den jemand daruf geben kann, dass er von SSD und deren Technologie überhaupt keine Ahnung hat. Es ist zwar nicht lebensnotwendig aber sehr hilfreich. Habe ich im Forum schon oft genug erklärt.

Das Apple es bisher nicht im Mac OS inetgriert hat, sollte doch wohl den Kritikern von AMD den Wind aus den Segeln nehmen, darf aber AMD nicht davon abhalten es schnellstens zu implementieren. Immerhin hat Linux es und auch der MSAHCI Treiber kann es.
 
Na wenn du meinst.
In jedem Fall ist eine Technik die OS unabhängig auf jeder Plattform funktioniert weiter fortgeschritten in meinen Augen. Wie ich nun mehrfach geschrieben habe kommen Sandforce basierende SSDs auch ohne TRIM dauerhaft zu sehr guten Performancewerten.

Wenn du nach wie vor TRIM als das Mass aller Dinge siehst, hast du vielleicht einige Monate Entwicklung bei SSDs verpasst.
 
Absolut lächerlich jetzt noch einen TRIM Treiber für den Chipsatz zubringen wenn die SSDs in Zukunft sich doch selbst drum kümmern werden.:rolleyes:

Für Windows gibt es immernoch kein AHCI/RAID Treiber mit Standby Schaltung der Festplatte...

Typisch AMD halt, der running fail der Treiberwentwicklung:(... (wobei Intel hier auch nicht wirklich Punkten kann)
 
ewndb schrieb:
Für Windows gibt es immernoch kein AHCI/RAID Treiber mit Standby Schaltung der Festplatte...
Alle 10.x AHCI Treiber haben meine Samsung HD in Standby versetzt sofern ich das Energiemanagement im Windows 7 damit beauftragt hatte.
 
Alle 10.x AHCI Treiber haben meine Samsung HD in Standby versetzt sofern ich das Energiemanagement im Windows 7 damit beauftragt hatte.

Welchen Chipsatz hast du denn 800er oder 700er Serie. Ich habe 750er und kann sagen das es derzeit nicht richtig geht.
 
TGoP schrieb:
(...)
Ergo, wahrscheinlich gibt's einfach "nur" irgendein Problem des Chipsatzes in Verbindung mit TRIM und einer SSD von dem wir nichts wissen... und auch nicht erfahren sollen.

Wenn dem so wäre, dann würde es mit dem Microsoft Treiber, der standardmäßig bei 7 dabei ist, ja auch nicht funktionieren dürfen. Mit dem klappt TRIM aber, also kann es doch schlecht ein Hardware-Problem sein?
 
Also ich habe auch einen 790 Chipsatz und bin sehr enttäuscht von AMD. Mein nächstes System wir sicherlich auch eins von Intel sein.
 
ewndb schrieb:
Absolut lächerlich jetzt noch einen TRIM Treiber für den Chipsatz zubringen wenn die SSDs in Zukunft sich doch selbst drum kümmern werden.:rolleyes:
Eine SSD wird sich NIE, NIE, NIE selbst darum kümmern können. TRIM ist wichtig und sinnvoll und es gibt auch kein Ersatz dafür. Es kommt auf noch mehr an als lange Benchmarkbalken!
 
ewndb schrieb:
Welchen Chipsatz hast du denn 800er oder 700er Serie. Ich habe 750er und kann sagen das es derzeit nicht richtig geht.
Ich habe den 750er auf einem MSI Board - aber ich würde mal bei der Festplatte suchen und die Energieprofile anschauen.

st3ff3nR schrieb:
Also ich habe auch einen 790 Chipsatz und bin sehr enttäuscht von AMD. Mein nächstes System wir sicherlich auch eins von Intel sein.
Tja da du auf dem 790er Chipsatz keine SATA Schnittstelle hast spielt das wohl kaum eine Rolle. Du solltest dir überhaupt mal ein AMD System aus der Nähe anschauen, da ich daran zweifle dass du eines in Betrieb hast ;)
Ergänzung ()

DoubleJ2k schrieb:
Eine SSD wird sich NIE, NIE, NIE selbst darum kümmern können. TRIM ist wichtig und sinnvoll und es gibt auch kein Ersatz dafür.
Siehe Sandforce Controller die selber bestimmen welche Zellen freigegeben werden - Controllerseitig und mit Duraclass Technik. Auf jedem OS mit jedem Treiber.
http://www.sandforce.com/index.php?id=3

http://www.ocztechnologyforum.com/f...Secure-Erase-TRIM-and-anything-else-Sandforce
JR the blocks are reset as they are needed, not before, they are then added to the list of available blocks dependent on write cycles incurred. Now Duraclass monitors all writes and control's encryption and compression, this is what effects the speed of the blocks being written to..NOT the fact they have been TRIM'd or not TRIM'd.

You guys have become fixated at TRIM not speeding up the drive and forget that Duraclass controls all writes incurred by the drive once a GC map has been written.
 
Complication schrieb:
Siehe Sandforce Controller die selber bestimmen welche Zellen freigegeben werden - Controllerseitig und mit Duraclass Technik. Auf jedem OS mit jedem Treiber.
http://www.sandforce.com/index.php?id=3
Das KANN der Controller ohne TRIM NICHT wissen, wie denn auch? Natürlich können teilweise Zellen wieder freigegeben werden, wenn Dateien überschrieben werden etc. Aber es bleibt dabei: Für TRIM gibt es keinen Ersatz und das wird es auch nie geben.

(Ok, der Samsung RBB Controller kann NTFS-Dateisysteme lesen und anhand der $Bitmap erkennen, welche Bereiche gesäubert werden können. Das ist aber die absolute Ausnahme und hat sich bei anderen Controllern auch zum Glück nicht durchgesetzt.)
 
DoubleJ2k schrieb:
Das KANN der Controller ohne TRIM NICHT wissen, wie denn auch? Natürlich können teilweise Zellen wieder freigegeben werden, wenn Dateien überschrieben werden etc. Aber es bleibt dabei: Für TRIM gibt es keinen Ersatz und das wird es auch nie geben.

Und was sagst du denen die einen Mac oder XP mit einer SSD benutzen? Da gibt es kein TRIM - erzähl doch nicht so einen Unsinn.

Der Sandforce Controller kontrolliert welche Speicherblöcke beschrieben werden, welche geleert werden und welche Daten komprimiert werden. Wie soll denn das Windows wissen dass nur 50% der NAND Zellen genutzt werden nach der Kompression der Daten und entsprechend die andere Hälfte der Zellen als leer oder nicht mehr benötigt markieren mit TRIM?

Erstmal die Technik verstehen vor solchen Falschaussagen. Aber sicherlich sind die Leute bei OCZ planlos - lies einfach den Link. :rolleyes:

Aber vielleicht hilft dir ja der Anand Artikel zu Sandforce auf die Sprünge:
http://www.anandtech.com/show/2899/2

durawrite2-jpg.214464


SandForce states that a full install of Windows 7 + Office 2007 results in 25GB of writes to the host, yet only 11GB of writes are passed on to the drive. In other words, 25GBs of files are written and available on the SSD, but only 11GB of flash is actually occupied. Clearly it’s not bit-for-bit data storage.

durawrite-jpg.214465


[...]
Assuming this is how SandForce works, it means that there’s a ton of complexity in the controller and firmware. Much more than what even a good SSD controller needs to deal with. Not only does SandForce have to manage bad blocks, block cleaning/recycling, LBA mapping and wear leveling, but it also needs to manage this tricky write optimization algorithm. It’s not a trivial matter, SandForce must ensure that the data remains intact while tossing away nearly half of it. After all, the primary goal of storage is to store data.

The whole write-less philosophy has tremendous implications for SSD performance. The less you write, the less you have to worry about garbage collection/cleaning and the less you have to worry about write amplification. This is how the SF controllers get by without having any external DRAM, there’s just no need. There are fairly large buffers on chip though, most likely on the order of a couple of MBs (more on this later).
 

Anhänge

  • durawrite2.jpg
    durawrite2.jpg
    131 KB · Aufrufe: 806
  • durawrite.jpg
    durawrite.jpg
    112,9 KB · Aufrufe: 773
Complication schrieb:
Es tut wirklich schon fast weh wenn man so viel Unsinn lesen muss:
Du hasst wohl die Weisheit mit Löffeln gefressen. Es war in jeder Review zu lesen, dass sich beim Chipsatz so gut wie nix wesentlich geändert hätte, Ausnahme die SB. Eine kleinere Struktur ist keine Änderung von Funktionen. Selbst das RAID Tool ist immer noch das selbe. Ein neues, wie auf der Treiberseite zu lesen ist, ist im Treiber gar nicht vorhanden.
 
@Complication
DoubleJ2k hat Recht, es gibt aktuell keinen Ersatz für TRIM! Es geht nicht darum, ob und wie der Controller Schreibvoränge regelt oder Zellen leert. Es geht darum wie der Controller erfährt, welche logischen Bereiche valide Daten enthalten und welche nicht. Denn nur so kann das Flash-Management effizient und langlebig funktionieren.

SandForce verwendet verschiedene Mechanismen, um die Probleme, die ein Controller ohne TRIM-Infos hat, abzumildern. Durch den großen Reservespeicher und die Komprimierung erfährt der Controller in der Regel durch Schreibanfragen für logische Bereiche, dass bestimmte Inhalte nicht mehr valide sind. Das reicht dem Controller, um gut zu arbeiten. Der Aufwand für den Controller ist aber ohne TRIM erheblich höher und das Absinken der sequ. Schreibrate ist z.B. ein Nebeneffekt, den man für das gute GC in Kauf nehmen muss.

Es ist also richtig zu sagen: TRIM wird bei SandForce-SSDs nicht benötigt, um die Realleistung hoch zu halten. Es ist aber falsch daraus zu schlussfolgern, dass TRIM keine Berechtigung hat bzw. Vorteile bietet!
 
Complication schrieb:
Erstmal die Technik verstehen
Richtig. Deswegen verlasse ich mich auch nicht auf das OCZ Forum sondern halte Mail- und Telefonkontakt direkt mit SandForce. Die Folien kenne ich übrigens auswendig, genau wie die Spezifikationen des Controllers. Ich schreibe selbst Artikel über SSDs und maße mir daher tatsächlich an, etwas bescheid zu wissen. Wenn du behauptest, dass TRIM unnötig oder ersetzbar ist, hast du die Technik nicht verstanden.

Das OS muss über die Kompression nichts wissen, deswegen nennt man sie auch transparent. Wenn der Controller 1000 Blöcke auf 100 runterschrumpft und das OS irgendwann sagt, hier, diese 1000 Blöcke kannst du wegwerfen, weiß der Controller, welche (100) Blöcke zu verwerfen sind. Wenn ein logischer Block überschrieben wird und der Controller einen neuen physischen Block allokiert, ist das die einzige Möglichkeit, einen physischen Block (nämlich den, der vorher dem entspr. logischen Block zugeordnet war) freizugeben. Durch die Kompression werden evtl. mehr Blöcke freigegeben als allokiert, wenn die neuen Daten besser zu komprimieren sind. Trotzdem bleiben immer Reste an verwaisten Daten im Flash, die der Controller ohne TRIM nie freigeben wird.

SandForce SSDs sind auf TRIM nicht angewiesen, um ordentlich zu funktionieren (im Sinne der Transferraten). Daraus aber zu schließen, TRIM wäre in Zukunft unnötig und überholt, ist gefährlich und falsch.
 
Zuletzt bearbeitet:
@Moros
Der OCZ Support sagt eindeutig was anderes
http://www.ocztechnologyforum.com/f...Secure-Erase-TRIM-and-anything-else-Sandforce
JR the blocks are reset as they are needed, not before, they are then added to the list of available blocks dependent on write cycles incurred. Now Duraclass monitors all writes and control's encryption and compression, this is what effects the speed of the blocks being written to..NOT the fact they have been TRIM'd or not TRIM'd.

You guys have become fixated at TRIM not speeding up the drive and forget that Duraclass controls all writes incurred by the drive once a GC map has been written.
Wo soll denn TRIM in der oben beschriebenen Vorgehensweise seine Informationen einbringen bei Sandforce? Welchen nutzen hat der Controller ausser dass unnötige Informationen wieder verworfen werden?
 
Das kommt mir vor wie die Diskussion ob 1600er RAM schneller ist als 1333er.
Es gibt sicherlich Messverfahren die das bestätigen nur hat es keine Relevanz in der Praxis.

Das Overprovisioning wird etwas verbessert und das war es auch schon - wo dieses mehr sich ausserhalb der Theorie auswirkt steht in den Sternen und vor allem in einer fast 100% Belegung der SSD. Benchmarkrelevante Diskussionen haben meistens wenig mit der Userpraxis zu tun.

@DoubleJ2k
Ich würde gerne mal einen deiner Artikel lesen :)
 
DoubleJ2k schrieb:
Das KANN der Controller ohne TRIM NICHT wissen, wie denn auch? Natürlich können teilweise Zellen wieder freigegeben werden, wenn Dateien überschrieben werden etc. Aber es bleibt dabei: Für TRIM gibt es keinen Ersatz und das wird es auch nie geben.
Richtig, aber lass Dich von ahnungslosen Werbegläubigen nicht provozieren.
Wer keine Ahnung hat, der muss ja glauben, was das Marketing ihm einzureden versucht und wer keinen Verstand hat, der will das auch glauben.
DoubleJ2k schrieb:
(Ok, der Samsung RBB Controller kann NTFS-Dateisysteme lesen und anhand der $Bitmap erkennen, welche Bereiche gesäubert werden können. Das ist aber die absolute Ausnahme und hat sich bei anderen Controllern auch zum Glück nicht durchgesetzt.)
Eben, sowas ist extrem gefährlich. Man stelle sich vor, das wird irgendwann leicht geändert und schon beginnt die SSD falsche Blöcke zu löschen, fatal.
Außerdem nur für Windows Nutzer zu gebrauchen. Wer jetzt ein RAID oder ein anderes Filesystem verwendet, kann nur hoffen das die SSD dies auch richrtig erkennt.
Der richtige Weg ist einfach, dass das Filesystem eben nicht nur ein Bit setzt um eine Datei als gelöscht zu markieren, sondern der SSD eben mitteilt welche logischen Blöcke diese belegt hatte. Damit braucht auch GC diese nicht mehr umzukopieren, was eben neben der Performance auch die Lebensdauer erhöht.
Irgendwann begreift dann auch der Letzte noch, dass TRIM eben dazu da ist GC mitzuteilen, welche Bereiche nicht mehr benötigte Daten enthalten, so dass GC dies eben nicht erst merkt, wenn das Betriebssystem eben gewillt ist, diese Bereiche irgendwann neu zu überschreiben. Und wenn der Dünnste das gemerkt hat, implmentiert vielleicht auch der letzte Hersteller dies in seinem Treiber, Betriebssystem, RAIDController etc.
Solange aber weiterhin erfolgreich der Unsinn verbreitet wird, dass GC alleine reicht und TRIM sogar als unnötig und veraltet ist, wird keiner der Verantwortlichen dieser Firmen die Mittel locker machen um TRIM zu implmentieren. Der Kunde verlangt es ja nicht.
 
Zuletzt bearbeitet:
Complication schrieb:
Das kommt mir vor wie die Diskussion ob 1600er RAM schneller ist als 1333er.
Es gibt sicherlich Messverfahren die das bestätigen nur hat es keine Relevanz in der Praxis.
Wenn man nur von Benchmarkwerten redet, hat TRIM bei SandForce tatsächlich kaum Relevanz. Ich rede aber auch von Haltbarkeit/Wear-Leveling. Je mehr freie Blöcke es gibt, desto besser kann es arbeiten. Mir ging es ursprünglich außerdem um die Aussage, das man in Zukunft generell kein TRIM mehr brauchen wird.


Complication schrieb:
@DoubleJ2k
Ich würde gerne mal einen deiner Artikel lesen :)
Passend zum Thema: http://www.hardwareluxx.de/index.ph...a-s599-was-kann-der-sandforce-controller.html

Ansonsten sollten wir glaube ich wieder auf den AMD AHCI-Treiber zurückkommen, bevor es komplett OT wird ;)
 
Zurück
Oben