SSD UltraDrive Supertalent / OCZ Vertex SSD / Indilinx Barefoot Controller [Part 6|2]

Status
Für weitere Antworten geschlossen.
Oha was hast du gemacht :confused:

HD Tune sieht ja ziemlich mies aus


habe ein Notebook... d.h. ich kann am Controller erstmal nichts ändern...^^ die anderen Benches wie Atto oder Crystal sehen aber gut aus... verstehe nicht warum hd tune so mies is...
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
bdbcp3rm5tfi4c2ba.png


so, damit bleib ich erstmal beim ich10r
 
so, wollte gerade meine Benchmark Session hinter mich bringen.. dabei ist mir aufgefallen das es mit der Firmware nahezu unmöglich ist, aussagekräftige Benchmarks zu machen.. ganz extrem bei Benchmarks wie ATTO oder AS SSD Benchmark, ich kann hier bei ATTO einen durchlauf machen, und anschließend sofort noch einen und bekomme dann überall gute 40MB/s weniger raus, egal ob READ oder WRITE.. direkt anschließend AS SSD Benchmark, erster Bench war ne Katastrophe mit unter 90MB/s WRITE SEQ., direkt darauf noch ein Durchlauf und siehe da, plötzlich 134MB/s WRITE SEQ.

das ganze Benchen bringt also nicht wirklich viel, fakt ist die FW scheint die Platte aufzuräumen und wenn sie damit fertig ist hat man TOP Werte, während dieser Aufräumphase dagegen furchtbar.. allerdings merkt man davon in Anwendungen recht wenig, außer "GC" arbeitet nicht dann wird's spürbar schneller.. also in meinen Augen ne TOP FW die quasi selbständig aufräumt, und das mit Erfolg!

wer sich dabei während dessen über die Leistung beschwert, bitte.. aber ne normale HDD ist während dem defragmentieren auch zu absolut garnichts zu gebrauchen!
 
So, hab jetzt dank der Unterstützung von ******* auch wieder auf die 1571 zurückgeflashed. Performance ist wieder wie gewohnt.
Fazit: Die neue 1819 Final ist bei mir nicht zu gebrauchen --> inakzeptable Performance !
Werd jetzt erstmal abwarten wie sich das Ganze noch entwickelt. Ich kann nur Hoffen das Supertalent bzw. Indilinx das noch in den Griff bekommt ( auch für nicht Win7 Benutzer ).

der_Kief
 
Zuletzt bearbeitet:
also in meinen Augen ne TOP FW die quasi selbständig aufräumt, und das mit Erfolg!

Den Aspekt will ich nochmal unterstreichen: Wenn hier CDM u. AS SSD gigabyte-weise Daten auf die SSD schreiben. Und bei den 4kb Tests sicher viele leere Eraseblocks mit 4kb bekritzeln u. die halb-vollgemüllten Seiten dann auf der SSD rumliegen, was soll das GC denn anderes machen als aufräumen?

Räumt es auf, so kommt es natürlich jedem weiterem Benchmark oder noch dem laufenden in die Quere.

Ja, vielleicht hat es schon einen Timer, der das GC nur noch einer gewissen Ruhephase anspringen lässt. Aber auch da ist ja nicht auszuschließen, dass es irgendwem in die Quere kommt.

Vielleicht findet mal einer mit Stethoskop heraus wann jeweils GC anspringt. Man müsste ja die SSD leise zirpen hören.

Fazit: Die neue 1819 Final ist bei mir nicht zu gebrauchen --> inakzeptable Performance !
Da hier ja schon in Tabellenform betroffene User gesammelt werden. Was soll denn der Maßstab für "inakzeptable Performance" sein? Ein Wert in einem Benchmark? Oder Real-life?
 
Zuletzt bearbeitet:
Wenn ich die neue Firmware auf die Ultradrive spiele und jetzt Windows 7 Prof. installiert habe hält sich die SSD von selber fit, oder? Also Trim...
 
Gut eingestellter GC sollte eigentlich warten bis es keine Aktivität mehr gibt...
 
Nochmal ne kleine Frage, falls jemand das Programm TrueCrypt nutzt.

Habe jedenfalls eine Systempartitionsverschlüsselung meiner Hauptplatte (SSD) gemacht und nun findet Wiper nix mehr. Gehe ich richtig in der Annahme, das durch die Verschlüsselung die SSD nicht mehr von Wiper erkannt wird, obwohl ich im Windows bin?

