SSDs mit Sandforce Controllers SF1200 und SF1500 [Part 3]

[HisN]

Sorry, und ich hab jetzt erst gesehen dass Du Deine Hardware ja dazugeschrieben hast ich Peiffe.

Erst mal frohe Weihnachten

Manche Mainboards haben mehr als einen Controller auf dem Board und Windows erkennt nicht automatisch alle Controller. Wenn es keinen Treiber für den benutzten Controller findet, dann kann es auch die angeschlossenen Geräte nicht finden.

Kleine weitere Frage. Du hast eine Festplatte (auf der jetzt scheinbar ein Windows läuft) am gleichen Controller. Wird die Festplatte bei der Installation angezeigt, oder auch nicht?

Und falls Dein Windows noch läuft. Bitte kurz ein Screenshot vom Gerätemanager. Mit den beiden Untergruppen aufgeklickt wie bei mir auf dem Screen.

 

[OttoFischer]

ok ;-) ja danke dir auch!!

---------- Beitrag hinzugefügt um 00:21 ---------- Vorheriger Beitrag war um 00:13 ----------

Also ich bin gerade an meinem Laptop aber ich kann eben das bild machen. Die andere Festplatte (Sata) wird ohne Probleme erkannt. bild kommt sofort ;-)

---------- Beitrag hinzugefügt um 00:26 ---------- Vorheriger Beitrag war um 00:13 ----------

---------- Beitrag hinzugefügt um 00:29 ---------- Vorheriger Beitrag war um 00:13 ----------

...mist habe die Controller vergessen

 

[barto11]

Hab die gleiche Platte heute auch bekommen und lief direkt alles, haste den im Bios auf AHCI umgestellt ?

 

[oggear51]

probier mal diese Punkte aus:

*Mainboard BIOS update
*SSD Firmware update
*im bios auf AHCI oder IDE einstellen, kein RAID

dass sind die Punkte dir mir jetzt um diese Uhrzeit spontan einfallen

 

[Spieluhr]

Hast du da noch einen HW-Raidcontroller im Rechner drin?

Einfachste Methode wäre alle anderen Platten abklemmen, im Bios auf AHCI umstellen und dann Win7 only über SSD auf diesen zu installieren. Auch solltest du dann keine weiteren LW-Controllertreiber während der Win7-Installation einbinden, daß machst du nachher über die AMD-HP wo du dir den AMD-AHCI Treiber herunter lädst.

Idealerweise sollte danach dann im Gerätemanager unter Speichercontroller nur ein "XXXX IDE Controller" stehen und unter IDE ATA/ATAPI-Controller der "AMD SATA Controller" (muß man event. noch selfmade von msahci auf diesen umstellen):

...

 

[Mike Sephan]

Ruhezustand und Standby lässt System nur mit SSD träge werden

Ich habe mir vor kurzem eine OCZ Vertex 2 60GB geleistet. Habe nun über Win7 das Align gemacht und dann WinXP installiert. Funktioniert soweit auch alles und ist schön schnell. Doch nun musste ich feststellen, dass das System nach einem Ruhezustand oder Standby extrem langsam wird. Es braucht über eine Minute bis ich vom Anmeldebildschirm auf den Desktop komme. Und auch dort reagiert das System träge. Es braucht Minuten bis sich etwas tut. Auch nach einer nochmaligen Installation und ATI Treiber Installation gleiches Problem. Mit meiner alten Festplatte funktioniert das ohne Probleme. Es hat also etwas mit der SSD zu tun.

 

[Powermikey]

TRIM auf Sandforce-SSD mit MSAHCI nicht aktiv! Lösungsmöglichkeit vorhanden!

Hi,

bin heute auf einen Forenthread im G.Skill-Forum gestoßen. Dort schreibt man, dass das Trim-Handling des MSAHCI nicht mit dem Sandforce kompatibel ist. Nun, das Gefühl hatte ich schon länger, da sich ein Sandforce-Laufwerk ja performancetechnisch gleich verhält, egal ob TRIM aktiv ist oder nicht. Durch einen Eingriff in die Registry wird das aber korrigiert.

