SSDs mit Sandforce Controllers SF1200 und SF1500 [Part 3]

Status
Für weitere Antworten geschlossen.
Also im BIOS kann ich nur einen Eintrag auf AHCI stellen. JEtzt ist mir aber noch ein Eintrag aufgefallen der auf IDE steht und den konnte ich noch auf SATA stellen.

AS SSD zeigt mir jetzt auch AHCI an.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also vom bios lass ich mal lieber die finger weg..Da sind ja jede menge einträge zum energiesparen.Hab nur mal speedstep und c1 deaktiviert,aber prozzi regelt sich trotz allem selber runter.Auch unter windows auf höchstleistung..

Außerhalb von Benchmarks bringt es sowieso keine Vorteile.
 
Zuletzt bearbeitet:
Ein paar Stündchen halt. Das SSD rödelt ja bei normaler Nutzung nicht ständig unter Vollast.

edit: Gerade wieder gebencht, läuft doch prima.

as-ssd-benchamd30stripbu2u.png


Die Werte sacken nur nach intensiver Nutzung und direkt darauf folgenden Benchen ab, erholen sich aber relativ schnell. Heute mittag habe ich zb. mit SSD_lastiger Software gearbeitet, Werte haben sich gut wieder eingependelt - ohne TRIM und im Raid.

...
 
Zuletzt bearbeitet:
Ein paar Stündchen halt. Das SSD rödelt ja bei normaler Nutzung nicht ständig unter Vollast.
Ok, bei mir geht der PC normalerweise nach 30 min in Standby, das wird wahrscheinlich zu knapp sein. Dann stell ich den Standby mal bei Bedarf ab, wenn ich so 2-3 Stunden weg bin.
 
Der SF besitz KEINE Idle-Time Garbage Collection. "Von alleine" ändert sich da garnichts an der Leistung, auch wenn man 10 Jahre wartet.

(Das war/ist nur bei Indilinx so.)
 
Supertalent Teradrive CT 128GB FTM12CT25H Firmware MP3P1

Hier mal noch ein paar Benchmarks zur FTM12CT25H. Scheint irgendwie nicht so bliebt zu sein? Zumindest findet man ja reviewmässig noch nix ausführliches darüber:

Platform war ein i5 760@160x20 auf nem Asus P7P55D-E und 2x Corsair XMS CL7 RAMs@1600Mhz 7-8-7-20. Platte hing am Intel Port.



unpartitioniert READ / WRITE:


partitioniert (Blocksize Standard)





Die aktuelle Firmware scheint wohl die Schreibwerte bissl gekillt zu haben ... im Vergleich zum hwluxx Kurztest jedenfalls.
 
Zuletzt bearbeitet:
@ DoubleJ: Dann erkläre mir mal bitte wie es dann kommt, daß sich meine SSDs nach starker Beanspruchung von der Leistung her wieder erholen?

Ich habe den Verbund schon desöfteren "gestresst", zb. mehrere GB. an Daten drauf kopiert, entpackt, gelöscht und das mehrfach hintereinander usw. usf. und immer wieder pendelten sich die gebenchten Transferraten a'la AS-SSD auf die zuvor geposteten Werte ein.

Vorher hatte ich Indilinx-SSDs, zuerst unter Vista und da brachen die nach hoher Last ständig ein, blieben auch so ziemlich auf diesen Level und stiegen in der Leistung erst wieder nach manuellen Trim.

edit: ..und es wird sogar noch besser. Habe gerade auf meinen 2ten SSD-Volume eine DVD encodet und direkt danach nochmal das Volume gebencht:

unbenannt06fh.png


..also irgendeine Methode muß da ja wohl greifen, denn TRIM geht ja im Raid definitiv nicht. ;)

.....
 
Zuletzt bearbeitet:
Richtig! Und der Bench erfolgte, im Gegensatz zu den letzten beiden zuvor geposteten, direkt darauf.
 
Ich habe ja auch nur gesagt, dass der Controller keine Idle-Time (= Leerlauf) Garbage Collection hat. Wenn du schreibst, räumt er natürlich auf, wie es alle vernünftigen Controller machen...
 
Dennoch macht es bei meinen SF-SSDs keinen Unterschied, ob ich die nun nach Beanspruchung oder nach einer zeitlang im "Leerlauf" benche. Die Werte brechen gebencht nicht ein, steigen sogar teils je länger die SSDs laufen. OHNE TRIM wie gesagt. Für mich zumindest ein Indiz, daß es bei Sandforce-SSD vollkommen schnuppe ist ob nun TRIM greift oder nicht. War bei den Indilinx ganz anders. Da konnte man regelrecht dabei zuschauen wie die einbrachen.
 
Zuletzt bearbeitet:
Und wann brechen sie dann bei dir ein?