Auch sind die Geschwindigkeitswerte wohl um die Hälfte eingebrochen, was wohl an der on-the-fly Verschlüsselung liegen könnte, oder???

Kann jemand vielleicht was dazu sagen? (Hätte halt gerne mein System sicher, weshalb ich die Truecrypt Systempartitionsverschlüsselung nutze.
 
Truecrypt ist inherent inkompatibel mit sämtlichen Formen von TRIM u. GC. Truecrypt verschlüsselt jeden Sektor auch wenn er komplett leer ist. Dadurch sieht die SSD nur volle Sektoren. Die SSD ist also immer voll belegt mit worstcase Performance. (Vgl. "Make sure that Quick Format is disabled when encrypting a partition/device within which you intend to create a hidden volume." in klick).

Forensiker würden sogar sagen: SSD + Truecrypt ist unsicherer als HDD + Truecrypt, da die Zusatzblocks, die die SSD gegenüber ihrer nominellen Kapazität Dubletten enthält woraus sich _theoretisch_ der Schlüssel leichter rekonstruieren lässt. Ist aber für die Praxis meist irrelevant. Der Aspekt ist hier beschrieben:
http://www.truecrypt.org/docs/?s=wear-leveling
 
Zuletzt bearbeitet:
TRIM sollte eigentlich mit truecrypt gehen.. GC eher nicht.
 
Grosser FW-Vergleich: 1819 Final, 1819 Beta, 1819G


1819 Final





1819 Beta





1819G



Zudem manuell eine 4GB grosse Datei kopiert: Alle 3 FWs benötigten auf die Sekunde genau gleich lange (69s, ~59MiB/s)


System: Compaq 6910p (Notebook) mit ICH8M, Win7x32Prof
UD GX32 SAIX


Benches:
CDM: Einstellungen ersichtlich (Standard)
HDTune: Standardeinstellungen
IOMeter: Workstationpattern, nach 5m. Screenshot (8kb, 80% Read, 80% Random)
ASS: Standardeinstellungen

Von der 1819G fehlt leider ein IOMeter Screen, die Perf. lag zwischen den anderen beiden - ist verschollen :)

-------------------------------

Mit Ausnahme vom ASS und CDM praktisch identische Werte. Insgesamt hinterlässt die Final einfach einen faden Beigeschmack - irgendwas ist leicht faul dran, was mir nicht gefallen will. Wie man sieht ist laut IOMeter die Performance auch bei gleichzeitigen Lese/Schreibzugriffen praktisch identisch, ebenso die Kopiergeschwindigkeit in der Praxis (manuell nachgemessen und ASS). Wo das Problem genau liegt, weiss ich jedoch nicht bzw. konnten mir die Benches nicht wirklich sagen, da die Ergebnisse so widersprüchlich sind...
 
Zuletzt bearbeitet:
Truecrypt ist inherent inkompatibel mit sämtlichen Formen von TRIM u. GC. Truecrypt verschlüsselt jeden Sektor auch wenn er komplett leer ist. Dadurch sieht die SSD nur volle Sektoren. Die SSD ist also immer voll belegt mit worstcase Performance. (Vgl. "Make sure that Quick Format is disabled when encrypting a partition/device within which you intend to create a hidden volume." in klick).

Forensiker würden sogar sagen: SSD + Truecrypt ist unsicherer als HDD + Truecrypt, da die Zusatzblocks, die die SSD gegenüber ihrer nominellen Kapazität Dubletten enthält woraus sich _theoretisch_ der Schlüssel leichter rekonstruieren lässt. Ist aber für die Praxis meist irrelevant. Der Aspekt ist hier beschrieben:
http://www.truecrypt.org/docs/?s=wear-leveling

OK, Danke vielmals! Dann werde ich die Systemverschlüsselung wohl wieder aufheben und ohne leben müssen. Sehr Schade...
 
Guten Tag Euch,

ich hab mich nun auch entschieden die 1819 Firm draufzumachen, obwohl ich ja mit meinem M2N-SLI Deluxe Board mit nForce 570 SLi AMD Chipsatz kaum noch Hoffnung auf autotrim geschweige manuelltrim mehr habe.
GC scheint auch nichts zu bringen im Moment.
Nun hatte sofort nach Firmwareflash unfaßbar schlechte Benchwerte , gut habe dann 6GB auf UD-SSD geschrieben um eventuell autotrim auszulösen und siehe da dann waren die Werte gut, dann habe ich verschiedene dinge mit den Speichercontrolertreibern (nforce) ausprobiert und nun hab ich wieder sehr schlechte Schreibwerte. und ich denke von autotrim keine Spur.

