Crucial RealSSD C300 256GB läuft zu langsam

@Holt,du kannst feststellen ob Trim wirklich funktioniert und das BS nicht nur den Befehl sendet unter Linux,klappt wunderbar.

Mal grob gesagst du erstellst ein File, liest dann die genaue Blockadresse aus auf dem das File beginnt ,löscht es dann und guckst wieder auf genau die gleiche Adresse-wenn dann nur noch Nullen da sind hat TRIM funktioniert, beinhaltet der Sektor wat anderes als Nullen hat Trimen nicht funktioniert.

hier mal n Link:

http://andyduffell.com/techblog/?p=852

hab dazu was interessantes zu windows7/TRIM gefunden(Part3)
http://www.ocztechnologyforum.com/forum/showthread.php?66696-New-FW-Flashing

vieleicht könnte das mal ein Windowsuser ausprobieren.

hier mal screenshots:
 

Anhänge

  • Trim1.png
    Trim1.png
    390,7 KB · Aufrufe: 391
  • Trim2.png
    Trim2.png
    168,4 KB · Aufrufe: 386
Zuletzt bearbeitet:
Stimmt, das mit Linux könnte in der Tat funktionieren, denn wenn sich die Daten auf der Adresse geändert haben, dann ist durch wordas Löschen mehr als nur ein Flag in den Verwaltungsdaten gesetzt worden. Vorraussetzung ist aber, dass sonst kein Programm läuft, welches etwa Datein die gelöscht wurden sicherheitshalber gleich überschreibt. Das müßte man mit einer Gegenprobe auf einer HDD testen.
Hier habe ich TRIM und GC mal erklärt, lies es aufmerksam durch (ist etwas länger, aber das Thema ist ja auch nicht so einfach). Da TRIM kein Befehl zum Löschen an die SSD ist, wird je nach Controller das effektive Löschen erst später bis viel später erfolgen, erst recht bei wirklich kleinen Dateien.
Die Nullen können also die Standartinhalt von nicht gemappten LBAs sein, der Controller könnte aber auch die wirklichen Daten einer zwar bereits ungültigen aber noch nicht geflashten Page noch immer zurückliefern, etwa um eine Datenrettung zu ermöglichen. Bei einem postiven Ergebniss kann man also mal von funktionierendem TRIM ausgehen und bei einem Negativen aber nicht mit der gleichen Sicherheit vom Gegenteil.
Die Überprüfung mit procmon sagt dagegen nichts aus, denn alle Vorgänge werden genauso ausgeführt und TRIM geschickt, wenn es in Windows 7 aktiviert ist, egal ob die Befehle ankommen oder nicht. Das wird ja bei der Methode nicht geprüft.
Ergänzung ()

Ob TRIM in Win7 aktiv ist, sagt mir fsutil behavior query DisableDeleteNotify viel schneller, es sagt nur halt nict, ob es funktioniert oder ob die TRIM Befehle irgendwo zwischen Treiber und SSD verloren gehen.
 
Zuletzt bearbeitet:
ich habe das ganze nochmal zur Gegenprobe aufm Laptop gemacht,der hat keine SSD beim gleichen BS. Die Bereiche wurden hier nur als"wieder freigegeben" markiert,sie können also überschrieben werden bei Bedarf, oder man könnte sie wieder herstellen, während sie bei der SSD mit Trim genullt wurden.Man siehst also das es funktioniert;) aber ich verstehe deine Einwände wegen eventuellem remapping der LBA´s.Du meinst also wenn ich das File lösche und wieder auf die gleichen Sektoren schaue, das er das Controllerintern umgemappt hat und ich sehe jetzt nen ganz anderen Bereich der zwar die gleiche Adresse hat bzw gibt er sie so aus zum BS, aber in wirklich ein ganz anderer Bereich auf der SSD ist,schwer zu sagen.Ich nehme aber mal nicht an das er die LBA´s ummappt,warum sollte er auch, er kriegt den Trim befehl und nullt einfach die Bereiche

screens:
 

Anhänge

  • TRIMLAP1.png
    TRIMLAP1.png
    98,1 KB · Aufrufe: 371
  • TRIMLAP2.png
    TRIMLAP2.png
    64,5 KB · Aufrufe: 393
Zuletzt bearbeitet:
Stany schrieb:
Man siehst also das es funktioniert;) aber ich verstehe deine Einwände wegen eventuellem remapping der LBA´s.Du meinst also wenn ich das File lösche und wieder auf die gleichen Sektoren schaue, das er das Controllerintern umgemappt hat und ich sehe jetzt nen ganz anderen Bereich der zwar die gleiche Adresse hat bzw gibt er sie so aus zum BS, aber in wirklich ein ganz anderer Bereich auf der SSD ist,schwer zu sagen.Ich nehme aber mal nicht an das er die LBA´s ummappt,warum sollte er auch, er kriegt den Trim befehl und nullt einfach die Bereiche
Wenn Du mit Nullen meinst, er hätte ich gelöscht, so macht er genau das vermutlich eben nicht. Der Test zeigt aber trotzdem, dass es funktioniert hat, denn wäre kein TRIM Befehl bei der SSD anggeommen, so wäre je nur ein Bit in den Verwaltungsdaten geändert worden, daraufhin hätte der SSD Controller diese LBA ja nicht remappen dürfen bzw. hätte die Daten je wieder auf die neue Adresse kopieren müssen, die ohne TRIM wären sie ja noch gültig.
Durch das TRIM wird der LBA aber in der Mappingtabelle genullt (oder herausgelöscht, je an Implemntierung als Liste oder Array) und immer wenn man auf einen genullten LBA lesend zugreift, liest die SSD gar keinen Speicher aus sondern liefert einfach einen Sektor mit Nullen zurück, denn er hat ja keine Daten für diesen LBA mehr spreichert
Greift man schreibend zu, so sucht oder schafft der Controller eine freie Page, schreibt die Daten dort, trägt ggf. markiert die alten Page als ungültig und mappt den LBA dann auf die neue Page.
 
achso, dann ändert er quasi nur die Dateizuordnungstabelle und gibt mir den genullten Bereich nur visuell zurück wenn ich anfrage, aber die gelöschten Daten sind je nachdem ob GC schon aktiv war eventuell noch da.Ich dachte er würde durch das Trimen die Sektoren gleich nullen-aber du hast natürlich recht, er kann sie ja garnicht ohne weiteres aufeinmal sofort nullen ,es könnten sich ja noch Teile von noch nicht als freigegeben markierten Dateien mit in dem Block befinden und er müsste sie erstmal woanders hinschreiben,richtig?Der Trimbefehl wurde aber richtig vom Controller umgesetzt sonst würde er mir die gleichen Werte ausgeben wie vorher ja auch ,weil sie für ihn ganz normale Daten sind(also noch Daten die in Gebrauch sind) und er(der Controller) kann ja ohne Trim nicht wissen das ich die Datei gelöscht habe nur das BS weiß es und zeigt sie mir im Dateimanager nicht mehr an, hdparm blickt aber natürlich tiefer als der Dateimanager.Die ganze SSDgeschichte ist für mich Neuland,habe mich davor auch nicht sonderlich viel mit dem Thema Storage befasst,aber ich lese mich grade nen bisschen ein, da sind aber noch viele offene Fragen.
 
Zuletzt bearbeitet:
Hallo Leute,


ich habe mal wieder Probleme mit der Geschwindigkeit, mit meiner SSD. Das booten von Windows dauert 3 min, das ist meiner Meinung nach viel zu viel, mit einer SSD. Ich glaube ich habe nicht die richtigen Treiber von dem Controller installiert, kann mir jemand von euch sagen was das sein könnte? Danke.

2016-08-19 14_09_59-Greenshot.png
 
Die Bootzeit hängt vor allem von der Zeit für die Initialisierung der HW ab und damit auch von den Treibern, weniger von der Performance der SSD. Da hatten wir vor einiger Zeit diesen Thread, wo dann letztlich ein "HP CUE DeviceDiscovery Service" das Booten massiv verzögert hat. Den speziellen Service hast Du vermutlich nicht, aber in dem Thread findest Du auch die Anleitung, wie Du so einen Übeltäter in Deinem System ausfindig machen kannst.

Außerdem solltest Du mal Dein SATA Datenkabel überprüfen, denn der Rohwert (rechte Spalte) vom Attribut C7 ist nicht 0, spätestens wenn der ansteigt liegt dort aktuell ein Problem vor, dann der Wert zählt Kommunikationsfehler zwischen dem SATA Host Controller und dem Controller der SSD.
 
Hallo Holt,

danke nachmal für die schnelle Antwort, ich werde am Sonntag das nochmal ausprobieren, was du mir geschrieben hast.
Werde mich ansonsten nochmal an dich wenden, wenn es nicht funktionieren sollte. Schönes Wochenende.


Gruß Raimund333
 
Also ich bin nicht der Fachmann für Windows Bootzeitanalysen, wenn Du dazu Fragen hast, schau am Besten in das passende Windows Unterforum.
 
Zurück
Oben