SSD mit Schreibrate: 66,3 MByte/s

A

A_H

Guest
Achtung: Nur 15295 von 60955 MByte getestet.
Fertig, kein Fehler aufgetreten.
Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
nochmals überprüfen.
Schreibrate: 66,3 MByte/s
Leserate: 131 MByte/s

H2testw v1.4

Traue keinem Test...

Bis jetzt halte ich das aber noch für einen ziemlich praxisgerechten Benchmark.

Es darf gerne gefragt, gerätselt, vermutet und diskutiert werden!
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich poste jetzt auch mal so ein Ergebnis aus heiterem Himmel ohne irgendwelche Informationen dazu:

TADA

Achtung: Nur 57881 von 122101 MByte getestet.
Fertig, kein Fehler aufgetreten.
Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
nochmals überprüfen.
Schreibrate: 180 MByte/s
Leserate: 174 MByte/s
H2testw v1.4


Edit:

Noch eine andere

Achtung: Nur 43064 von 61054 MByte getestet.
Fertig, kein Fehler aufgetreten.
Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
nochmals überprüfen.
Schreibrate: 147 MByte/s
Leserate: 185 MByte/s
H2testw v1.4


Edit 2:

Noch ne dritte!

Achtung: Nur 32674 von 60953 MByte getestet.
Fertig, kein Fehler aufgetreten.
Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
nochmals überprüfen.
Schreibrate: 124 MByte/s
Leserate: 198 MByte/s
H2testw v1.4
 
Zuletzt bearbeitet:
In deinem Post fehlt irgendwie eine wichtige Informationen.

Das war Absicht. ;)

Bisher wurde jede sachliche Diskussion mit dem Totschlagargument abgewürgt: Du willst nur trollen und eine bestimmte Sorte SSD madig machen. Diese Leute dürfen sich hier bitte raus halten.

Also lasse ich den Hersteller mal außen vor. Der spielt in dieser Hinsicht auch kaum eine Rolle.

Ein paar wichtige Informationen:
- SSD, MLC, 64GB, neueste Firmware.
- Windows 7 64, Treiber msahci.sys.
- Das System ist mit der aktuellen Firmware seit ein paar Wochen in Betrieb.
- Der PC befindet sich im "Normalzustand". DAS SYSTEM UND DER DATENTRÄGER WURDEN NICHT BEWUSST ODER UNBEWUSST AUF EINEN BENCHMARK VORBEREITET!


Vor ein einem Monat sah es noch so aus:

Achtung: Nur 38000 von 60955 MByte getestet.
Fertig, kein Fehler aufgetreten.
Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
nochmals überprüfen.
Schreibrate: 94,8 MByte/s
Leserate: 138 MByte/s
H2testw v1.4
 
Zuletzt bearbeitet:
Du hast uns also gezeigt, dass eine SSD Leistung verliert. Schön, aber nichts Neues.
 
SLC Systemlaufwerk, Virenzeug an, Superfetch an,Schattenkopie an -Nach einem Monat neuer Test:


 
Zuletzt bearbeitet:
Bei allen anderen scheint es mal wieder zu laufen. Scheint wohl mal wieder der User schuld zu sein und nicht das SSD.

Wie so oft.....
 
liegt bestimmt an der Datenintegrität des Users ^^
 
Bei allen anderen scheint es mal wieder zu laufen. Scheint wohl mal wieder der User schuld zu sein und nicht das SSD.

Wie so oft.....

Über Deine Äußerungen kann sich jeder halbwegs gescheite Mensch seine eigene Meinung bilden.


Ich kann das auch "zaubern":

Achtung: Nur 1000 von 60955 MByte getestet.
Fertig, kein Fehler aufgetreten.
Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
nochmals überprüfen.
Schreibrate: 95,0 MByte/s
Leserate: 138 MByte/s
H2testw v1.4

Du kennst die Zusammenhänge ganz genau und verschweigst sie absichtlich.