Nun möchte ich mal probieren das ich die nForcetreiber runter schmeiße und durch andere ersetze.

Aber welche und wo bekomme ich die her?

Danke schonmal für Eure Hilfe.

Ps.:Benutze Windows 7.
 
Zuletzt bearbeitet:
@Eggcake: du hast ja win7 trim an. Die Probleme kommen erst wenn es zu wenig getrimten speicher gibt(besonders stark mit der Final).
 
Die 1819G ist wohl Nachfolger der Final und aktuell in der beta-phase.

Übrigens der GC funktioniert bei mir (nach paar stunden idle ohne TRIM nach dem vollschreiben):
 

Anhänge

  • as-ssd-bench STT_FTM64GX25H 17.10.2009 17-45-30-gc.png
    as-ssd-bench STT_FTM64GX25H 17.10.2009 17-45-30-gc.png
    11,9 KB · Aufrufe: 83
Die 1819G ist eine nicht-öffentliche Beta mit Garbage Collection und TRIM, die 1819 Beta hat keine (nur TRIM). Die Final scheint ebenfalls beides zu haben, was das Ganze noch merkwürdiger macht...
 
....Da hier ja schon in Tabellenform betroffene User gesammelt werden. Was soll denn der Maßstab für "inakzeptable Performance" sein? Ein Wert in einem Benchmark? Oder Real-life?
Zum einen natürlich die Benchmarks :d aber ich konnte auch real-life schlechtere Performance "fühlen" unter anderem die längere Bootzeit. Vorerst bleib ich bei 1571 die läuft stabil und schnell.

der_Kief
 
TRIM sollte eigentlich mit truecrypt gehen..
Widerspräche der Sicherheitspolitik von Truecrypt vehement:

. TRIM kann nur das Filesystem auslösen indem es dem Datenträger mitteilt welche Datenbereiche frei geworden sind. Beispiel Datei Löschen: MFT Eintrag wird gelöscht. TRIM löscht die Datenbereiche.

. Angenommen TRIM wird auf dem Truecrypt Volumen ausgelöst. Was sollte die TrueCrypt Verschlüsselung nun mit dieser Information über freie Blöcke anfangen? Aus Gründen, die ich bereits verlinkt habe speichert Truecrypt keine freien Datenblöcke (Sektoren - Truecrypt arbeitet 512 Byte Sektorbasiert), sonder ein Datenblock mit Inhalt 000000 wird mit dem Masterschlüssel, Hash u. Salt durch die Mangel genommen u. landet als *!"§LÖ auf dem Datenträger. Das ist ganz essentiell für TrueCrypt, dass man die freien Datenblöcke aus Sicht des Filesystems auch niemals erkennen kann (sowohl aus Sicht eines Schlüsselknackers als auch aus Sicht von Hidden Volumes). Also bleibt Truecrypt nichts anderes übrig als das TRIM zu verwerfen - was das effizienteste ist. Wenn es das TRIM durch die Encryption Mangel nähme, dann hätte dies für die SSD wegen *!"§LÖ keinen Vorteil mehr.

Der Sourcecode von Truecrypt ist öffentlich. Gerne kann obiges nicht nur anhand der Truecrypt Doku verifiziert werden, sondern auch im Sourcecode nachgelesen.

Erst wenn Arrandale/Clarkdales kommen mit AES Verschlüsselung in Hardware läuft Truecrypt ohne Performance impact (HDTune Benchmarks inside):
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3648&p=5
Sogesehen wäre mir jetzt TRIM auch nicht soooo wichtig für Truecrypt.

Die manuellen TRIM Tools werden höchstwahrscheinlich auf einem Truecrypt Volumen nicht funktionieren. Sie können es nicht umgehen.
 
Zuletzt bearbeitet:
Alle fragen bezüglich beta-fw-bekommen bitte an SSDfix.

---------- Beitrag hinzugefügt um 18:26 ---------- Vorheriger Beitrag war um 18:21 ----------

Widerspräche der Sicherheitspolitik von Truecrypt vehement:

. TRIM kann nur das Filesystem auslösen indem es dem Datenträger mitteilt welche Datenbereiche frei geworden sind. Beispiel Datei Löschen: MFT Eintrag wird gelöscht. TRIM löscht die Datenbereiche.

