SSD als systemplatte?

hallo, bin zur zeit am überlegen ob ich mir eine ssd als systemplatte zulege.. spiele und daten sollen weiterhin auf meiner 500gb hdd installiert werden

da ich im internet überall nur verwirrede und z.T. stark veraltete empfehlungen / tests etc finde wollt ich mal bei euch um ne beratung bitten....

was ist momentan zu empfehlen? welche größe sollte ich nehmen? hatte an sich so an 25-50gb gedacht, lasse mcih allerdings auch gerne belehren...

was kosten denn gute geräte überhaupt? finde da zwsichen 50 und 5000€ alles *g*

hoffe mir kann wer helfen...

ach ja falls benötigt:

System:

Asus p5q pro
Core 2 q6600
9800gtx+
4gb 800er DDRRam
500gb maxtor hdd

So grob hat Weltenspinner schon recht. Hier im Forum finden sich immer wieder User, die noch Probleme mit ihren SSDs haben. Die OCZ Vertex klingen von Ihren Werten her z.B. super, schlagen sich an manchen Controllern sehr schlecht und werden zusätzlich, sobald der Speicherplatz einmal vollständig beschrieben wurde, langsam.
Die Intel SSDs sind da wohl besser, auch wenn deren Daten auf den ersten Blick eventuell gar nicht mal besser zu sein scheinen.

SLCs sind vor allem beim Schreiben die bessere Wahl, aber auch deutlich teurer. MLCs sind aus Sicht des Endbenutzers, günstiger, dafür beim Schreiben langsamer.

Die Haltbarkeit von MLCs ist für den privaten Einsatz kein Problem. Dank Wear-Levelling muß man sich da wohl keine großen Gedanken in den nächsten 5 Jahren machen.
Allerdings sollte man darauf achten, daß die SSD nach Möglichkeit nicht randvoll wird, da ansonsten die Geschwindkeit zusätzlich abnimmt.

Für eine OS-Platte würde ich also, ne nachdem, wie Sparsam Du bist, 32GB oder besser 64GB Vorschlagen. (Ich komme i.d.R. mit 15GB so eben aus - 4GB Swapfile mit eingerechnet). Da .Net Framework und andere Zusätze aber in letzter Zeit extrem zugenommen haben, wird das leider etwas knapp. 32GB wären bei mir mehr als nur genug, mit 64GB sollte man auch noch reichlich Luft für zukünftige Anwendungen jeder Art haben.

Eine 64GB SLC SSD kostet natürlich richtig viel Schotter (ca 700 Euronen):
http://www.heise.de/preisvergleich/a365724.html

Die Kingston E-Series (also SLC) konnte ich nun gar nicht auf Anhieb mit 64GB SLC finden.

@iamsiggi:
Diese Geschwindigkeitsabnahme soll bei der OCZ SSD ziemlich deutlich ausfallen. Also auch, sobald das Wear-Levelling einmal die ganze SSD "durch" hat. Mehr kann ich da auch nicht zu sagen - 7Oby ist da wohl der Spezialist. Der treibt sich wohl häufig genug bei OCZ im Forum herum und kennt dort die Geschichten der User besser.

Bei (guten) SLCs sollte das so oder so nicht so stark auftreten KÖNNEN, da SLCs ja besser zu beschreiben sind. Schön zu hören, daß bei Dir die SLC-SSD so gut rennt.

Hast Du rein zufällig ein paar Benchmarks in der Hosentaschen, die Du vorzeigen könntest? HD-Tune Pro, Atto, etc? (Wobei ATTO wohl eh nicht gerade aussagekräftig ist bei SSDs. HD-Tach brauchst Du erst gar nicht anwerfen. *g*)

Ich würde die privaten Tests von iamsiggi bevorzugen. Das ist halt eine handelsübliche SSD, kein "für PR-Zwecke-handselektiertes" Gerät, eine SSD mit SLC-Chips und in einem "normalen" Rechner eingebaut, der nicht nur für Benchmarks hergerichtet ist.
Das sind dann sozusagen realistische Werte. Natürlich nicht unbedingt ideal übertragbar, aber interessieren würden mich die Werte schon.

Vielen Dank!

Vor allem die Zugriffszeiten wollte ich sehen.
Schade, daß kein Write-Test möglich ist, aber man kann halt nicht alles haben.