Bei 90% aller Nutzer, die sich nicht hier im Forum tummeln, dürften die praktischen Ergebnisse mehr bei meinen als bei Deinen liegen.

---------- Beitrag hinzugefügt um 17:46 ---------- Vorheriger Beitrag war um 17:45 ----------

liegt bestimmt an der Datenintegrität des Users ^^

"Betatester" und Pöbler raus! :fresse:
 
Zuletzt bearbeitet:
Ich kann das auch "zaubern":
Du kennst die Zusammenhänge ganz genau und verschweigst sie absichtlich.

Tja, blos dass ich NICHT manuell getrimmt habe wie du es mir vorwirfst. Ich hab das Wiper Tool bestimmt schon 4 Wochen nicht mehr genutzt.

Aber scheinbar willst du ja eh nur provozieren, pöbeln und falsche Fakten verbreiten.... so wie in jedem deiner Threads/Posts.
 
Indilinx Laufwerk auf SATA1-Controller? Irgendwas altes mit Jmicron?
 
Tja, blos dass ich NICHT manuell getrimmt habe wie du es mir vorwirfst. Ich hab das Wiper Tool bestimmt schon 4 Wochen nicht mehr genutzt.

Aber scheinbar willst du ja eh nur provozieren, pöbeln und falsche Fakten verbreiten.... so wie in jedem deiner Threads/Posts.

Du stellst ganz absichtlich falsche Behauptungen auf - Ablenkung, Nebelkerzen, Hütchenspielerei.

Ich habe eben auch nicht manuell getrimmt. "Falsche Fakten", wie macht man das? In 4 Wochen mache ich den Test noch mal; dann mit "Der Notar hat sich von der Richtigkeit...".

Ach so: Das Wiper Tool zerschießt bei mir leider das Dateisystem.
 
Zuletzt bearbeitet:
Du stellst ganz absichtlich falsche Behauptungen auf - Ablenkung, Nebelkerzen, Hütchenspielerei.

Ich habe eben auch nicht manuell getrimmt. "Falsche Fakten", wie macht man das? In 4 Wochen mache ich den Test noch mal; dann mit "Der Notar hat sich von der Richtigkeit...".

Ach so: Das Wiper Tool zerschießt bei mir leider das Dateisystem.

Ich kann ja nur vermuten, evtl. haste auch den freespacecleaner drüberlaufen lassen. Tja, dann müssen wir eben weiter deinen nebulösen Behauptungen lauschen wenn du uns nicht aufklärst was du überhaupt gemacht hast....

Warum sollte ich falsche Behauptungen aufstellen?

Wiper hat bei mir übrigens noch nie was zerstört. Wenn das allgemein so wäre würden sich tausende User beschweren......
 
Zuletzt bearbeitet:
Indilinx Laufwerk auf SATA1-Controller? Irgendwas altes mit Jmicron?

Es ist eine aktuelle SSD mit einem fast nackten Windows 7 und ein X38-Mainboard. Mit dem OS drauf ist die SSD wohl nicht schneller als 95MB/s im Schreiben. Wenn die leere SSD von einem andere Laufwerk aus gebencht würde, sähe es vielleicht noch schneller aus, aber wer hat das schon - außer einem Schlauberger.
 
Also entweder die "persönliche Note" verschwindet aus den Posts hier oder der Thread ist zu...
 
@Morpog
Dann will ich mal meine Vermutungen aus dem Sack lassen:
In "Eurem" Thread seid Ihr ja mit keinem Wort auf meine Feststellung eingegangen, dass es mit automatischem TRIM eine "leichte Schwäche" bei kleinen Dateien geben könnte. Zur Ablenkung kam das gezielte Störfeuer. Da hätte die FW also noch Verbesserungsbedarf. Um ehrlich zu sein: ich habe meine Zweifel, dass das so leicht in den Griff zu kriegen wäre. Oder anders rum: ich glaube schon zu wissen, wo der Hase im Pfeffer liegt. Die FW-Entwickler wissen das garantiert auch.

