SSDs mit Sandforce Controllers SF1200 und SF1500 [Part 3]

Status
Für weitere Antworten geschlossen.
Ich hab' jetzt grade Windows neu installiert, die SSD hängt jetzt am JMicron Controller des Boards und die HDDs weiterhin am Standard AMD Controller im RAID. Funktioniert auch alles wunderbar, allerdings sagt mir SSDLife dass die SSD nicht unterstützt wird, wird wohl am JMicron liegen... (Vorher hat SSDLife gar keine SSD erkannt) Wenigstens stimmt jetzt das Alignment.

Ach, das RAID hat schon 2 Austauschboards, diverse BIOS-Updates und Controllerumstellungen völlig Problemlos überlebt, da mache ich mir wenig Sorgen. Nein, ich habe von den Daten kein Backup, nur von den wichtigsten die da drauf sind.

Ich hab' mal eine Frage: Wie kann ich Windows dazu bewegen nur von C: ein Systemabbild zu machen? Hab' schon im Gerätemanager den Laufwerksbuchstaben von D: gelöscht, bringt aber nichts. Hilft wahrscheinlich nur die D: Platten abzuziehen oder?

Naja, ich werde jetzt erstmal wieder alle Programme installieren und das System fit machen...

Gruß und Danke für die Hilfen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Kann sein, daß deine D-Partition aktiv ist oder Auslagerungen dahin statt finden. Das erste siehst in der Datenträgerverwaltung, das zweite unter Erweiterte Systemeinstellungen -> Leistung -> Einstellungen -> Erweitert -> Virtueller Arbeitsspeicher -> Ändern. Selbst wenn da das Häckchen für Auslagerungsdateigröße automatisch verwalten gesetzt ist, setz lieber manuell alle Partitionen/Platten, bis ebend auf C, auf keine Auslagerungsdatei.
Kann nämlich sein, daß Win da noch mit irgendwelchen Alteinstellungen aus dem Tritt kommt.
 
Jup, D: ist Aktiv, Einstellungen hab' ich wie Du gesagt hast geändert. Ich werde jetzt erstmal neustarten.

Gruß

EDIT: Systemabbild geht jetzt, er will nicht mehr D: mitsichern! Danke Dir!
 
Zuletzt bearbeitet:
Ich hab mich wohl falsch ausgedrückt. Unter Drosselung wird wohl nur die Reduktion der Schreibrate bei massiver Überbeanspruchung des Laufwerks bezeichnet. Also wenn jemand wirklich praktisch nonstop auf das Laufwerk schreiben will. Dann bringt die Drosselung auch etwas für die Lebensdauer des Laufwerks. Aber eben nur wenn man praktisch nonstop schreibt, also jeder normale Desktop User sollte die Drosselung nie sehen, da sie im Desktop Fall auch nichts bringt. Sobald der User Pausen beim Schreiben auf die SSD macht bringt die Drosselung nämlich genau nichts, da in den Pausen die SSD die Zeit hat auch mit tieferen Schreibraten doch alle Daten draufzuschreiben.

Es gibt ja aber auch noch eine zweite Art der Reduktion der Schreibrate (welche aber wohl keine Drosselung in dem Sinn ist): Sobald das Laufwerk das ertste mal komplett beschrieben wurde reduziert sich die Schreibrate (von 130MB/s auf ca. 90MB/s angeblich, mein eigenes Laufwerk ist noch nicht so weit). Die Ursache dafür sei, dass bei einem Trim die Blöcke nicht direkt gelöscht werden, sondern erst wenn sie das nächste mal beschrieben werden sollen. Das dies sinnvoll ist kann ich nachvollziehen bei halb beschriebenen Blöcken. Aber alle komplett beschriebenen und getrimmten Blöcke könnten doch direkt nach dem Trim gelöscht werden. Das braucht keine Reorganisation von noch gültigen Daten, noch muss dann zwingend auf diese Blöcke später als erstes geschrieben werden (wenn sie zum Beispiel schon viele Cylcles haben). Aber die Verzögerung des Löschens bis zum nächsten Write ist völlig unnötig. Wieso soll man Daten die nie wieder jemand braucht, und die als einzelner Block gelöscht werden könnten (ohne Einfluss auf andere Blocks) nicht direkt gelöscht werden?
 
