Samsung SSD 840 120 GB unter WIN 7 Ultimate schlechter als unter WIN XP SP2

[spoilerhungary]

Hallo liebe Forumgemeinde !

Nachdem ich die o. g. SSD zuerst unter WIN XP betrieben hatte, habe ich vor kurzem WIN 7 Ultimate aufgespielt. Dabei hat das WIN 7 Setup die SSD formatiert, 1 Partiton. Die SSD hängt an 1. SATA Contoller, das Board kann nur SATA 2.
Jetzt stelle ich leider fest, das die Benchmarkwerte unter WIN 7 so ca 30% schlechter sind als unter dem früher benutztem WIN XP (s. Anlage).
Mir ist aufgefallen, das verschiedene Treiber WIN XP = nvata und WIN 7 = nvstor benutzt werden. Trim ist wohl aktiviert, ( Abfrage mit fsutil behavior query DisableDeleteNotify ). AHCI kann ich bei meinem Motherboard nicht aktivieren, gibt dafür nicht.
Habe bereits mehrmals ausführlich gegoogelt, bin noch zu keiner Lösung gekommen.


Mit SAMSUNG Magician 4.1 kann ich nur den Performance Test durchführen, die anderen Funktionen sind nicht aktivierbar.
Hat von Euch jemand evt. die Idee, die mich weiter bringen könnte ?


Vielen Dank (vorerst nur) fürs Lesen

Jürgen

 

[Holt]

Die NVidia Chipsätze sind sehr alt und viele SSDs funktionieren nicht ordentlich mit denen, so auch die Samsung 840. Wie man sieht, scheint es auch am Treiber zu liegen, aber da NVidia niemals AHCI lizenziert (deshalb kann Du auch keinen AHCI Modus im BIOS auswählen) und daher einen eigenen Pseudo-AHCI Modus implementiert hat, gibt es i.d.R. keine Möglichkeit einen anderen Treiber als den von NVidia zu verwenden. Außerdem scheint es teils auch am Port zu liegen, bei jemandem war es wohl zumindest so, dass die SSD an einem Port nur im 1.5Gb/s Modus lief (wie bei Dir unter Win7) und am anderen mit 3Gb/s (wie bei Dir unter XP). Andere haben berichtet, dass es mal so und mal so geht, die SSD mit dem Host Controller also mal den 3Gb/s Modus aushandeln konnte und mal nicht.

fsutil behavior query DisableDeleteNotify sagt übrigens nur, ob überhaupt TRIM Befehle verschickt werden nicht aber, ob diese auch ankommen. Auch CrystalDiskInfo zeigt nur an, ob die SSD überhaupt TRIM Befehle versteht und nicht, ob sie welche erhält. Ob TRIM wirklich funktioniert, kann man mit dem TrimCheck prüfen, man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat. Dazwischen sollte man nichts am Rechner machen und ein paar Minuten warten.

 

[Zidane]

Die SSD reklamieren, sofern möglich und eine Crucial M4 oder M500 verbauen, ein Kollege von mir hat die M4 auf einem N-Force 520er Board am laufen, ohne Probleme. Samsung ist nicht 100% kompatibel mit dem NV Chipsatz.

 

[Hiserius]

Was mich jetzt noch interessieren würde, NV Chipsatz hin oder her - warum kommt mit der identischen Config XP besser damit klar als W7?

 

[pinki]

weil höchstwahrscheinlich der treiber rotz ist

 

[Holt]

Die NVidia halten sich da wohl nicht so genau an den SATA Standard, aber leider gibt es darüber nichts mehr im Netz. Nicht jeder Controller der mit SATA II beworben wird, ist voll mit der 2.0 (oder höhere) Version des SATA Standards konform. Es gibt einigen, gerade die frühen Modelle, die nur 1.0 vollständig einhalten und einige Optionen aus 2.0, vor allem die 3.0Gb/s. Das hat z.B. Intel bei der ICH7 (siehe S.44) damals auch gemacht und das führt nun einmal bei einigen Laufwerken zu Problemen, z.B. beim Aushandeln der Geschwindigkeit. Die Crucial m4 ist da weniger sensibel als eben die Samsungs, von denen schon die 830er unter diesem Problem gelitten haben.

Aber wie gesagt: Es kann sein, dass es mal mit den 3Gb/s klappt und mal nicht und das kann auch vom Port abhängen, jetzt pauschal zu sagen und XP gehen immer 3Gb/s aber mit Win7 nicht ist aufgrund von nur je einer Messung vielleicht verführt.

 