Indilinx hat außerdem eine sehr aggressive Idle-Time Garbage Collection. Deswegen ist die Write Amplification auch so extrem hoch und die Teile nutzen sich so schnell ab.

Ich weiß ja nicht, ob wir von den gleichen Laufwerken reden?!
 
also wenn meine einbrechen erholt sich von allein rein ganrichts... eine verbesserung ist nur minimal zu verzeichen und eher der messungenauogkeit geschuldet-

Was ich mir bei dir vorstellen kann ist, da du ja 3 SF im Raid hast, es einfach nicht weiter runter geht als momentan...
1x60 GB SF macht ca 60 MB/s write wenn eingebrochen und bleibt recht stabiel auf diesem wert im AS Bench... 3x60 = 180 MB/s also das was du auch in etwa hast. dazu noch der Write Cache des Controllers und schon bist bei 210 MB/s.
Nicht eingebrochen sollte dein verbund gute 270 MB/s Seq write haben.

Das dein verbund eingebrochen ist sieht man übrigends recht gut am 4k Write, der sollte deutlich höher sein bei 3 SF 60 GB wenn nicht eingebrochen
 
Zuletzt bearbeitet:
Keine Ahnung wann die einbrechen. :d

Vieleicht kannst du mir ja eine "Methode" empfehlen, die ich noch nicht ausprobiert habe, um meine SSDs so zu fordern das sie einbrechen. Mir fällt da nix mehr ein.

Bei den SF meine ich meine OCZ Vertex2-E, bei den Indilinx Dingern, die mir übrigens 2x abgeraucht sind, von den Ultradrive GX & GX2 beide je 64GB und 1x 32GB.

@ Pinki: Das ist eher eine Milchmädchenrechnung. Da ich Raid ja nicht erst seit jetzt nutze sondern schon seit Jahren, weiß ich sehr genau, daß man den Transferstream eines einzelnen Laufwerkes nicht einfach Pi*Daumen hochrechnen kann x der im Volume eingebundenen Laufwerke. ;) ..außerdem laufen die letzten beiden SSD des Volumes ja schon seit Anfang an im Volume, hätten also den von dir vorgerechneten Einbruch auch schon seit Anfang an aufweisen müssen. Dem ist aber nicht so wenn du mal ein paar Seiten zurück blätterst, da ist ein AS-SSD Bench der gleich nach Konfiguration und Erstbetrieb im Volume erfolgte und (übliche Benchtoleranzen inbegriffen) fast identisch den jetzigen Werten entsprechen.

....
 
Zuletzt bearbeitet:
komisch... bei meinem Raid0 (sogar bei beiden) kann man des sehr wohl hoch rechnen, zumindest den seq Write, eingebrochen wie auch nicht eingebrochen... muss bei mir wohl anders sein als bei dir ;)

Eine Samsung 470 64 GB macht im Seq write ca 175-180 MB/s und im Raid0 verbund 360-365 MB/s
eine SF 60 GB macht uneingebrochen in etwa 90-95 MB/s seq write und in meinem Raid0 (2xSF 60 GB) ca 180 MB/s uneingebrochen
Eingebrochen macht meine SF einzelln ca 55-60 MB/s und im Raid0 dann eingebrochen 113-120 MB/s.... also hier kann man das sehr sehr schön hoch rechnen ;)

Glaub mir deine werte sind auf niveau von 3 eingebrochenen SF 60 GB, allerdings sind die ergebnisse ja dennoch recht hoch deswegen empfindest du die ergebnisse als gut und denkst sie seien nicht eingebrochen.
Das die ergebnisse in etwa dem entsprechen wie am anfang kann mehrere ursachen haben... es war bereits eine eingebrochen, der Controller ist eh an der grenze oder was weiß ich.
Schau die mein User Review zu meinen beiden Extrememory an, und das sind NUR 2 SSD´s, vergleiche mal die 4k Writes, so sehen die bei 2 SF im Raid0 aus wenn nicht eingebrochen.

zerpfluck das raid0 mal und bench ne einzellne dann siehst du das se eingebrochen sind insofern du keinen secure erase machst zuvor

Ach ich zeigs in bildern ^^

Hier 2 SF 60 GB im Raid 0 taufrisch

as-ssd-benchvolume_000kp2s.png


Und hier jetzt wenn eingebrochen wobei der einbruch noch recht klein ist, wird noch stärker hab erst vor 1-2 wochen nen secure erase gemacht

as-ssd-benchxlr8plusra1m2u.png


Niedriger 4k Read liegt an den C-States
 
Zuletzt bearbeitet:
Spieluhr, ist es bei dir möglich SMART Werte auszulesen?
 
Ok, nehmen wir mal an du hättest recht. Dann nenn mir eine Methode, die -deiner Meinung nach- die SSDs wieder resettet.