Sieht aber ansonsten wirklich gut aus.

Gute N8.

@Siggi: Kann es sein, daß Deine "Wechselplatte" auch eine SSD ist? ... (OCZ irgendwas)
Ich wollte gerade schon fragen: "Welche normale SATA-Platte ist SO schnell?"

Habe nicht richtig aufgepasst, sonst hätte mir das auffallen müssen. Die Daten der Intel-SLC-SSD sind dann ja sogar nochmal besser als das vorherige Ergebnis und passt nun eigentlich auch erst zu dem, was Du geschrieben hast.

Gestern Nacht war's halt einfach schon zu spät... *zzzZZZzzz*

hi,

also um nochmal auf mein anfängliches "Problem" zurückzukommen...

hab mir die letzen wochen wieder einige tests durchgelesen und bin z.Zt. sehr an der Mushkin Eurpe 2 serie interessiert...

gibt es momentan gründ die gegen die laufwerke sprechen? sollte ich die 120er platte nehmen? meine mal gelesen zu habendass die irgendwie schneller als die 60er sein kann, finde das aber nciht wieder.. liege ich da richtig??

Es gibt durchaus einen Grund für eine größere SSD: Wear Levelling.

Zu volle SSDs sind nicht gut auf dauer, da es die Lebenszeit stark verkürzt. Wenn man mit 60GB also nur "soeben" hinkommt, dann sollte man lieber eine 80GB oder, falls es keine 80GB sondern nur 120GB gibt, eine 120GB nehmen.

Eine Randvolle SSD ist, vor allem mit MLCs eben nicht das beste, was man machen kann.

Ich behaupte nun einfach mal, ohne empirische Daten vorweisen zu können, 10GB sollten mindestens frei bleiben (wenn die SSD "voll" ist). Besser ist es, wenn etwas mehr frei ist.

Die Intel X25-M Postville hat eine geringere sequentielle Schreibrate. Dennoch ist sie insgesamt in der Praxis schneller. Designer von SSDs müssen einen Tradeoff zwischen sequentieller Datenrate und Zugriffszeiten (für kleine Dateien) machen und niemand macht das im Moment so gut wie Intel.

Damals als die ersten Indilinx Controller auf den Markt kamen hatte Anand (von www.anandtech.com) das Problem schnell erkannt u. folgende Empfehlung an die Designer abgegeben:

http://www.anandtech.com/storage/s [...] =3531&p=20

Wenn Du die Tests anschaust: Die Intel hat weiterhin eine etwas geringere Streamingrate (insbesondere bzgl. Schreibrate) dafür aber geringe Zugriffszeiten bei kleinen Dateien. In der Praxis wie die Tests zeigen wertvoller.

Darüberhinaus hat die Intel bisher KEINEN TRIM Support. Dieser ist für die Postville angekündigt (nicht für die alte X25-M, sondern nur für die neue X24-M "Postville" ). TRIM wird die Intel auch nur in Win7 funktionieren. Nicht für Vista wie für die SuperTalent (Indilinx). Das wird wohl per Firmware Update kommen.

Die SSDs könnten es nur selbständig, wenn sie das Filesystem kennen und verstehen würden. Zum einen ist dies unheimlich aufwändig - gerade mit der Einführung von SSD schießen Filesysteme wie Pilze aus dem Boden: ext4, Tux3, Btrfs, NILFS2, MFT (Managed Flash Technology). Zum anderen ist es immer schlecht wenn man in geschichteten Architekturen in die untere Schicht KnowHow der oberen Schichten verbastelt.

Aus dem Grund wurde TRIM "erfunden": Eine Filesystem unabhänigige Schnittstelle um der SSD mitzuteilen welche Datenblöcke "nicht mehr aktuell" sind. Natürlich braucht dies Erweiterungen am Filesystem Treiber, der letzten Endes die TRIM Kommandos verschicken muss. Deshalb auch erst Support ab Win7 u. neueren Linux Kernel versionen.

Wie gesagt: "Unabhängig vom OS" bedeutet "abhängig vom Filesystem". Denn wenn das OS Einträge im Verzeichnis (Master File Table bei NTFS und File Allocation Table bei FAT32) löscht, dann muss die SSD verstehen welche Datenblöcke gemeint sind.