[KurzGedacht]

Der nvidia Treiber unter Win7 taugt nix.das Problem dürfte bei jeder ssd bestehen.

Gesendet von meinem Galaxy Nexus mit der Hardwareluxx App

 

[Hiserius]

Danke, wieder was gelernt

 

[spoilerhungary]

...das Problem ist zumindest für mich gelöst.

Hallo Forenleser,

das Problem ist zumindest für mich gelöst.
Folgendes habe ich gemacht, bzw. durch Ausprobieren zuerst vermutet und dann bestätigt bekommen
Das Board hat 6 SATA 2 Anschlüsse. Bisher waren an Anschluss 1 u. 2 je 1 SATA 2 HDD, an Anschluss 3 die SSD.

1. Bios neu geflasht , bestehendes BIOS überschrieben, aber mit „ Disable to keep DMI Data“.
2. Entsprechende Treiber von NVIDIA.de heruntergeladen (NVIDIA.png).
3. Im Gerätemanager alle IDE ATA / ATAPI Controller deinstalliert.
4. Nicht rebootet, sondern das NVIDIA Setup zur Installation der NVIVIA Treiber ausgeführt (Setup Nvidia.png ).
5. Reboot. AS SSD Benchmark zeigt den richtigen Treiber an, nvstor 32 ok ( Benchmark2.png), aber immer zu langsam. Auch kommt die Fehlermeldung von Magician (WIN 7 Boot Magician.png) nicht mehr, alle Funktion der Software sind jetzt ansprechbar
6. Nach langer hin und her Gestöpselei habe ich folgendes festgestellt: Die SSD zusammen mit meinen beiden anderen HDDs in beliebiger Kombination auf SATA 1 bis 3 gestöpselt :> immer läuft die SSD nur auf SATA 1, die 2 HDDs laufen immer auf SATA 2.
7. Die 2 HDDs auf SATA 1 bis 3 gestöpselt , die SSD auf SATA 4 bis 6 gestöpselt :> immer läuft die SSD auf SATA 2, die 2 HDDs laufen auch immer auf SATA2 (Benchmark Port 5.png).
8. Meine Vermutung, das die Controller den Mix SATA 2 HDD und SATA3(fähige) SSD nicht anständig verarbeiten können, habe ich als falsch
Bestätigt bekommen, weil wenn die SSD an SATA 5 und die HDD an SATA 6 Anschluss hängt (3. Controller), läuft die SSD immer noch auf SATA 2, die HDD auch.
9. Weitere versuche habe ich nicht mehr unternommen.

Danke an diejenigen, die sich des Problems hier angenommen haben.

Jürgen

 

[MoBo 01/04]

Sehr aufschlussreich. Danke für diese Rückmeldung.

 

[Holt]

Danke für den aufschlussreichen Test, der bestätigt was ich aufgrund anderer Posts schon nicht ausschließen konnte: Das es eben vom Treiber sondern Port abhängt.

69MB/s seq. schreibend sind aber für die SSD immer noch sehr wenig, die sollte 130MB/s erreichen. Kannst Du mal mit Trimcheck prüfen, ob TRIM funktioniert? Du musst das Tool mehrfach laufen lassen, denn beim ersten mal werden die Testdaten geschrieben und gelöscht, bei den weiteren Tests wird dann geprüft, ob die LBAs getrimmt wurden, was aber einige Sekunden bis Minuten dauert. Ich vermute mal, dass es nicht funktioniert, aber testen kann ich es mangels NVidia Board nicht.

 

[spoilerhungary]

Hallo Holt,

habe dein posting gelesen, danke.
Bin am hin und her probieren, immer mit verschiedenen Ergebnissen. Nutze auch ATTO Tool und das Tool von Samsung Magician, sowie den WIN Test. Diese zeigen mir immer bessere Seq.-Werte als AS SSD an. Leider bin ich bis jetzt noch nicht hinter das Geheimnis gekommen, mal sagt Trimcheck, Trim läuft, mal wieder nicht. Sobald ich reproduzierbare Ergebnisse habe, werde ich diese hier posten.
Ein Ergebnis ist die Erkenntnis, daß ich das BS nicht auf die SSD gepackt habe, es auf einer gleich große Partition auf einer der HDDs gelandet. Auch habe ich gesehen, daß die SSD mit 512 byte/sector läuft. Das 1. wird sein, die SSD mit 4kb/sector zu formatieren. Melde mich hier wieder, wenn ich wirklich was erreicht habe.