@ Cippoli: Hab das über RaidXpert deaktiviert. Werds aber wieder aktivieren. Einen Augenblick.

edit: Hab es aktiviert aber wie schon vermutet, wird im Raid nicht unterstützt.

edit2 @ Pinki: Da ich zwischenzeitlich mein Volume mal aufgelöst hatte (wollte nur ein 2er-Volume und ein SSD non_Raid laufen lasse), hab ich damals jedes SSD über die Raidconsole vom Board über das implementierte Secure Erase (0000-Folge) gelöscht. Die Werte danach waren nicht anders als davor. Aber ich werd das Raid einfach mal nachher auflösen, ist ja schnell gemacht, und die mal einzeln laufen lassen. Kein Thema. ;)
 
Zuletzt bearbeitet:
@ Cippoli: Hab das über RaidXpert deaktiviert. Werds aber wieder aktivieren. Einen Augenblick.

edit: Hab es aktiviert aber wie schon vermutet, wird im Raid nicht unterstützt.

Schade, man hätte da nämlich die Host-Writes zuhilfe nehmen können um festzustellen ob DuraWrite schon für jedes Laufwerk im Verbund aktiv ist (Phase 2).
 
und meiner erfahrung nach ausschließlich ein Secure Erase.

Entweder mit HDDErase oder mit der SF ToolBox

Aber ehrlich gesagt, bei 3 SF im Raid0 ist das ganricht mehr nötig, die werte sind eh sehr hoch und unterschied merkt man deswegen auch nicht...

das implementierte Secure Erase (0000-Folge) gelöscht. Die Werte danach waren nicht anders als davor. Aber ich werd das Raid einfach mal nachher auflösen, ist ja schnell gemacht, und die mal einzeln laufen lassen. Kein Thema. ;)

Ähm... das ist kein Secure Erase zumindest nicht ein solcher der die SSD wieder in den ursprünglichen leistungszustand versetzt.
Ein SecurErase mittels HDDErase oder eben über die SFToolbox, gibt den zellen kurzzeitig mehr strom, was die zellen in den Uhrzustand zurück versetzt (Gaaaanz grob erklärt)
Das was du da gemacht hast war lediglich die zellen mit 0en voll schreiben, das bringt dir garnix, außer einen weiteren schreibzyclus, ist also eher kontraproduktiv

Eine erklärung wie HDDErase funktioniert und was du machen musst bekommst du wenn du bei google mal OCZ und HDDErase eingibst, ist zwar in englisch aber mit eigentlich selbst erklärender bebilderung, solltest du es nicht hin bekommen (ist etwas kompliziert bzw umständlich) dann schreib mir ne PN dann erklär ichs dir, oder du schaust ob du die OCZ SF Toolbox her bekommst, damit ists dann etwas einfacher.
 
Zuletzt bearbeitet:
Vieleicht kannst du mir ja eine "Methode" empfehlen, die ich noch nicht ausprobiert habe, um meine SSDs so zu fordern das sie einbrechen. Mir fällt da nix mehr ein.
Wirklich nichts?

Code:
:START
xcopy c:\windows\*.* s:\windows\ /v/e/q/y
rmdir s:\windows\ /s/q
goto START
:fire:

Am besten noch die Zeit stoppen.
Falls du Hilfe bei einem funktionierende Skript brauchst, dag Bescheid.
Und ja, von sowas brechen sie ein.

mfg
 
Zuletzt bearbeitet:
So, hab jetzt mal den Verbund "kurzfristig" aufgelöst, Abbild liegt auf HDD und hier die 3 SSD solo.

1te SSD erst formatiert und mit W7:
c-ssdpmsp.png


2te SSD nix dran gemacht:
k-ssd3mlr.png


3te SSD über OCZ-Toolbox erase't (ging erst über AHCI im Bios):
f-ssdtmb7.png


Das Erasen scheint zumindest von der Zugriffzeit lesen und im Schreiben was gebracht zu haben. Im wichtigen 4k lesen aber nicht.

edit: Werd aber jetzt mal alle 3 SSD erasen, daß Raid drüber bügeln und dann mal langfristig beobachten wie sich das verhält.

edit2: Was mir gerade auffällt: Bei dem ersten SSD stimmt die Größenangabe laut AS-SSD nicht. 54,95GB?
 
Zuletzt bearbeitet:
Wenn es nicht zuviel Arbeit macht, wäre es schön wenn du noch SMART mit CDI auslesen könntest und die Screens in der Reihenfolge postet in der du die AS SSD Screens gepostet hast, damit man sie entsprechend zuordnen kann.

P.S. Wie hast du formatiert? Schnellformat?
 