. Angenommen TRIM wird auf dem Truecrypt Volumen ausgelöst. Was sollte die TrueCrypt Verschlüsselung nun mit dieser Information über freie Blöcke anfangen? Aus Gründen, die ich bereits verlinkt habe speichert Truecrypt keine freien Datenblöcke (Sektoren - Truecrypt arbeitet 512 Byte Sektorbasiert), sonder ein Datenblock mit Inhalt 000000 wird mit dem Masterschlüssel, Hash u. Salt durch die Mangel genommen u. landet als *!"§LÖ auf dem Datenträger. Das ist ganz essentiell für TrueCrypt, dass man die freien Datenblöcke aus Sicht des Filesystems auch niemals erkennen kann (sowohl aus Sicht eines Schlüsselknackers als auch aus Sicht von Hidden Volumes). Also bleibt Truecrypt nichts anderes übrig als das TRIM zu verwerfen - was das effizienteste ist. Wenn es das TRIM durch die Encryption Mangel nähme, dann hätte dies für die SSD wegen *!"§LÖ keinen Vorteil mehr.

Der Sourcecode von Truecrypt ist öffentlich. Gerne kann obiges nicht nur anhand der Truecrypt Doku verifiziert werden, sondern auch im Sourcecode nachgelesen.

Erst wenn Arrandale/Clarkdales kommen mit AES Verschlüsselung in Hardware läuft Truecrypt ohne Performance impact (HDTune Benchmarks inside):
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3648&p=5
Sogesehen wäre mir jetzt TRIM auch nicht soooo wichtig für Truecrypt.

Die manuellen TRIM Tools werden höchstwahrscheinlich auf einem Truecrypt Volumen nicht funktionieren. Sie können es nicht umgehen.

Klar verschlüsselt true-crypt auch die leeren blöcke. Aber wenn das BS an diesen leeren block(BS weiss ja dass block leer!) TRIM-Befehl sendet wird der halt genullt. Das stört ja truecrypt in sofern nicht da es ja auf den block niemals zugreift(der ist ja leer). Es senkt etwas die Sicherheit da Angreifer dann feststellen kann wo leere und wo gefüllte blöcke liegen. Auch trim-tools sollten funktionieren da sie das BS-funktionen zum auslesen von freien sektoren verwenden.

Und ja die Hidden-Volumes gehen dann natürlich nicht.

P.S.: TRIM ist ein ATA-Befehl und kein einfaches 0000 schreiben. Das funktioniert unabhänig vom inhalt des Blocks.
 
Zuletzt bearbeitet:
Die 1819G ist wohl Nachfolger der Final und aktuell in der beta-phase.

Übrigens der GC funktioniert bei mir (nach paar stunden idle ohne TRIM nach dem vollschreiben):

Schau und bei mir funktioniert GC absolut nicht, selbst nach 6 stunden idl nicht aber keine sorge, auch bei den Vertex hat sich nach 6 stunden IDL nichts mehr verbessert nachdem ich mit dem freediskcleaner drüber bin, anscheinend ist GC das dann zu viel.

was mich an derm ganzen extrem wurmt ist das ich mir echt 2 wochen lang nen wolf getestet hab mit der beta und ST dann so ne kranke Final raus gebracht hat die nicht auf jeder UD gleich performt bzw dann bei benches unterschiedliches raus kommt.
Was sprach dagegen die getestete Beta zu finalen und GC etwas später nachzureichen, das hätte viel verwirrung verhindert und die testerei der betatester nicht völlig umsonst und sinnfrei sein lassen.
Ehrlichgesagt bin ich da etwas sauer auf ST.

Das se da jetzt ne FW gefinalt haben die bei manchen Modellen in benches das grauen hoch kommen lässt ist die ohrfeige die ST ein weiteres mal verdient hat.
SO bekommt man das vertrauen nie und nimmer zurück, zu recht!

Und der meinung bin ich obwohl meine UD von der schlechten performance nichtmal betroffen ist.

ST machts einem nicht leicht die Supertalent zu verteidigen, ich kann jeden verstehen der so langsam die schnautze voll hat.
 
Sorry, wegen OT - ich halt mich kurz. Will's nur kurz gerade ziehen.
Klar verschlüsselt true-crypt auch die leeren blöcke. Aber wenn das BS an diesen leeren block(BS weiss ja dass block leer!) TRIM-Befehl sendet wird der halt genullt.
Das BS weiß noch nicht mal ob das Truecrypt Laufwerk ein Container, eine Partition oder eine Festplatte ist. Deshalb kann das OS kein TRIM an den darunterliegenden Datenträger senden. Layered Architecture!
 