Wenn ich das Namensschild an der Klingel des Mehrfamilienhauses entferne, muss das Kommando Wohnungsauflösung + Streichen kommen u. die gesamte Bude putzen. Dazu muss ich wissen welche Wohnung zur Klingel gehört, damit ich nicht die falsche Bude putze. Bei der Klingel ist das einfach - da hört man das.

Man könnte das übliche nennen: Potentiell Kinderkrankheiten. Ist ja nicht so, dass wir bei Festplatten u. SSDs in jüngster Zeit vermehrt Rückrufaktionen u. dringende Firmwareupdates ausstehen hatten. Auch die Indilinx Controller haben eine lange Zeit der Reife hinter sich.

Mitnichten. Spätestens bei gleichzeitigem Zugriffen mehrerer Betriebssystemthreads bist Du aufgeschmissen, da Du Raceconditions bekommst und nicht mehr auflösen kannst welcher Zugriff zu welchen Daten u. Verzeichniseinträgen gehört. MFT und Daten liegen im allgemeinen NICHT zusammen. Das sind somit mindestens zwei einzelne Schreib- bzw. Lesezugriffe (Bei der Platte kommen zwei Befehle an).

Jedes Filesystem speichert seine Einträge im Verzeichnis auf komplett unterschiedliche Art und Weise. Während FAT u. NTFS ihre Belegungstabellen zentralisiert speichern, verteilt ext2 (ext3/4) die Belegungsbitmaps quer über die gesamte Platte. Sie haben darüber auch ein komplett unterschiedliches Layout.

Da kommt sich überhaupt nichts in die Quere weil ein Betriebssystem die LBA Sektoren 64 - 50000 belegt und das andere Betriebssystem die LBA Sektoren 50001 - 100000.

Das Wear-Leveling macht die SSD transparent. Das führt im übrigen auch dazu, dass bei Deiner Füllung oben von 50% die Platte zu weitaus mehr als 50% belegt ist. Für jeden einzelnen Schreibzugriff nimmt sich die SSD zunächst einen leeren Erase Block (hat eine Größe von 64kb - 128kb) - selbst wenn Du da nur 512 Byte ablegst.

Das ist die Antwort auf deine Frage:

Die zwei Dateisysteme in unterschiedlichen Partitionen kommen sich nicht in die Quere weil sie sich über unterschiedliche LBA Adressen erstrecken.

Falls Du etwas ganz anderes gemeint hast: Nämlich vorn Windows XP und hinten Windows 7 mit TRIM Support. Und Du bootest jetzt Windows XP und modifizierst damit damit die NTFS Partition von Windows 7. Auch da kommt sich überhaupt nichts in die Quere. Das Filesystem bleibt konsistent. Das Nicht-TRIM fähige Windows XP sorgt halt dafür, dass manche Schreibzugriffe etwas langsamer von statten gehen (dann auch unter Win7 bis sich alles wieder zurechtgetrimmt hat).

--

Nimm zwei Blatt Papier Din A4 kariert. Auf dem rechten Bogen kannst Du Schreiben (irgendwelche Matheformeln rechnen). Für jedes Kästchen, dass Du beschreibst markierst Du im Linken Blatt, dass es belegt ist, indem Du das entsprechende Kästchen ausmalst. Das linke Blatt sagt Dir welche Kästchen rechts belegt sind. Willst Du etwas löschen, dann löscht Du zuerst im linken durch wegradieren. Anschließend im rechten wegradieren und kannst dann drüberschreiben.

Wenn jetzt zwei Personen unabhängig von einander mit den Blättern arbeiten: Der eine löscht immer links und rechts (TRIM Support Win7 ). Der andere ist faul, der löscht nur links (WinXP - kein Trim) und markiert so was er noch braucht u. was nicht. Die kommen sich nicht in die Quere. Anhand des linken Blattes sucht man sich eine freie stelle im rechten Blatt. Steht dort schon was muss man vor dem Schreiben radieren - steht dort nichts, kann man direkt drauflosschreiben.

Die Metapher besticht nicht durch Praxistauglichkeit, aber genauso funktioniert das Filesystem und TRIM. Eine SSD braucht den Radiergummi für's rechte Blatt. Eine Festplatte nicht, da sie einze Sektoren (512 Byte) schreiben kann unabhängig davon was dort zuvor stand. Eine SSD muss zuerst löschen.