Falls das System abstürzt und man ein Backup zurück spielen muss, ist automatisches TRIM in der derzeitigen Form chancenlos. Ich hätte allerdings mit einer besseren "Selbstheilung" gerechnet.

Wenn man einen Bechmark mit genügend großen Dateien macht, dann wird nach dem Löschen der Testdateien natürlich getrimmt. Man möchte nur nicht einmal im Monat seine SSD sinnlos komplett voll schreiben und dann löschen. Das weiß fast jeder - es sagt aber nicht jeder.

---------- Beitrag hinzugefügt um 18:54 ---------- Vorheriger Beitrag war um 18:51 ----------

Also entweder die "persönliche Note" verschwindet aus den Posts hier oder der Thread ist zu...
Da habe ich aber schon Schlimmeres und Primitiveres erlebt. Wo war da ein Moderator - also bitte...
 
Das liegt dann aber an Win7, dass seine TRIM Kommandos verzögert raus sendet.

Klar ist TRIM chancenlos wenn man von einem anderen System, das kein TRIM unterstützt, ein Backup einspielt. Da kann aber die FW oder der SSD controller nichts dafür. Das ist eben ein Nachteil von ATA TRIM und der Flash Technik an sich.

Dann entweder vorher formatieren (mit dem Win7 Setup, dann wird getrimmt) oder manuell später einmal Wiper laufen lassen. Denn GC kann hier nur bedingt helfen.
 
Das liegt dann aber an Win7, dass seine TRIM Kommandos verzögert raus sendet.

Klar ist TRIM chancenlos wenn man von einem anderen System, das kein TRIM unterstützt, ein Backup einspielt. Da kann aber die FW oder der SSD controller nichts dafür. Das ist eben ein Nachteil von ATA TRIM und der Flash Technik an sich.

Dann entweder vorher formatieren (mit dem Win7 Setup, dann wird getrimmt) oder manuell später einmal Wiper laufen lassen. Denn GC kann hier nur bedingt helfen.

Für eine Verzögerung seitens Windows konnte ich keinen Anhaltspunkt finden.
Ich vermute, dass momentan nur getrimmt werden kann, wenn auf einen Rutsch ein gesamter Erase-Block (wie groß ist der nun?) frei ist. Wenn mehrere kleine Dateien in so einem Block gelöscht werden, dann wird vermutlich auch dann nicht getrimmt, wenn innerhalb des Eraseblocks die letzte Datei gelöscht wurde.

Es gibt vom Hersteller kein amtliches, manuelles TRIM-Tool. Die Defekte bei aktiviertem automatischen TRIM und gleichzeitigem manuellem TRIM sind bei mir leider mehrmals passiert. Dann kommt das Restore, und spätestens dann bin ich bei unter 80MB/s.

Ohne enge Verzahnung von Dateisystem, Treiber und FW ist wohl kaum etwas zu erreichen.

Ach so, wie bin ich auf die Angelegenheit gestoßen? Wenn ich beim jetzigen automatischen TRIM das manuelle TRIM gestartet habe, dann hat das rein optisch genau so ausgesehen, wie ohne automatisches TRIM. Man kann also ziemlich gut sehen, dass das automatische TRIM recht unvollständig ist.

---------- Beitrag hinzugefügt um 20:34 ---------- Vorheriger Beitrag war um 19:18 ----------

SLC Systemlaufwerk, Virenzeug an, Superfetch an,Schattenkopie an -Nach einem Monat neuer Test:

Ich habe gegrübelt, wie ich auf Deine Werte kommen könnte; bis ich die Buchstaben SLC verdaut hatte - Sch...ade.
 
Zuletzt bearbeitet:
Für eine Verzögerung seitens Windows konnte ich keinen Anhaltspunkt finden.