Ich habs ausprobiert und bin bis jetzt begeistert, lest den Faden hier selbst: Enabling TRIM in Windows 7 with a Phoenix/Phoenix Pro SSD - GSKILL TECH FORUM

Bin mal auf das Feedback der Cracks hier gespannt. Pinki? Morpog?

Grüße

 

[DoubleJ]

Eingebrochene SF-Laufwerke werden dadurch auch nicht wieder beschleunigt, da das "Problem" (eigentlich ist es keins) auch z.B. mit dem Intel RST auftritt, der vollständig kompatibel ist. Das dürfte ja nicht der Fall sein, wenn der Einbruch an der fehlerhaften TRIM-Implementation des msahci liegt...

 

[Powermikey]

Eingebrochene SF-Laufwerke werden dadurch auch nicht wieder beschleunigt, da das "Problem" (eigentlich ist es keins) auch z.B. mit dem Intel RST auftritt, der vollständig kompatibel ist. Das dürfte ja nicht der Fall sein, wenn der Einbruch an der fehlerhaften TRIM-Implementation des msahci liegt...

Nun, dass der Intel RST vollständig kompatibel ist, wäre noch zu beweisen. Jedenfalls haben sich meine Schreibwerte von ~60MB/s auf 95 erhöht. Nach dem Regmod habe ich das Tool "Forcetrim" ausgeführt. Dieses erzeugt ja bekanntermaßen durch Speicherplatzreservierung viele 2GB Dateien, ohne dabei jeden dabei belegten Sektor zu beschreiben. Nach dem Löschen wird TRIM ausgelöst. Dies verhielt sich nun anders, nach dessen Beendigung blieb das System für 30s fast stehen, die HD-Lampe leuchtete. Scheinbar war da TRIM in Aktion - das habe ich so bei einem Sandforce-Laufwerk noch nie gesehen!

Grüße

 

[dictamnus]

bin heute auf einen Forenthread im G.Skill-Forum gestoßen

gilt das für alle sandforce-ssds oder nur für die phoenix?

 

[T34]

Hab das zufällig mal MITGELESEN. W7 sendet wohl (normal) eine TRIM-Anweisung für 8 Blöcke/Sektoren/Zuordnungseinheiten, also eine Gruppe, und dieser Controller/Firmware möchte es gerne einzeln, trimmt also nur die erste Zuordnungseinheit - oder so ähnlich. Es entsteht also mehr Traffic auf dem Schnürsenkel bei 8 einzelnen Anweisungen.

Wenn man die Änderung in der Reg gemacht hat, müsste man also nach dem neuen Systemstart mal mit H2testw o.ä. die SSD voll schreiben und wieder löschen, damit alles getrimmt wird.

 

[Morpog]

Meiner Meinung nach sollte Sandforce endlich ihre Firmware an die Treiber anpassen - nicht umgekehrt. Bei allen anderen SSD Controller Herstellern klappt es schließlich auch.

 

[Cippoli]

Hab das zufällig mal MITGELESEN. W7 sendet wohl (normal) eine TRIM-Anweisung für 8 Blöcke/Sektoren/Zuordnungseinheiten, also eine Gruppe, und dieser Controller/Firmware möchte es gerne einzeln, trimmt also nur die erste Zuordnungseinheit - oder so ähnlich. Es entsteht also mehr Traffic auf dem Schnürsenkel bei 8 einzelnen Anweisungen.

Meiner Meinung nach sollte Sandforce endlich ihre Firmware an die Treiber anpassen - nicht umgekehrt. Bei allen anderen SSD Controller Herstellern klappt es schließlich auch.

Sandforce hält sich an die ATA8-ACS (Version 6) Spezifikation. Nicht der Controller ist das Problem, sondern der MSAHCI-Treiber, welcher sich nicht normgerecht verhält.

 

[T34]

Und wie verhält sich RST/iastor?

 

[DoubleJ]

Nun, dass der Intel RST vollständig kompatibel ist, wäre noch zu beweisen.

Techniker bei SandForce haben das "bewiesen", ich denke das ist als Quelle vertrauenswürdig. Von SandForce selbst stammt übrigens auch dieser Fix, den du gefunden hast. Sollte eigentlich noch nicht veröffentlicht werden...

Scheinbar war da TRIM in Aktion - das habe ich so bei einem Sandforce-Laufwerk noch nie gesehen!

Dann hast du noch nie hingeschaut Dieses Verhalten haben SandForce-Laufwerke immer, wenn große Bereiche getrimt werden. Egal ob mit Intel RST, msahci mit/ohne Fix oder AMD AHCI.

Meiner Meinung nach sollte Sandforce endlich ihre Firmware an die Treiber anpassen - nicht umgekehrt. Bei allen anderen SSD Controller Herstellern klappt es schließlich auch.

Naja, Microsoft hat beim msahci gepfuscht. Ist daran jetzt SandForce schuld? Ich finde es eher ein gutes Zeichen, wenn SandForce das Problem an der Ursache anpackt und nicht bei den Symptomen... Vermittelt das Gefühl einer sauberen Arbeitsweise.

 

[M_P_E]

Finde ich auch so. Schon etwas kurios das Ganze.

Übrigens schon alter Käse

Hier das ganze nochmal in PDF-Form von TeamGroup. Vielleicht sollte man das ja auch verlinken am Anfang.

 

[T34]

MS kann nicht direkt gepfuscht haben, sonst würde der Eintrag in der Reg gar nicht abgefragt werden. Wer schmeißt jetzt mal procmon an?

 

[DoubleJ]

MS kann nicht direkt gepfuscht haben

Doch, der Treiber sollte es automatisch erkennen.

 

[Morpog]

Nun, dass der Intel RST vollständig kompatibel ist, wäre noch zu beweisen. Jedenfalls haben sich meine Schreibwerte von ~60MB/s auf 95 erhöht.

Techniker bei SandForce haben das "bewiesen", ich denke das ist als Quelle vertrauenswürdig. Von SandForce selbst stammt übrigens auch dieser Fix, den du gefunden hast.

Sandforce hält sich an die ATA8-ACS (Version 6) Spezifikation. Nicht der Controller ist das Problem, sondern der MSAHCI-Treiber, welcher sich nicht normgerecht verhält.

Mag schon sein, dass Microsoft sich nicht komplett an den ATA Standard gehalten hat. Da stellen sich mir aber mehrere Fragen:

• Warum klappt es bei anderen Controller Herstellern damit problemlos?
• Warum kann ich keine Leistungserhöhung wie Powermikey beobachten wenn ich den RST einsetze (vom AMDSATA hab ich dergleichen auch nichts gehört)?
• Wie verhält sich die Registry Änderungen mit anderen SSD Controllern?

Doch, der Treiber sollte es automatisch erkennen.

Tut dies der Intel RST? Wird der MSAHCI dies später können (evtl. SP1)?

 

[T34]

Ich habe procmon an, Filter Pfad entält ATAport, Ordner ATAPORT auf c: angelegt, in der Liste tauchen nur C:\ATAPORT auf, nix Registry. Will jetzt mal procmon beim Booten aktivieren.

 

[Powermikey]

Dann hast du noch nie hingeschaut Dieses Verhalten haben SandForce-Laufwerke immer, wenn große Bereiche getrimt werden. Egal ob mit Intel RST, msahci mit/ohne Fix oder AMD AHCI.