Selbstverständlich weiß die SSD welche LBA Adresse auf welche Flash Page gemappt ist. Und zwar NUR die SSD. Das OS weiß das nicht. Mit und ohne TRIM.

Ich hab' niemals behauptet die SSD wüsste nicht welche LBA Adresse auf welche Flash-Page abgebildet ist. Das war bisher auch der Grund warum beim Flashen der Firmware bei SSDs teilweise alle Daten verloren gingen. Sie haben wohl an der Kodierung dieser Abbildung nochmal gedreht u. damit waren die Daten der SSD dann verloren.

In wessen Darstellung?

Die SSD erkennt, dass sie keinen leeren Eraseblock mehr hat. Sie wählt daher einen Eraseblock aus nehmen wir 0kb - 128kb und liest den Inhalt in ihren schnellen Cachespeicher. Anschließend löscht sie den kompletten Eraseblock. Und als letztens kopiert sie in die erste Page 0kb - 4kb die neuen Daten und 4kb - 128kb die alten Daten aus dem Eraseblock von denen sie nicht weiß ob das echte Nutzdaten sind.

Was Du damit gerade beschrieben hast ist genau die Stelle an der die Performance der SSD ohne TRIM runtergeht. Ab diesem Zeitpunkt ist die SSD "voll" und jedes Schreiben bedeutet ab dort (ohne TRIM) immer Lesen, Löschen, Schreiben.

Das löst sich alles in Wohlgefallen auf - keine Sorge.

Der Aspekt über den Du Dir die ganze Zeit den Kopf zerbrichst ist Wear-Leveling. Wir sind uns darüber einig, dass die SSD natürlich genau weiß welche LBA Adresse auf welche Flash-Page gemappt wird. Und das ist auch alles richtig was Du schreibst. Was Du übersehen hast, ist wie das Filesystem arbeitet. Dazu ein Beispiel u. Du siehst sofort wo die SSD aufhört zu wissen was belegt ist und was nicht.

Ich nehm' nochmal eine SSD mit 100000 LBA Sektoren. Die Abbildung von LBA Adressen auf Flashpage Adressen ist jetzt unwichtig. Nehmen wir nur eine NTFS Partition an u. das MFT (Master File Table) liegt in der Mitte u. belegt ein paar Sektoren ab LBA Sektor 50000.

Eine ziemlich große Datei liegt auf den Sektoren 60000 - 70000. Und Du löscht diese Datei. Was das Betriebssystem dann macht ist, dass es lediglich einen bestimmten Sektor im MFT modifiziert. Auch nicht löscht, sondern einfach die Datei aus dem Belegungsverzeichnis löschz. Es wird nur ein Sektor geändert u. wenn Du nach dem Löschen ein Undelete Tool verwendest, dann sie die Daten wieder da, weil sie physikalisch noch auf Sektor 60000 - 70000 liegen.

Was die SSD nun nicht wissen kann ist, dass gerade Sektor 60000 - 70000 frei geworden sind. Und genau das leistet TRIM. Mit TRIM sagt das OS der SSD: "Hey 60000 - 70000 sind jetzt frei". Das macht das OS ohne TRIM nicht (siehe Undelete Beispiel).

Wo der Unterschied zwischen TRIM und Wiper ist wird auch auf Wikipedia gut erklärt:
http://en.wikipedia.org/wiki/TRIM_%28SSD_command%29

Wiper kennt das NTFS Filesystem (und FAT32). Es versteht genauso wie Acronis Trueimage welche Sektoren einer Partition belegt sind und welche nicht. Das ist der Filesystem abhängige Part. Und Wiper löscht dann die Sektoren. Ein Betriebssystem löscht üblicherweise keine Daten - nur mit speziellen Erase tools.

Zunächst mal hast Du Recht: Eine SSD ist "schnell" voll in dem Sinne, das die leere Eraseblocks aufgebraucht sind. Dazu reicht schon die Auslagerungsdatei oder Systemwiederherstellung auf der SSD. Windows kritzelt einfach viel auf der Platte rum u. für die Schreibzugriffe werden immer schön neue ca. 128KB Eraseblocks angebrochen, so dass da bald nicht mehr viel frei ist.

Jetzt machen wir 'nen bißchen Mathematik, so dass auch Dein Wear-Leveling ganz einfach geht. Fuchteln wir nicht mit Eraseblöcken rum, sondern nur mit Flashpages 4kb. Sagen wir die SSD hat 10 Flashpages und 3 Ersatzpages. Der Sektor habe jetzt auch 4kb. Wenn man mit Sektorgröße 512 Byte rechnen will braucht man im folgenden an den entsprechenden Stellen nur noch Modulo 4kb und Ganzzahldevision einzustreuen.

Für die Kapazität von 10 Sektoren (= 40 kb) in unserem Beispiel hat das Betriebsssystem die LBA Sektoren 1 - 10 zur Verfügung. Die SSD hat eine Tabelle mit Mappings LBA -> Flashpage und eine Liste mit freien Flashpages. Beim Neukauf der SSD ist noch keine Flashpage beschrieben u. die eine Warteschlage freier Flashpages umfasst 13 Flashpages (10 + 3 Ersatzpages):

Jetzt fängst an die SSD zu beschreiben. Hat eine LBA Andresse noch keine Flashpage Nummer assoziiert, so bedienst Dich in der Warteschlage für freie Flashpages und setzt diese ein. Nach einer Weile könnte dies so aussehen:

Die Abbildung LBA -> Flashpage ist injektiv aber nicht surjektiv in die Menge {1, 13}. Jede LBA Nummer ist nun einer Flashpage zugeordnet u. ich hab's absichtlich etwas durcheinander gewürfelt.

Jetzt soll LBA 7 überschrieben werden. Nach der Tabelle wäre das Flashpage Nummer 9. Wear Leveling aber bedeutet, dass bei LBA 7 nicht ständig Flashpage Nummer 9 überschreiben werden soll. Die ginge sonst nämlich kaputt. Was nun passiert ist, dass aus der "Liste freie Flashpages" das vorderste Element entnommen wird (Nr. 6) und die Flashpage Nummer 9 hinten angehangen. Das sieht jetzt so aus:

Ich kann jetzt dreimal LBA 7 beschreiben bis zum zweiten Mal Flash Adresse 9 überschrieben wird u. habe die Lebensdauer verdreifacht.

--

Anmerkungen:
. das geht auch ganz ohne freie zusätzliche Flashpages. Die Abbildung LBA -> Adressen Flashpage ist dann eine Permutation u. somit ein Element aus der symmetrischen Gruppe. Aus der Zyklendarstellung folgt dann, dass man einen beliebigen Zweierzykel für jedes Wear-Levling anhängen darf. Umgangsprachlich: Vertausch auf der rechten Seite der Tabelle einfach zwei Zahlen und es bleibt eine Permutation.
. Hat man keine freien Flashpages, so muss man für jeden Schreibzugriff 2x schreiben (Vertauschen zweier Elemente der rechten Tabellenseite). Da alle Flashpages belegt sind, löst sich ein Schreibzugriff auf eine Page in 1x Lesen einer Page u. 2x Schreiben von Pages auf.
. Wichtig ist eigentlich nur: Die freien Flashpages braucht man nur, um das Wear-Leveling performant implementieren zu können. Man spart sich 1x Lesen + 1x Schreiben. Es ginge auch ganz ohne freie Ersatzpages. Man schreibt umgangssprachlich "Reihe um"

Ich denke Du müsstest Dir mehr Mühe geben den Sacheverhalt zu verstehen oder präzise Fragen zu stellen. Ich kann versuchen Deine Fragen direkt zu beantworten (denn mir sind die Antworten jeweils absolut klar), aber ohne, das vorangegangene wird Dich das nicht wesentlich weiter bringen:

Wenn OHNE TRIM alle Flash Zellen belegt sind, werden beim Schreiben auf die selbe LBA Adresse trotzdem immer andere Flashzellen beschrieben. Damit dies effizient gesehen kann, gibt's ein paar Reserverblöcke. Erklärung siehe vorangegangenes Posting.

Die LBA -> Flashpage Tabelle sagt ob eine Flashpage belegt ist oder nicht.

Es gibt keine LBA Adressen, die vergeben sind. Denn wenn das OS sagt, dass es LBA Adresse 0 (= MBR) überschreiben will, dann will es genau das und keine andere LBA Adresse überschreiben.

--