Zuletzt bearbeitet:
Palomino2000 schrieb:
Verstehst du jetzt, was ich meine?

Ich gehe davon aus, dass viele Reviewer gar nicht wissen was sie da eigl. benchen, selbst wenn sie auf Phase 2 oder 3 versehentlich stoßen, wissen viele vermutlich nicht was es damit auf sich hat. Sandforce gibt nur das nötigste an Infos weiter.

Dennoch sollte man sich jetzt nicht zu sehr auf diese Einbrüche versteifen. Es ist im Grunde nichts was sich negativ auf den Alltagsbetrieb auswirken sollte. Das SSD bleibt schnell, es geht hier nur um die sequenzielle Schreibleistung bei nicht komprimierbaren Daten.

mmoeller schrieb:
Ich hab mich wohl falsch ausgedrückt. Unter Drosselung wird wohl nur die Reduktion der Schreibrate bei massiver Überbeanspruchung des Laufwerks bezeichnet. Also wenn jemand wirklich praktisch nonstop auf das Laufwerk schreiben will. Dann bringt die Drosselung auch etwas für die Lebensdauer des Laufwerks. Aber eben nur wenn man praktisch nonstop schreibt, also jeder normale Desktop User sollte die Drosselung nie sehen, da sie im Desktop Fall auch nichts bringt. Sobald der User Pausen beim Schreiben auf die SSD macht bringt die Drosselung nämlich genau nichts, da in den Pausen die SSD die Zeit hat auch mit tieferen Schreibraten doch alle Daten draufzuschreiben.

Ich kann immer noch nicht ganz verstehen auf welches Problem du eigl. hinaus willst. :hmm:

Die Drosselung ist da um die Haltbarkeit zu erhöhen. Punkt.

Deine Non-Stop Theorie ist absurd. Ich bezweifle, dass die Laufwerke sich so weit herunterdrosseln werden, dass sie auf einen Niveau gelangen, wo nicht mehr mit ihnen gearbeitet werden kann. Nach den ganzen cleveren Features, die man in den Controller eingebaut hat, kann ich nicht glauben, dass man sich so einen Schnitzer leistet.

Nun wäre es wirklich mal interessant zu sehen, ob es nach Phase 3 (50% sequenziell Schreibleistungsverlust ausgehend von Phase 1) auch noch eine 4. Phase oder gar 5. gibt.

Freiwillige die das mal testen wollen? Palomino2000? :d

mmoeller schrieb:
Es gibt ja aber auch noch eine zweite Art der Reduktion der Schreibrate (welche aber wohl keine Drosselung in dem Sinn ist): Sobald das Laufwerk das ertste mal komplett beschrieben wurde reduziert sich die Schreibrate (von 130MB/s auf ca. 90MB/s angeblich, mein eigenes Laufwerk ist noch nicht so weit). Die Ursache dafür sei, dass bei einem Trim die Blöcke nicht direkt gelöscht werden, sondern erst wenn sie das nächste mal beschrieben werden sollen. Das dies sinnvoll ist kann ich nachvollziehen bei halb beschriebenen Blöcken. Aber alle komplett beschriebenen und getrimmten Blöcke könnten doch direkt nach dem Trim gelöscht werden. Das braucht keine Reorganisation von noch gültigen Daten, noch muss dann zwingend auf diese Blöcke später als erstes geschrieben werden (wenn sie zum Beispiel schon viele Cylcles haben). Aber die Verzögerung des Löschens bis zum nächsten Write ist völlig unnötig. Wieso soll man Daten die nie wieder jemand braucht, und die als einzelner Block gelöscht werden könnten (ohne Einfluss auf andere Blocks) nicht direkt gelöscht werden?

Fangen wir von vorne an - denn ich sehe du hast dir das "Indilinx denken" angewöhnt. ;)

Um Daten innerhalb der NAND-Flashzellen speichern zu können werden Zellen in 4 KB großen Pages unterteilt. Meist entsprechen 128 Pages einen Block. Daraus ergibt sich 512 KB für einen Block.

Leere Pages können zwar direkt beschrieben werden, befinden sich jedoch Daten in den Pages müssen diese erst gelöscht werden ehe sie beschrieben werden können. Löschvorgänge können aber nur Blockweise erfolgen.