Doch, ich habe hingesehen. Einschränkend muss ich sagen, dass ich das bei meinem System (AMD SB600) mit Msahci und AMDAhci mit dem Sandforce so nie gesehen habe, wohl mit dem vorigen Indilinx Laufwerk. Andere Systeme mit SSDs habe ich nicht im Zugriff.

Grüße

 

[T34]

Mit RST/iastor auch beim Neustart keine Abfrage der Reg nach ...ataport... zu erkennen. Es wird sogar ein Treiber ataport.sys angelegt.

Das müsste also jetzt mal jemand mit msahci testen.

 

[Powermikey]

Mit RST/iastor auch beim Neustart keine Abfrage der Reg nach ...ataport... zu erkennen. Es wird sogar ein Treiber ataport.sys angelegt.

Warum sollte der Intel RST eine Registryeintrag des MSAHCI abfragen...

 

[T34]

Woher hattest du die Überzeugung, dass das nur msahci betrifft? Wer erzeugt denn das TRIM-Kommando?

 

[Mike Sephan]

Ich habe heute einen Thread aufgemacht "Ruhezustand und Standby lässt System nur mit SSD träge werden" der wurde irgendwie hier her verschoben, kann den aber nicht finden. Also schreibe ich nochmal den Beitrag hier rein:

Ich hab mir eine Vertex2 60GB gekauft und mit Win7 das Align gemacht und danach WinXP drauf installiert. Nachdem ich nun das meiste installiert hatte, habe ich den Ruhezustand getestet. Damit habe ich nun das Problem, dass nach dem Aufwachen das System extrem langsam reagiert. Wenn ich im Anmeldebildschirm auf den User klicke, dauert es Minuten bis der Desktop erscheint, und auch dort dauert es ewig bis sich was tut. Gleiches Phänomen tritt auch mit dem Standby auf. Die Maus selbst reagiert ganz normal. Habe WinXP bereits neu installiert und nur den ATI Treiber drauf, damit der Ruhezustand geht. Doch das Problem besteht dort ebenfalls. Wenn ich das Ganze von meiner alten HDD mache gibt es das Problem nicht. Scheint also irgendwas im Zusammenhang mit der SSD zu sein. Die Firmware ist bereits die Neueste.

 

[T34]

Ich liebe diese Sammelthreads...

 

[Morpog]

@Mike Stephan

Eine Seite vorher ist dein Beitrag. Ist in der hitzigen Diskussion leider untergegangen.
Dein Verhalten kann ich auf meinen Systemen nicht nachvollziehen. Da funktioniert nach dem Standby alles einwandfrei.

Schon ein FW Update auf die aktuellste Version versucht?

 

[Powermikey]

Ich liebe diese Sammelthreads...

Stimmt, das erhöht nur die Datenmenge, da man ständig quoten muss, um klar zu stellen auf was man antwortet. Und die Forensuche nützt einem auch nix, weil man bei dem Treffer auf Seite 1 des Threads landet. Superunübersichtlich...

 

[T34]

Bei Suche unten den Radiobutton Beiträge anklicken.

 

[DoubleJ]

[*]Warum klappt es bei anderen Controller Herstellern damit problemlos?[/LIST]

Die können größere Bereiche auf einmal TRIMen und haben daher kein Problem. Oder der Hersteller hat einen Workaround in die FW implementiert.

Tut dies der Intel RST? Wird der MSAHCI dies später können (evtl. SP1)?

Ja und SF arbeitet mit MS zusammen, um das Problem zu beseitigen.

Doch, ich habe hingesehen.

Dann ist es dir nie aufgefallen Ich hatte SF Laufwerke jetzt aber schon mit allen möglichen Storagetreibern in Betrieb und immer, wenn TRIM "irgendwie" gesendet wird (und ein großer Bereich betroffen ist) brennt die HDD-LED permanent. Das ist nichts Neues.

Woher hattest du die Überzeugung, dass das nur msahci betrifft? Wer erzeugt denn das TRIM-Kommando?

Zumindest der Fix (eher workaround) betrifft nur den msahci.