P.S.
. Man kann LBA Adressen unabhängig von TRIM u. Wear-Leveling verstehen (= ist ja einfach machen Festplatten ja genauso u. die haben beides nicht).
. Man kann TRIM ohne Wear-Leveling verstehen, denn TRIM ist nichts weiter als ein Löschkommando (Parmeter: Start-LBA und Anzahl LBA Adressen, die genullt werden).
. Und man kann Wear-Leveling verstehen ohne TRIM, denn im Moment gibt's quasi nur eine TRIM fähige SSD u. alle machen Wear-Leveling.

Wenn man alles einzeln verstanden hat, kann man das beliebig zusammenbauen u. puzzeln. Vielleicht hilft Dir das.

Während Reserverblöcke bei Festplatten hauptsächlich dazu da sind um defekte Sektoren ersetzen zu können, ist das nicht der primäre Grund für Reserveblöcke bei SSDs. Wie ich schon sagte haben Reserveblöcke bei SSDs fast ausschließlich die Funktion das Wear-Leveling effizient implementieren zu können.

Ist im Absatz Free Space to the Rescue auch ansatzweise erläutert:
http://www.anandtech.com/storage/s [...] i=3531&p=9
und insbesondere:

Wie Du siehst tritt Dein Fall in der Praxis so nicht auf, da SSDs eine höhere Kapazität besitzen als sie dem OS mitteilen.

Wenn es keine Ersatzblöcke gäbe, dann hat die SSD zwei Möglichkeiten: kein Wear Leveling machen. D.h. also jeden LBA Block immer in die gleiche Flashzelle schreiben. So dumm waren aber selbst die allerersten CompactFlash Karten wohl nicht.

Statt dessen werden in den LBA -> Flashzellen Mappings immer zwei Einträge vertauscht. Zu Beginn ist das Mapping beispielsweise so:

LBA -> Flashzelle

1 -> 1
2 -> 2
3 -> 3
4 -> 4

beim nächsten Schreiben auf LBA 1 werden zwei Mappings vertauscht:

1 -> 2
2 -> 1
3 -> 3
4 -> 4

beim nächsten Schreiben zwei andere:

1 -> 3
2 -> 1
3 -> 2
4 -> 4

beim nächsten Schreiben von LBA 1 wieder andere:

1 -> 4
2 ->1
3 -> 2
4 -> 1

Du siehst, dass LBA 1 immer wo anders gelandet ist. Warum das so einfach ist, liefert eben die Zyklentheorie, die man üblicherweise in der Hochschule 1. Semester Lineare Alebra lernt.

Jetzt nochmal näher angeschaut was beim Austaschen passiert. Zunächst sah es so aus:

lba -> flash
1 -> 1
2 -> 2
3 -> 3
4 -> 4

Beim Schreiben vertauscht der Controller das mapping und kopiert dazu den Inhalt von Flash Zelle 2 in Zelle 1:

// copy flash
flash_cell(1) := flash_cell(2)

// remap table
help = lbatoflash(2)
lbatoflash(2) = lbatoflash(1)
lbatoflash(1) = help

// write flash:
flash_cell(lbatoflash(1)) := content

1 -> 2
2 -> 1
3 -> 3
4 -> 4

Bei diesem ersten Schreiben auf LBA Adresse 1 wurde Flash Zelle 1 auch noch beschrieben (nämlich mit dem Inhalt von Flash Zelle 2). Allerdings schon beim nächsten Schreiben von LBA Adresse 1 wird Flash Zelle 1 nicht mehr berührt, dann sind nur Zelle 2 und 3 involviert im übernächsten Schritt ist dann auch Zelle 2 raus ...

Bei einem Schreibzugriff auf eine Flashzelle muss ohne Ersatzflashzellen 2x geschrieben werden und 1x gelesen. Das ist der Preis in diesem Fall für's Wear Leveling.

--

Wer sich die Mühe gemacht hat bis hierhin zu folgen, der stößt dann irgendwann noch über den Garbage collection Begriff.

http://www.ocztechnologyforum.com/ [...] post420384

--