Was folgt nun daraus? In einen Block können sich nun valide aber auch gleichzeitig invalide Daten befinden. Da man nun nicht nur die invalide gewordenen Pages innerhalb des Blocks löschen kann, müssen die validen Daten in den Cache zuerst zwischengespeichert und reorganisiert werden. Erst dann kann der Block und somit die invaliden Daten gelöscht werden.

Beginnt man nun mit dem Löschen sofort nachdem Daten (Pages) invalide geworden sind (Indilinx), löst dies eine Lawine an Reorganisationsarbeit aus. Daraus folgt eine wesentlich höhere Write-Amplification, als wenn man dies kontrolliert nach Bedarf machen würde (Sandforce).
 
ich habe mal eine kleine frage

seit gestern besitze ich eine eine ADATA S599 mit 64gb (win7+treiber+programme installiert)

crystaldiskinfo zeig mir bei zustand 87% an :-[ ist das normal oder läuft da was falsch ?
 
Ich bin auf der Suche nach einer neuen SSD.
1. Kann mir jemand kurz sagen wie es bis jetzt mit der Langlebigkeit ausschaut? Seit dem "Griff in das Klo" mit dem Indlix bin ich da etwas unsicherer geworden.
2. Welchen Hersteller ist den zu bevorzugen? Ich möchte eine möglichst schnelle, auf den letzten Euro kommts nicht drauf an, wichtig ist noch guter Firmware support.
Ich dachte da an eine OCZ SSD Vertex 2 Extended Cap. 120GB, SATA-II, 2,5 Zoll. Sind die brauchbar?

Ich hoffe ihr mögt mir verzeihen, dass ich nicht unbedingt die letzten 5300 Beiträge durchlesen möchte.

Danke
 
Zuletzt bearbeitet:
@Cippoli: Zur Drosselung: So lange die Drosselung das Schreiben gewisser Daten nicht verhindert bringt sie absolut nichts. Also erst an dem Punkt an dem die Platte nicht mehr mit dem Abarbeiten der Schreibaufträge nachkommt bringt die Drosselung etwas. Angenommen der User arbeitet 8h pro Tag und schreibt 1TB Daten auf die Platte. Anfangs mit 150MB/s, nehmen wir an damit würde das Laufwerk 1 Jahr halten. Bei 150MB/s ist die SSD ca. 2 Stunden mit schreiben beschäftigt. Jetzt kommt die Drosselung und reduziert auf 50MB/s um die Lebensdauer angeblich wieder auf 3 Jahre zu erhöhen. Doch (oh Wunder), der User schreibt immer noch 1TB pro Tag auf die Platte, da bei 8h auch 50MB/s noch reichen. Jetzt ist halt die SSD 6 von den 8h mit schreiben beschäftigt. Und die Lebensdauer ist immer noch nur 1 Jahr, trotz Drosselung. Erst wenn er den Punkt erreicht wo sein Laufwerk non-stop am schreiben ist bringt eine weitere Drosselung wirklich mehr Lebensdauer.

Das mit den Blöcken und Pages ist mir soweit eigentlich alles schon klar. Aber ich würde erwarten, dass es bei einem Trim von grösseren gelöschten Files sehr viele Blöcke gibt, bei denen alle Pages ungültig werden. Wozu soll man das Löschen dieser bis zum nächsten Write aufsparen, statt sie gleich zu löschen? Direktes Löschen der komplett vollen und komplett invaliden Blöcke erhöht die Write-Amplification nicht. Würde aber wohl der Performance helfen.

@DoubleJ: Hm, dann würde mich aber mal interessieren wie genau der Einbruch von 130MB/s auf 90MB/s den einige Messen genau erklärt wird. Im Prinzip dürfte dass ja durch Füllen der Platte (und darauf folgendes Löschen) mit sehr grossen Files nicht auftreten. Da man da praktisch nur komplett volle und komplett invalide Blocks hat nach dem Trim, die direkt ereased werden können, also die SSD danach wieder fast wie neu sein müsste (von der Performance her).
 
Zuletzt bearbeitet:
ich habe mal eine kleine frage

seit gestern besitze ich eine eine ADATA S599 mit 64gb (win7+treiber+programme installiert)

crystaldiskinfo zeig mir bei zustand 87% an :-[ ist das normal oder läuft da was falsch ?
Bitte mal einen Screenshot (der alles zeigt) posten. Wenn sie neu ist (so verstehe ich dich), sollte das eigentlich nicht passieren.
Nimmst du die neueste Version von CDI? Ältere hatten iirc Interpretationsprobleme.

Nun wäre es wirklich mal interessant zu sehen, ob es nach Phase 3 (50% sequenziell Schreibleistungsverlust ausgehend von Phase 1) auch noch eine 4. Phase oder gar 5. gibt.

Freiwillige die das mal testen wollen? Palomino2000? :d
Hm ... :teufel:

mfg
 
Zuletzt bearbeitet:
Bitte mal einen Screenshot (der alles zeigt) posten. Wenn sie neu ist (so verstehe ich dich), sollte das eigentlich nicht passieren.
Nimmst du die neueste Version von CDI? Ältere hatten iirc Interpretationsprobleme.

ja die ssd ist neu...

 
Zuletzt bearbeitet:
@Cippoli: Zur Drosselung: So lange die Drosselung das Schreiben gewisser Daten nicht verhindert bringt sie absolut nichts. Also erst an dem Punkt an dem die Platte nicht mehr mit dem Abarbeiten der Schreibaufträge nachkommt bringt die Drosselung etwas. Angenommen der User arbeitet 8h pro Tag und schreibt 1TB Daten auf die Platte. Anfangs mit 150MB/s, nehmen wir an damit würde das Laufwerk 1 Jahr halten. Bei 150MB/s ist die SSD ca. 2 Stunden mit schreiben beschäftigt. Jetzt kommt die Drosselung und reduziert auf 50MB/s um die Lebensdauer angeblich wieder auf 3 Jahre zu erhöhen. Doch (oh Wunder), der User schreibt immer noch 1TB pro Tag auf die Platte, da bei 8h auch 50MB/s noch reichen. Jetzt ist halt die SSD 6 von den 8h mit schreiben beschäftigt. Und die Lebensdauer ist immer noch nur 1 Jahr, trotz Drosselung. Erst wenn er den Punkt erreicht wo sein Laufwerk non-stop am schreiben ist bringt eine weitere Drosselung wirklich mehr Lebensdauer.

So kann das ganze auch nicht funktionieren. Wenn ich an einen Tag 1TB mit 150MB/s schreibe, dann werde ich es die kommenden Tage auch können, da hier noch gar keine Drosselung greift. Du hast also am nächsten Tag dein Kontingent von 1TB bei 150MB/s wieder frei.

Nehmen wir an die Drosselung greift ab 1TB/Tag.

Schreibst du nun an einen Tag 2TB, so wird das erste TB mit vollen 150MB/s geschrieben. Nun kommt die Drosselung - aber nur für das restliche TB! Nehmen wir an du schreibst das restliche zweite TB mit 50MB/s. Insgesamt hast du deine 2TB dann mit 100MB/s geschrieben.

Am darauffolgenden Tag wirst deine 1TB aber nicht mehr mit 150MB/s schreiben können, ehe du nicht einen Tag Pause machst oder an dem Tag weniger als 1TB schreibst, da du am vorherigen Tag dein Kontingent überschritten hast.

Hälst du dich an diese Pause oder an die Schreibminderung, so kannst du am übernächsten Tag wieder mit vollen 150MB/s deine 1TB schreiben.

Ich glaube dennoch nicht das dieses Beispiel zu 100% dem entspricht was Sandforce in den Controller implementiert.

mmoeller schrieb:
Das mit den Blöcken und Pages ist mir soweit eigentlich alles schon klar. Aber ich würde erwarten, dass es bei einem Trim von grösseren gelöschten Files sehr viele Blöcke gibt, bei denen alle Pages ungültig werden. Wozu soll man das Löschen dieser bis zum nächsten Write aufsparen, statt sie gleich zu löschen? Direktes Löschen der komplett vollen und komplett invaliden Blöcke erhöht die Write-Amplification nicht. Würde aber wohl der Performance helfen.

Ich wiederhole - das ist Indilinx denken! Sandforce SSDs arbeiten anders.


Trau dich... :shot:
 
Zuletzt bearbeitet:
Kann mir einer auf die schnelle den Unterschied zw. den OCZ SSDs mit Sandforce Controller sagen? Also den Vertex/Agility/Onyx 2 SSDs...ich blick da nicht durch...
 
So weit ich weiß sind die Agility 2er auf 10.000 IOPS begrenzt und die Vertex 2er auf 50.000.

Bin mir aber wirklich nicht mehr sicher, da muss sich nochmal einer von den Profis hier zu äußern ;)

Gruß
 
Zuletzt bearbeitet:
So weit ich weiß sind die Agilitys auf 10.000 IOPS begrenzt und die Vertex auf 50.000.
Bitte Agility 2 und Vertex 2 (und Onyx 2), die Einser-Versionen hatten noch Indilinx-Controller. Es gibt aber wohl auch die High-Performance-Firmware für beide Modelle. Unterschiede gibt es auch in der zur Verfügug stehenden Kapazität, während der berbaute Flashspeicher gleich ist (bei den entsprechenden Modellen).

Was da jetzt genau die empfehlenswerteste variante ist? Keine Ahnung ... vermutlich solltest du nach Preis entscheiden.

mfg
 
Weiß ich, da er aber in seinem Post von den 2ern geredet hatte hielt ich das für selbstverständlich. Ich änder' das trotzdem mal ab.
 
Ja ich habe jeweils von den 2er Varianten gesprochen

das mit den IOPS habe ich auch bereits auf der Homepage gefunden, IOPS sind was? I/O pro sek?
 
sOT, aber vielleicht doch ganz interessant.

Komprimierbarkeit von Benchmark-Daten


  • ATTO-Testdaten, 256 MiB
    • NTFS-Kompression: 4kiB
    • 7z: 38 kiB
    • RAR: 129 kiB
    • Die Testdatei wird während des Benchmarks von der NTFS-Kompression auf 24,3 MiB gepackt
  • AS SSD normale Testdaten, 1 GiB
    • NTFS-Kompression: 124 MiB
    • 7z: 231 kiB
    • RAR: 631 kiB
    • Die Testdatei wird während des Benchmarks von der NTFS-Kompression auf etwa 710 MiB gepackt
  • AS SSD Kompression Testdaten, 1 GiB
    • NTFS-Kompression: 520 MiB
    • 7z: 527 MiB
    • RAR 512 MiB
    • Bemerkenswert ist, daß das eigentlich beste 7z am schlechtesten abschneidet. Eine sich stetig erhöhende Kompression vom Anfang zum Ende hin ließ sich erwartungsgemäß beobachten. Mehr dazu weiter unten.
  • CDM Testdaten, 1000 MiB
    • NTFS-Kompression: 1000 MiB (d. h. garnicht komprimiert)
    • 7z: 717 kiB
    • RAR: 831 MiB, (Anmerkung: RAR "beste" schafft auch 1419 kiB)
  • Zum Vergleich: Mein Windows 7-Ordner (14 GiB)
    • NTFS-Kompression 8 GiB = 65%
    • 7z: 2 GiB = 15% (in ~120 Minuten auf einem i3 @ 3,6 GHz)
    • RAR: 6,2 GiB = 42% GiB (in 13 Minuten)
    • Sandforce behauptet laut AnandTech (2. Absatz), während einer Windows 7- und Office 2007-Installation statt der eigentlich angefallenen 25 GB nur 11 GB tatsächlich geschrieben zu haben, also 44%. Naja.

Kompressionseinstellungen:
  • RAR: "schnellste"
  • 7z: Archivformat 7z, Kompressionstärke Ultra, Kompressionsverfahren LZMA, Wörterbuchgröße 512 MB, Wortgröße 273
  • andere (siehe unten): jeweils das maximal mögliche

Da dort in den ersten 16 MiB (laut nsa666 bzw. der x-Achsenbeschriftung) keine Kompression möglich ist, ist das auch der eigentlich interessante Teil für diesen Test. Keines der Programme konnte auch nur ein Bit einsparen, damit dürfte das ganze wirklich unkomprimierbar sein. :-)
Analog für die mittleren 16 MiB, diese soll zu 50% komprimierbar sein und sind es in allen Programmen auch (mit einigen wenigen kiB Abweichung).
Weitere getestete Packer:
paq8px_v69, fp8_v1, nanozip-0.08a.win32, PPMX