Tja pinki, was soll man dazu sagen? Sollten die Nutzer nicht besser ihre Interessen bündeln, statt sich gegenseitig ans Bein zu machen?

Ich habe manchmal gesagt: "Es gibt Leute, die probieren nur, statt gezielt mit Überblick zu programmieren."

Vielleicht solltet ihr in der Beta nur einen bestimmten Programmteil ausprobieren, der jetzt eventuell auch in der FW ist?

Warum sollte man überhaupt irgend eine Firma verteidigen? Wer verteidigt denn unsere Interessen?
 
Schau und bei mir funktioniert GC absolut nicht, selbst nach 6 stunden idl nicht aber keine sorge, auch bei den Vertex hat sich nach 6 stunden IDL nichts mehr verbessert nachdem ich mit dem freediskcleaner drüber bin, anscheinend ist GC das dann zu viel.

was mich an derm ganzen extrem wurmt ist das ich mir echt 2 wochen lang nen wolf getestet hab mit der beta und ST dann so ne kranke Final raus gebracht hat die nicht auf jeder UD gleich performt bzw dann bei benches unterschiedliches raus kommt.
Was sprach dagegen die getestete Beta zu finalen und GC etwas später nachzureichen, das hätte viel verwirrung verhindert und die testerei der betatester nicht völlig umsonst und sinnfrei sein lassen.
Ehrlichgesagt bin ich da etwas sauer auf ST.

Das se da jetzt ne FW gefinalt haben die bei manchen Modellen in benches das grauen hoch kommen lässt ist die ohrfeige die ST ein weiteres mal verdient hat.
SO bekommt man das vertrauen nie und nimmer zurück, zu recht!

Und der meinung bin ich obwohl meine UD von der schlechten performance nichtmal betroffen ist.

ST machts einem nicht leicht die Supertalent zu verteidigen, ich kann jeden verstehen der so langsam die schnautze voll hat.

ja so gehts mir "pinki" weiß langsam nicht mehr was ich mit der UD soll wenn ich sie nicht Warten kann!!!!:confused:

ich finde ich habe komische Werte. will mal zeigen die Werte nach Firmwareupdate zur 1819 final nach 6GB schreibaktion auf der SSD.
Die Werte sind aber schonwieder schlechter und nach dem Flash ist der wert bei Crystallinfo von 100% auf 98% Gesundheit (sozusagen) gesunken.
 

Anhänge

  • IDE Firmware 1819 2.PNG
    IDE Firmware 1819 2.PNG
    15,3 KB · Aufrufe: 66
  • IDE Firmware 1819.PNG
    IDE Firmware 1819.PNG
    20,3 KB · Aufrufe: 59
  • IDE Firm 1819.PNG
    IDE Firm 1819.PNG
    18,9 KB · Aufrufe: 61
Sorry, wegen OT - ich halt mich kurz. Will's nur kurz gerade ziehen.
Das BS weiß noch nicht mal ob das Truecrypt Laufwerk ein Container, eine Partition oder eine Festplatte ist. Deshalb kann das OS kein TRIM an den darunterliegenden Datenträger senden. Layered Architecture!

Wenn du es als containerdatei anlegst nicht. Wenn du allerdings die boot-platte verschlüsselt verhällt sich truecrypt weitgehend transparent.
 
Naja, ich hab mal die Gunst der Stunde genutzt und mein Ultradrive von 1215 auf 1571 geflasht... ;)
Ging ohne Probleme, danach noch mal schnell das erste mal Wiper drüber laufen lassen (nachdem damals die Installation von WoW so lahm war - das einzige Mal, dass ich bemerkt habe, dass das SSD laut Benchmarks schon komplett auf ~40MB/s seq. eingebrochen war. Arbeiten ging flott wie eh und je, genauso wie das Installieren von Programmen.) und alles perfekt in Ordnung.

Je weniger "Garbage collected" wird, desto länger lebt auch das SSD - TRIM spielt da zum Glück keine negative Rolle, aber merken tut man ein "eingebrochenes" SSD ja nach miener eigenen Erfahrung eh nicht - also keinen Stress machen und einfach ein bisschen warten, bis sich die Verwirrung wieder legt.
 
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