Wieviel TRIM ausmacht wollte ich gestern noch herausfinden u. posten. Habe mich dazu durch die Benchmarkliste in diesem Titelthread geblättert:
http://www.hardwareluxx.de/communi [...] p?t=637083
Allerdings sind die Effekte sehr schwer in Zahlen zu fassen, da die Varianz sehr hoch ist. Der automatische Garbage Cleaner im Hintergrund tut etwas (wobei das nur andere Dinge optimieren kann als TRIM, aber TRIM gibt dem GC mehr freie Blöcke) in Idle Phasen. So fallen die Ergebnisse sehr unterschiedlich aus u. hängen auch von der Firmware Version ab. Ab Firmware 1320 gab's das Wiper Tool (manuelles TRIM). Die heftigste Performance degraduierung habe ich hier gefunden (leider muss man registriert sein, um die Ergebnisse zu lesen):
http://www.hardwareluxx.de/communi [...] st12009016
Die 4kb Schreibperformance nach Atto (sicher nicht der beste Test) liegt dort bei 32MB/s ohne TRIM und 80MB/S getrimmt.
Die sequentielle Schreibrate liegt bei 50MB/s ohne TRIM vs. 150MB/s mit TRIM.

So heftig ist es jedoch selten. Bei manchen sieht man nach Monaten kaum Änderungen z.B. hier (ohne ohne Registrierung zu lesen AFAIK):
http://www.hardwareluxx.de/communi [...] count=1814

Mit der Firmware 1711 gibt's ja (leider) noch ein Problem bzgl. Datenkorruption. Sehr ärgerlich:
http://www.anandtech.com/storage/s [...] =3631&p=15

Wenn möglich zurückflashen. Oder sich in diesem Thread Hilfe holen:
http://www.hardwareluxx.de/communi [...] p?t=637083

Oder einfach abwarten. Man arbeitet wohl mit Hochdruck daran. Firmwareupdate könnte jederzeit erscheinen.

@ 7oby
1. danke für die info (werde warten auf neue FW)
da ich mein sys sowieso neu mach wenn ich die kaufversion vom w7 hab
und datenverlust da kein Problem für mich ist.

hast du die gleiche ssd oder ne baugleiche/ähnliche und ähnliche werte ?

Uuh, jetzt habe ich mal den Thread so halbwegs gelesen. Hierzu waere noch eine andere Loesung interessant, die leider so wohl nicht auf einem IBM-PC funktioniert:

Man laesst das DOS direkt auf der Festplatte laufen. Vorteile: Festplatte erledigt selbstaendig alle Aufgaben. Festplatte verwaltet das Dateisystem. Dem eigentlichem OS waere es dann egal, welches Dateissystem genutzt wird. Performanz waere vielleicht ein Plus. Zumindest braeuchte man dann keine großartigen Treiber mehr, weil der Platte ja nur noch Kommandos uebergeben werden muesen.

Nachteil waere der Preis, und das man an ein bestimmtes Dateisystem gebunden waere, zumindest solange man nicht der Platte ein anderes Dateissystem beibringen kann.

Also das System, wie es die alten Commodore-Computer verwendet haben. Und waere beim C64 der IC fuer die Serielle Datenuebertragung nicht verbuggt released worden, waere es sogar recht schnell gewesen.

es kann viele umstände geben das eine ssd nicht optimal läuft.
(sata1, nicht am 1.sata channel, nicht das benchmark programm genommen was zu den werbe ergebnissen führt bzw einstellungen, sata treiber, blockgrösse beim formatieren unter xp ?, ide oder ahci)

was für benchmarkeinstellungen hast du ? (blockgrösse)

4 kb blöcke average 43 mb/s
64 kb - 180 mb/s
1mb - 205 mb/s
8mb - 210 Mb/s

das sind die werte meiner ssd st 60gb gemessen mit hd tune 2.55 (lesen)
die blockgrösse ist also entscheident.
wenn du mit 4 kb blöcken gebencht hast ist das ergebniss sogar in ordnung

Im Intel-Chipsatztreiber ist kein AHCI-Treiber enthalten.

Damit sich überhaupt ein AHCI-Treiber installieren lässt (da gibt's für Dich im wesentlichen zwei: 1x Microsoft AHCI.SYS u. 1x Intel IASTOR.SYS), muss der SATA-Controller im AHCI Betriebsmodus sein. Wenn es für AHCI/IDE im BIOS keine Möglichkeit zum Einstellen gibt, dann ist Dein Netbook auf IDE festgelegt u. daran kann man dann nichts ändern. Ob dies der Fall bei Dir ist kann ich Dir sagen wenn Du im Gerätemanager auf dem Sata Controller rechte Maustaste Eigenschaften / Reiter Details / Eigenschaft: Hardware-IDs die Werte für

VEN_8086&DEV_2829

postest. Speziell die vier Zahlen hinter DEV sind dabei wichtig zu kennen. IDE gegenüber AHCI bringt minimale Performancevorteile, die liegen aber im Bereich von ca. 1%. Ein Netbook mit SSD selbst im IDE Betriebsmodus bringt ca. 100 MB/s selbst an SATA-1 Controllern vgl. z.B. hier:
http://www.tomshardware.com/de/for [...] tune-werte

Poste auch mal bitte einen Screenshot von diesem Benchmarktool:
http://crystalmark.info/software/C [...] dex-e.html

Die Transcend, die Du gekauft hast sollte eigentlich schneller als 30MB/s sein - auch wenn es eine der schlechtesten u. langsamsten SSDs ist, die man für Geld kaufen kann.

Anhand des Screenshots sehe ich, dass der SATA Controller im IDE Betriebsmodus läuft (DEV_27C4). Im AHCI Betriebsmodus wäre dies bei Dir DEV_27C5). Wenn man's im BIOS nicht umstellen kann - dann geht das nicht wie bereits gesagt. Ist aber üblich für Netbooks.

Zur Performance in CrystalDiskMark: Bei den sequentiellen Übertragungsraten bestätigt es Deine Messungen mit HDTune u. liegt etwa auf dem Niveau einer nicht mehr ganz so taufrischen 5400er Notebook Platte.

Bei den 4kb Leseraten erkennt man die Ambitionen zur SSD mit 8,7 MB/s. Hier liegt eine 5400er Festplatte bei etwa 0,3 MB/s u. eine moderne SSD bei gut Faktor 3x gegenüber Deinen Werten. Bei den 4kb Schreibwerten offenbart sich die gesamte Grausamkeit: Mit 0,17 MB/s bis Du gut 3x langsamer als eine 5400er Notebookplatte u. etwas 50x langsamer wie eine aktuelle (günstige) SSD - die liegt bei knapp 10 MB/s bei den Test.

Die Vergleichs-SSD wäre eine 64GB Supertalent Ultradrive GX für ca. EUR 150,-.

Trotz "SLC" im Namen. Ich führte die Transcend ist so langsam. Sie waren es immer. Kann bei der SSD (JMicron Controller denke ich) auch zu fürchterlichen LAGS (= Aussetzern / Hängern) beim Installieren von Software oder Durchstöbern von e-Mails kommen.

Hab die HDD wieder eingebaut. Anbei die Werte.
Was sagt dein geschultes Auge dazu?

Es handelt sich um eine WDC WD1600 BEVT-22ZCT0

Danke im Voraus und Grüße!



Vince

Achtung, es folgt eine Vermutung:

Bei Festplatten ist der Unterschied zwischen AHCI und IDE-Modus herzlich gering ausgeprägt, wobei im AHCI-Modus noch vor "kurzem" zwingend Treiber für die Installation eines OS nachgereicht werden mußten (F6 + Diskette für WinXP, falls nicht bereits auf der CD integriert).
Wenn sich der Hersteller dann dazu entschlossen hat das BIOS "reibungsfrei" voreinzustellen, also eben so, daß die angebotenen Konfigurationen gut funktionieren und Enduser nicht bei einer Neuinstallation plötzlich vor dem Problem stehen, daß die Platte nicht gefunden wird, da im BIOS der AHCI-Modus aktiviert wurde, dann wurde auf diese Option im BIOS vielleicht schlicht und einfach verzichtet.
"Brauchen die User nicht bei unseren verbauten Platten; es verursacht nur Supportaufwand, wenn es aktiviert wird und dann eine Neuinstallation versucht wird."

Also wäre das ein rein wirtschaftliches Interesse. Ebenso könnten zu der Zeit, als das Notebook entwickelt wurde, noch andere Gründe vorgelegen haben... z.B. nicht behobene Errata im AHCI-Modus.

Das ist aber nur Spekulatius... *knusper*... äh... Spekulation. Ob man trotzdem in den AHCI-Modus kommt, eventuell durch das flashen eines fremden oder modifizierten BIOS, ohne gleich das Notebook zu schrotten, weiß ich nicht.

Vielleicht hat 7Oby noch ein paar passende Ideen zur Hand.