Mein Fazit: Sandforce schummelt da vermutlich schon ein wenig. So gut (und einfach), wie auch die AS SSD Benchmark- und CDM-Daten komprimierbar sind, sollten diese Benchmarks wie ATTO auch von der Kompression profitieren. Da sie es nicht tun, fällt es mir schwer zu glauben, daß ich bei normaler Nutzung etwas von der Kompression habe.

Hinweise:
Die Live-Werte der NTFS-Kompression sind mit Vorsicht zu genießen.
Die Daten des AS SSD-Benchmark-Kopiertest habe ich nicht rausbekommen.


mfg
 
ich habe mal eine kleine frage

seit gestern besitze ich eine eine ADATA S599 mit 64gb (win7+treiber+programme installiert)

crystaldiskinfo zeig mir bei zustand 87% an :-[ ist das normal oder läuft da was falsch ?

vermutlich werden die werte immernoch nicht korrekt ausgelesen.
nutzt du die neuste version des programms?



Ich bin auf der Suche nach einer neuen SSD.
1. Kann mir jemand kurz sagen wie es bis jetzt mit der Langlebigkeit ausschaut? Seit dem "Griff in das Klo" mit dem Indlix bin ich da etwas unsicherer geworden.
2. Welchen Hersteller ist den zu bevorzugen? Ich möchte eine möglichst schnelle, auf den letzten Euro kommts nicht drauf an, wichtig ist noch guter Firmware support.
Ich dachte da an eine OCZ SSD Vertex 2 Extended Cap. 120GB, SATA-II, 2,5 Zoll. Sind die brauchbar?

Ich hoffe ihr mögt mir verzeihen, dass ich nicht unbedingt die letzten 5300 Beiträge durchlesen möchte.

Danke

sorry, dein post ist etwas in der technik diskussion hier untergegangen.
er wäre in der kaufberatung meiner meinung nach auch besser aufgehoben gewesen... naja, jetzt eben doch hier...

1. bis jetzt gibt es was die haltbarkeit angeht noch keine negativen berichte über die sf basierten ssds. allerdings sind diese auch noch nicht so lange verfügbar wie die indilinx ssds.
es ist aber davon auszugehen, dass es da durchaus zu deutlich weniger problemen kommen wird. der controller ist so ausgelegt, dass er den flash möglichst schont und dazu sogar die leistung drosselt. die ssds sind also eher dafür konzipiert lange zu halten.

2. der hersteller ist eher zweitrangig. die unterschiede sind marginal und firmware updates kommen eigentlich überall zeitnah raus.
die ocz kannst du bedenkenlos kaufen. das dortige forum scheint auch gut besucht und bei problemen um hilfe bemüht.
interessant ist auch diese: Extrememory XLR8 Plus SSD 120GB
firma mit sitz in deutschland und ein mitarbeiter ist auch oft hier im forum unterwegs.
 
Gibt es irgendwo Benchmarks (ATTO, AS SSD, ...) von NTFS Compressed vs. NTFS Normal auf Sandforce und Marvell Controllern?
 
Das ist ja gerade das interessante daran. Unter Umständen ist eine komprimierte NTFS Partition auf einem Marvell Controller schneller (und braucht weniger NAND Cycles) als eine normale NTFS Partition. Natürlich auf Kosten von zusätzlicher CPU Load. Wieviel (und ob) man etwas dabei gewinnt, und viel CPU Load man zusätzlich bekommt würde mich interessieren.
 
Mein Fazit: Sandforce schummelt da vermutlich schon ein wenig. So gut (und einfach), wie auch die AS SSD Benchmark- und CDM-Daten komprimierbar sind, sollten diese Benchmarks wie ATTO auch von der Kompression profitieren. Da sie es nicht tun, fällt es mir schwer zu glauben, daß ich bei normaler Nutzung etwas von der Kompression habe.

Man darf nicht ausser Acht lassen, dass der SF-Controller die Daten On-The-Fly komprimieren muss, d.h. die Kompression muss mit der Leistung der Hardware ausbalanciert sein.

Intel i3 @ 3,6 Ghz gegen SF-Controller - ein unfairer Vergleich, wo es nur einen Sieger geben kann.
 
Das ist ja gerade das interessante daran. Unter Umständen ist eine komprimierte NTFS Partition auf einem Marvell Controller schneller (und braucht weniger NAND Cycles) als eine normale NTFS Partition. Natürlich auf Kosten von zusätzlicher CPU Load. Wieviel (und ob) man etwas dabei gewinnt, und viel CPU Load man zusätzlich bekommt würde mich interessieren.
In fast allen Fällen (ausgenommen Spezialanwendungen) wird man durch die Kompression durch die CPU mehr Leistung verlieren als man durch etwas schnellere Transferraten gewinnt, denn die Transferraten sind bei keiner aktuellen SSD das Problem - eher das restliche System, also z.B. die CPU.
 
sorry, dein post ist etwas in der technik diskussion hier untergegangen.
er wäre in der kaufberatung meiner meinung nach auch besser aufgehoben gewesen... naja, jetzt eben doch hier...

Hab ich mir zuerst auch überlegt, da es sich jedoch speziell um den Sandforce Controller handelt, dachte ich ich wäre hier besser aufgehoben.

1. bis jetzt gibt es was die haltbarkeit angeht noch keine negativen berichte über die sf basierten ssds. allerdings sind diese auch noch nicht so lange verfügbar wie die indilinx ssds.
es ist aber davon auszugehen, dass es da durchaus zu deutlich weniger problemen kommen wird. der controller ist so ausgelegt, dass er den flash möglichst schont und dazu sogar die leistung drosselt. die ssds sind also eher dafür konzipiert lange zu halten.

2. der hersteller ist eher zweitrangig. die unterschiede sind marginal und firmware updates kommen eigentlich überall zeitnah raus.
die ocz kannst du bedenkenlos kaufen. das dortige forum scheint auch gut besucht und bei problemen um hilfe bemüht.
interessant ist auch diese: Extrememory XLR8 Plus SSD 120GB
firma mit sitz in deutschland und ein mitarbeiter ist auch oft hier im forum unterwegs.

Danke für die Info! Die Extrememory wäre ein interessantes Produkt da es eine deutsche Firma ist, leider bekomme ich die in der Schweiz nicht.
Ich werde mich für die OCZ entscheiden, klingt sympatisch:d
 
ok, wie gesagt, die ssds nehmen sich ohnehin fast nichts.
da kann man jedes produkt kaufen.
 
In fast allen Fällen (ausgenommen Spezialanwendungen) wird man durch die Kompression durch die CPU mehr Leistung verlieren als man durch etwas schnellere Transferraten gewinnt, denn die Transferraten sind bei keiner aktuellen SSD das Problem - eher das restliche System, also z.B. die CPU.
Nein. Zumindest auf meinem i3 zwackt sich die NTFS-.Kompression nicht wirklich viel ab, /edit: stimmt wohl nciht ganz, die CPU-Zeit scheint einfach nur dem schribenden Programm zugerechnet zu werden /editend
... agiert eher im Hintergrund und nachträglich, d.h. sie spart Platz, aber weniger Bandbreite.

Tests mit ATTO/AS SSD/CDM/Windows-Ordner-Kopie auf mit/ohne NTFS-Kompression laufen ...

mfg
 
Zuletzt bearbeitet:
Wie soll sie denn "nachträglich" arbeiten? Wenn Daten gebraucht werden, müssen sie ja wohl dekomprimiert werden, bevor sie verarbeitet werden können.
 
hier gibts testfiles (510 verschiedene files = 310MB)
Maximum Compression (lossless data compression software)
vielleicht kann mal jemand gucken wie schnell die auf sandforce geschrieben/gelesen werden im vergleich zu unkomprimierbaren files. Dann kann man die sandforce komprimierung besser einordnen.

es kann auch sein, daß sandforce nach dem schreiben im hintergrund noch nach duplikaten zum löschen sucht. das kompressionsverhältnis kann man dann nicht ermitteln.

auf einem q6600 erreicht xp-ntfs kompression 40.8MB/s lesen (Platz 29), 55.9MB/s schreiben (Platz 13)

die i-cpus sind aber viel besser. lzo erreicht auf einem q6600 88.7MB/s lesen, auf einem i7 920 sogar sagenhafte 434MB/s lesen, 169 schreiben
Fast compression library for C, C# and Java
 
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