Jürgen

 

[Holt]

Auch wenn die Schreibrate ggf. geringer als bei einer HDD ist, so dürfte es doch deutlich schneller sein, wenn Du Windows auf der SSD statt auf einer HDD hast. Trimcheck prüft meines Wissens die Partition, wo es abgelegt wurde. Du es also auf die SSD kopieren, damit Du die testen kannst. Zwischen den Läufen sollte man möglichst wenig am Rechner machen und es sollten auch möglichst keine Programme im Hintergrund auf die getestete Partition schreiben, damit nicht die Adressen überschrieben werden, auch denen die Testdaten lagen.

Das AS-SSD eine viel geringer Schreibrate anzeigt, dürfte daran liegen, dass es mehrere Durchläufe macht und den Durchschnittswert anzeigt, während die meisten anderen Programme die Bestwerte anzeigen. Bei den ersten Durchläufen ist dann vermutlich die Schreibrate höher und fällt dann ab. Mache mal den Kompressionsbenchmark, der zeigt einigermaßen gut an, wie sich die Schreibrate mit der Zeit verändert. Da der Controller ja keine Datenkompression hat, müsste idealerweise ein waagerechter Strich für die Schreibrate entstehen.

 

[spoilerhungary]

Danke für die Tipps.
Trimcheck habe ich von der SSD aus gestartet. Den Kompress-Benchmark Test kannte ich bis jetzt noch nicht, bin zurück auf die WIN 7 Treiber und habe ihn dann laufen lassen. Sieht für mich nicht ok aus, die Ups and Downs auf der SSD. Selbst eine alte IDE 80 GB sieht besser aus,wenn ich min/max Differenz-Ausschläge vergleiche. Kann ich aus dem Kompress-Benchmark Test nun schlussfolgern, dass der SSD Contoller defekt ist ?

 

[Holt]

Defekt ist der Controller deswegen nicht, der hat wohl nur nicht viel freien Bereich zum Schreiben. Die NAND werden ja Pageweise (4k oder 8k, teils auch schon 16k) geschrieben und gelesen, aber können nur Blockweise (256, 512 Pages, also durchaus 1MB) gelöscht werden. Da man die Pages aber nicht überschrieben, sondern nur in schon gelöschte Pages schreiben kann, müssen die Controller regelmäßig mal Blöcke auswählen die sie Löschen wollen. Der Controller darf nun aber nicht einfach einen Block löschen, er vorher die noch gültigen Daten erst in andere Pages kopieren, sich also auch merken welche Daten gültig sind und welche nicht mehr und er muss eben auch die LBAs (logischen Adressen die von Rechner angesprochen werden) auf interne Flashadressen mappen.

Von der Auswahl welchen Block er als nächstes löscht, hängen dann so Eigenschaften wie die Write Amplification (das Verhältnis vom ins NAND geschrieben Datenvolumen zum von Rechner geschrieben Datenvolumen) und die Qualität des Wear Leveling (gleichmäßige Nutzung der P/E Zyklen aller Blöcke) ab. Dabei wird er dann gerne Blöcke auswählen bei denn möglichst viele Pages schon ungültige Daten enthalten.

Aber wie weiß der Controller, welches Daten nun ungültig sind? Erstmal sind alle Daten für ihn so lange gültig bis die Adresse (LBA) unter der diese abgelegt wurden, überschrieben wird. Dann wären die alten Daten an dieser Adresse auf einer HDD ja auch überschrieben und somit weg. Dadurch wird aber eine SSD dann schon nach einem normalen Formatiervorgang für den Controller voll sein, weil dabei ja alle LBAs einmal beschrieben werden. Dann hat er nur noch ein paar % freien Platz, den jeder Hersteller seinen SSDs mitgibt, denn es sind ja bei allen mindestens x GiB (1024^3Byte) verbaut aber maximal x GB (1000^3 Byte) verfügbar, was etwa 7% Unterschied ergibt. Wenn nun viel am Stück geschrieben wird, so gehen dem Controller halt schnell die freien Pages aus und es musst den oben beschriebene Vorgang ausführen. Dann kann keine SSD die maximale Schreibrate erreichen und wie stark der Einbruch ist, hängt davon ab wie in der gelöschten Page noch gültig waren und somit kopiert werden müssen.

Da wohl offenbar TRIM bei Dir nicht funktioniert, passiert genau das bei Deiner SSD und daher diese zackige Linie. Beim ersten Durchlauf dürfte die Schreibrate am Anfang höher gewesen sein, sofern Du nicht gerade erst vorher eine Menge geschrieben hast, etwa bei einem Benchmark.

---------- Post added at 11:09 ---------- Previous post was at 10:57 ----------

Jetzt habe ich ganz vergessen zu erklären, was TRIM ist. Dieses Löschen der Blöcke wird als Garbage Collection (GC) bezeichnet und muss bei jedem Flash Speicher durchgeführt werden, sonst könnte man die Kapazität nur einmal beschreiben. Aktuelle Controller führen auch im Idle so eine Garbage Collection aus, was als Idle-GC bezeichnet und leider oft mit der eigentlichen GC verwechselt wird. Damit der Controller bei der GC nun nicht noch Daten kopieren muss, die nicht mehr gebraucht werden, weil die Datei schon gelöscht wurde, hat man den SATA TRIM Befehl eingeführt. Über diese Befehle wird dem Controller dann auch mitgeteilt, welche Daten ungültig sind und somit gelöscht werden können. Bei Controllern mit Idle-GC (haben heute alle aktuellen SSD Controller) hat das den Effekt, dass der Controller nun so viel Platz als frei ansehen kann, wie der User auch im Filesystem sieht. Damit kann man dann eine entsprechende Datenmenge mit der maximalen Performance schreiben.

Das Problem mit TRIM ist, dass der Befehl erst später zum SATA Befehlssatz gekommen ist und daher nicht von allen Treibern und Controllern auch weitergereicht wird, weil sie ihn eben nicht kennen. Betroffen sind natürlich vor allem von solchen die schon vor der Einführung des TRIM Befehls entstanden sind.

 

[spoilerhungary]

Danke!
Trim wird aber mal als funktionierend und mal als nicht funktionierend ausgegeben.
Und selbst wenn in den Kompress-Bechm.Test direkt nach einer Performance Optimization durch die Magician Software laufen lasse (was wie Trim sein soll), ist das Ergebnis nur wenig besser.

Was kann ich nun noch machen,SSD neu formatieren,System neu installieren?
Evt. die Platte an ein anderes System hängen, und dort trimmen lassen? Das wäre dann aber auch nur eine kurzfristige Lösung.
Oder ist die SSD Contollerseitig nicht mehr zu retten ??



Kann ich die SSD unter LINUX mit Gparted oder mit diskpart "tunen"?

Nochmal danke für dein Mitgefühl, Jürgen

 

[Holt]

Die SSD mal in einem anderen Rechner zu benchen wäre vielleicht interessant, denn solche Einbrüche können auch durch anderweitige Zugriffe auf die SSD entstehen, was bei Systemlaufwerken ja immer mal vorkommen kann. Vielleicht liegt es auch am Treiber und wenn der andere Rechner einen anderen (Intel oder AMD) Chipsatz hat, dann könnte man mal sehen, ob ggf. der Treiber die Einbrüche verursacht. Die Treiber verwalten ja auch einen Schreibcache.

Ein Defekte der SSD liegt aber wohl nicht vor wenn das bei einer der Fall ist, dann sind bei den Samsungs i.d.R. die 4k Werte ganz mies. Ich würde mir darum jetzt aber nicht so viele Gedanken machen, das ist eben was so ein alter Chipsatz liefern kann und gut. Schneller als eine HDD ist es doch, oder?

 

[spoilerhungary]

Hier ist nun die Lösung

Hier ist nun die Lösung,
wie ich die SSD wieder "schnell" gemacht habe. Partiton gelöscht,um die Daten zu löschen, mit GParted. Partition erstellt, damit ich unter Magician "Secure Ersase" machen kann.
Partition mit 2 Mb Alignment erstellt, dann unter Win formatiert (4k).
Nacheinander die Tests laufen lassen, jeder Test bringt gute Ergebnisse.

Jürgen

 

[Holt]

Das war die Radikalmethode! Das Problem war also entweder, dass die SSD lange ohne TRIM gelaufen ist oder vielleicht (zusätzlich) noch eine große Fragmentierung des Filesystems. Auch wenn sich den Fragmentierung bei SSDs längst nicht so auswirkt wie bei HDDs, so führt es doch dazu, dass statt weniger langer Zugriffe viele kurze erfolgen und die sind dann eben langsamer. Irgendwann macht sich das dann, gerade in einem Benchmark, bemerkbar. Man sollte deshalb eine Partition nie zu voll werden lassen, selbst wenn TRIM funktioniert, denn wenn das passiert, steigt auch die Fragmentierung massiv an.