Antiram hat das mal in einer virtuellen Maschine mitgeloggt, soweit ich mich erinnere.

Ich vermute, dass momentan nur getrimmt werden kann, wenn auf einen Rutsch ein gesamter Erase-Block (wie groß ist der nun?) frei ist.

512Kb laut OCZ. Wäre aber irgendwie sinnfrei, da es dann so gut wie null Leistung bringen würde. Das kann ich bei mir aber nicht beobachten.

Wenn mehrere kleine Dateien in so einem Block gelöscht werden, dann wird vermutlich auch dann nicht getrimmt, wenn innerhalb des Eraseblocks die letzte Datei gelöscht wurde.

Glaub ich nicht.

Es gibt vom Hersteller kein amtliches, manuelles TRIM-Tool. Die Defekte bei aktiviertem automatischen TRIM und gleichzeitigem manuellem TRIM sind bei mir leider mehrmals passiert. Dann kommt das Restore, und spätestens dann bin ich bei unter 80MB/s.

Wieso muss das Tool amtlich sein? :hmm: Es gibt ein TRIM Tool namens Wiper und es basiert auf einer frühen TRIM Implementation seitens Indilinx als der TRIM Standard noch nicht festgelegt war.

Ohne enge Verzahnung von Dateisystem, Treiber und FW ist wohl kaum etwas zu erreichen.

Es ist doch jetzt schon eng verzahnt. Besserung könnte nur ein auf Flash optimiertes Dateisystem bringen. Wobei sich seit TRIM die Lage deutlich entspannt hat.

Ach so, wie bin ich auf die Angelegenheit gestoßen? Wenn ich beim jetzigen automatischen TRIM das manuelle TRIM gestartet habe, dann hat das rein optisch genau so ausgesehen, wie ohne automatisches TRIM. Man kann also ziemlich gut sehen, dass das automatische TRIM recht unvollständig ist.

Das liegt daran dass das Wiper Tool und das automatische TRIM nach ATA in Win7 unterschiedlich arbeiten.

Wiper erzeugt eine riesige Datei, liest die zugehörigen Sektoren vermutlich aus der Volume Bitmap von NTFS und schickt dann ein einziges TRIM Kommando an die SSD.

Win7 dagegen wird scheinbar nur in bestimmten Zeiten aktiv und schickt dann gesammelt viele TRIM Befehle los, die jeweils nur einige Sektoren säubern.
 