Bei der 1ten über die Raidconsole. Dauert ca. 5min. und wird mit Nullen beschrieben.

OK, hier der CDI-Screen mit Smart in Reihenfolge s.o.:

 
Danke schön. Ich versuch mich dann mal in dem Kuddelmuddel durchzuarbeiten.

Als Hilfestellung zum besseren Verständniss der jeweilen Zustände/Phasen (am besten noch die letzten 5-6 Seiten lesen):

http://www.hardwareluxx.de/community/15992360-post233.html


SSD1 (Laufwerk C:) - 1344GB Host-Writes / DuraWrite aktiv (Phase 2)

Das beschreiben mit Nullen hat wie erwartet nicht die sequenzielle Schreibrate auf Phase 1 zurückgebracht.


SSD2 (Laufwerk D:) - 576GB Host-Writes / DuraWrite aktiv (Phase 2)

Hier ist DuraWrite aktiv, da man anhand der hohen Host-Writes davon ausgehen kann.


SSD3 (Laufwerk F:) - 2112GB Host-Writes / DuraWrite inaktiv (Phase 1)

Hier hast du durch Secure Erase das SSD resettet und damit auch DuraWrite. Das SSD führt solange nicht jeder Block mit Daten beschrieben wurde keine GC aus.
 
also wie gesagt, das beschreiben mit nullen bringt dir die leistung nicht zurück, wie gesagt, wenn secure erase dann mit HDDErase oder toolbox.
Mit nullen beschreiben kommt noch aus zeiten der HDD´s, hatte aber nicht den hintergrund was schneller zu machn sondern rest daten zu überschreiben damit se nichtmehr ausgelesen werden können.

So wie bei der die 90 MB/s Write hat (der 3. screen) so sollte das bei allen 3 aussehen , dann ohne groß im single zu benchen die teile wieder ins Raid0 und schauen wie es dann mit der leistung aussieht.
Aber erhoffe dir nicht zu viel, lang bleibt der speed dann nicht...
Habs hier sogar schon geschaft das se einbrechen obwohl ich ne woche lang nichtmal aufs raid zurück gegriffen hab.. sprich hatte von anderer SSD gebootet und auch nur mit der gearbeitet, das raid wurde nicht angetastet, nach 1,5 wochen wollt ich dann mal sehen was die leistung sagt und zack.. eingebrochen looool
Aber eigentlich isses ja egal, merkst eh nicht, im AS komprimiertest merkst auch nicht´s ob eingebrochen oder nicht.

PS:
Das mit der ersten wo nur 54,xy GB angezeigt werden ist eigenartig
 
Zuletzt bearbeitet:
@ Cippoli: Thx, für die Info. Hab jetzt alle drei SSD erase't, nun sollte diese "Phase 1" für alle gelten. ;)

@ Pinki: Ich weiß woran das liegt. Wie bei Festplatten ist im Volume ja das erste gesetzte LW. immer sozusagen das Master-LW wo der MBR mit den Einstellungen des Raid überschrieben wird. Daher hast du ja, wenn du ein Raid nicht "vernünftig" auflöst, nachher u.U. auch so ein Gemurkse mit dem Master-LW im Singelbetrieb. Gehe mal davon aus, bei SSD wird das grundsätzlich nicht anders sein.

So, hab das Raid nun wieder in alter frische über Systemabbild neu aufgebrutzelt:

as-ssd-benchamd30strip4m0x.png


(+) höhere seq. Schreibrate, höhere 4k-64 Schreibrate, niedrigere Lesezugriffzeit
(-) niedrigere seq. Leserate, ganz leicht niedrigere 4k Schreibrate
(=) 4k Leserate, 4k-64 Leserate, Schreibzugriffzeit

EDIT: UUUUUPS, mein Fehler! Hab vergessen im RaidXpert den auf Cippolis Anfrage aktivierten Smart-Status wieder zu deaktivieren. Diese Option bremst nämlich das Raid aus. ;)

So sollte es ausschauen:

as-ssd-benchamd30stripbm4n.png
 
Zuletzt bearbeitet:
hoppala... mein hochrechnen mit ca 270 MB/s seq write haut wohl doch hin *gg*
Aber dein 4k write kommt mir immernoch niedrig vor wenn ich das mit meinem vergleiche...
Hast den cache vom Raid Controller aktiviert?

Ansonnsten... soooo muss das aussehen bei 3 SF 60 GB ;)
Wobei ich davon ausgegangen bin das Seq read deutlich höher sein sollte, evtl bremst da irgendwas (irgendwelche stromsparmachnismen) oder ungünstige stripe size (für hohe seq Read ergebnisse)

Na ich werd mir nächsten monat ne 3. SF dazu holen um das mal testen wie es dann bei mir ist.

Was spuckt der AS Kopier bench aus ?
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
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