Ja. Wir sind uns dann aber doch einig, dass das manuelle TRIM noch jede Menge Daten findet, die das automatische TRIM übersehen hat?
Meiner Vermutung nach teilt Win 7 der SSD nur mit, von mir aus könntest du von Sektor xxx bis Sektor yyy trimmen, wenn du kannst. Und der Controller macht diesen :( weil das kein kompletter Eraseblock ist, oder so ähnlich.
Ich habe auf die Schelle nicht alles verstanden, was der Mann dort schreibt, aber wir scheinen in die gleiche Richtung zu denken:
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/

http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/

Wenn sich jemand seine SSD (auf eigenes Risiko!) genau betrachten will:
Acronis True Image 2009, Werkzeuge, Festplattenbereinigung, Gegenwärtigen Zustand der Festplatte ansehen, C: auf SSD anklicken, im Windows-Explorer auf C: kleine Textdatei öffnen, Zeichenkette kopieren, Textdatei löschen, in Acronis die Lupe/Suche anklicken, in das Textfeld die Zeichenkette eingeben, suchen. Sehr wahrscheinlich wir die Textdatei gefunden werden. Dann wurde nicht getrimmt. Sektornummer aufschreiben und gelegentlich wieder suchen. Ich habe bisher nicht erkennen können, dass ein solcher Sektor später noch getrimmt wurde; der wurde irgendwann einfach überschrieben.

Fazit:
Wenn ich eine Investition mache, dann will ich bei Problemen nicht die Schuld verteilen, sondern ich will das Problem weg haben. Wie unser Altbundeskanzler sagte:" Entscheidend ist, was hinten rauskommt."
http://de.wikipedia.org/wiki/Return_on_Investment
 
Zuletzt bearbeitet:
Ja. Wir sind uns dann aber doch einig, dass das manuelle TRIM noch jede Menge Daten findet, die das automatische TRIM übersehen hat?

Nö, wir sind uns nur einig dass das automatische TRIM von Win7 nicht sofort trimmt.
 
Nö, wir sind uns nur einig dass das automatische TRIM von Win7 nicht sofort trimmt.

Der Punkt geht an Dich!
Der Laufwerkscache der SSD spielt vielleicht eine Rolle (sollte man den deaktivieren?) oder die Volumenschattenkopie, aber bei zwei Tests war die Testdatei nach einem Restart weg.

Bleibt das Problem mit Backup/Restore, das sich mit H2testw und löschen der Dateien beheben lässt - 1 Mal im Monat wäre das wohl vertretbar.

Ich danke Dir!
 
Zuletzt bearbeitet:
Du solltest wenn du sowas testest auch den Papierkorb leeren, ansonsten wird Windows sicher keinen TRIM Befehl rausgeben, da die Daten dann nicht mehr wiederhergestellt werden könnten.
 
Achtung: Nur 15295 von 60955 MByte getestet.
Fertig, kein Fehler aufgetreten.
Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
nochmals überprüfen.
Schreibrate: 66,3 MByte/s
Leserate: 131 MByte/s

H2testw v1.4

Traue keinem Test...

Bis jetzt halte ich das aber noch für einen ziemlich praxisgerechten Benchmark.

Es darf gerne gefragt, gerätselt, vermutet und diskutiert werden!

Rannte heute wieder wie sau!

 
Es freut mich echt, dass Du an so etwas Deinen Spaß hast.

Ich habe das an anderer Stelle schon geschrieben, ich würde und könnte mir auch so eine tolle Rennmaschine zusammenbauen. Aber ich bin leider etwas zickig und vom Kopf her etwas schwierig. Ich muss für solche Sachen leider meistens eine praktische Verwendung haben, sonst werde ich hinterher ganz traurig. :(
Und ich gebe es zu, ich bin fast krankhaft geldgeil. Ich habe immer das zwanghafte Verlangen, für meine Ausgaben das Doppelte wieder rein zu holen.

Jedenfalls beneide ich Dich.
 
Es freut mich echt, dass Du an so etwas Deinen Spaß hast.

Ich habe das an anderer Stelle schon geschrieben, ich würde und könnte mir auch so eine tolle Rennmaschine zusammenbauen. Aber ich bin leider etwas zickig und vom Kopf her etwas schwierig. Ich muss für solche Sachen leider meistens eine praktische Verwendung haben, sonst werde ich hinterher ganz traurig. :(
Und ich gebe es zu, ich bin fast krankhaft geldgeil. Ich habe immer das zwanghafte Verlangen, für meine Ausgaben das Doppelte wieder rein zu holen.

Jedenfalls beneide ich Dich.

Na , ich hoffe, Du denkst bezüglich Frauen anders

Und....auf keinen Fall möchte ich beneidet werden.
 
Zuletzt bearbeitet:
das die KLEINE datei nicht getrimmt wird kann auch dran liegen, daß sie in der MFT gespeichert wurde. Die Cluster der MFT sind anscheinend alle als belegt gekennzeichnet. Die MFT ist ziemlich groß und liegt in der Mitte des Dateisystems (wenn man nicht resized). Man sieht sie nach W installation, wenn bloß zb. 20% belegt sind mit HDTune (Leseleistung über Kapazität aufgetragen). Die Zacken in der Mitte vom Dateisystem ist die MFT.

oder Defragprogramm Grafik angucken
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh