Ich hatte das gar nicht geschnallt, weil oben in dem Bild "Sequential READ Speed" stand.
...Das fängt an in der Gegend von 10MB/s und bleibt zur Hälfte unter 50MB/s, Durchschnitt 57,5MB/s - abscheulich!
Das hatte wir auch schon, am 21.03.2013, vor 5 Tagen also. Mein Gott, das ist ja schon ewig her.
Vergleich den Screenshot damit, wie sich alle anderen SSDs verhalten und sag mir dann bitte, wieso sich "alle" SSDs so verhalten wie die Vertex 4.
Im Alltag werden SSDs langsamer, wenn sie recht voll sind, aber nicht in den Tests. Das ist klar das Ergebnis der Methode von OCZ um gute Schreibraten zu erzielen und das da bei 50% was passiert, sieht man sogar an der Kurve der Leserate, die im zweiten Test ab 50% geringer wird. Leider ist nicht klar, ob das Lesen vor dem Schreiben passiert ist oder danach.
Ich habe von SLC -> MLC gesprochen. Bei MLC -> TLC hast du recht.
Sorry, dann hatte ich das da falsch verstanden. Aber man sieht daran, dass die Hersteller beim Wechsel auf 16LC (also 4 Bit pro Zelle) nur noch 25% der Zellen einsparen, aber eine noch komplexere Elektronik benötigen werden (solange da nicht gewaltige Fortschritte gemacht werden) und daher somit kaum so bald damit zu rechnen sein wird.
IOMeter ist OpenSource, schau Dir den Quellcode also einfach an und dann weißt Du es vermutlich besser als alle anderen hier im Forum.
Genaue Kenntnisse des Lesers darf man nicht voraussetzen.
Bei manchen Lesern darf man wirklich nichts voraussetzen, das ist schon klar. Das sie aber wenigsten mal genauer lesen was geschrieben wird, darauf darf man doch wohl wenigsten hoffen, oder?
"...sodass das Laufwerk nach einem zweiten HDTach-Durchlauf wieder auf dem Ausgangsniveau ist" Wie kann das sein? Löscht HDTach?
Benchmarks löschen nur selten, aber es ist kein Wunder, dass die Daten nach dem seq. Beschreiben der ganzen Kapazität dann schneller wieder überschrieben werden können, denn diese sind ja danach anders im Flash angeordnet als nach dem intensiven Random Schreiben mit IOMeter. Die volle Geschwindigkeit ist es aber wohl nicht, nur begrenzt HDTach eben, so dass alle über 450MB/s halt gleich schnell aussieht (obendrein begrenzt das SATA Interface natürlich auch, was die NANDs wirklich schaffen könnten, kann man schwer sagen, wenn diese jenseits des Limits des Interfaces von etwa über 500MB/s liegen, denn Schreiben hat mehr Overhead als lesen).
Auf einer komplett vollen SSD kann keine GC der Welt irgend etwas ausrichten!
Auch das stimmt nicht und auch darüber
habe ich hier schon geschrieben. Vergiss nichts, voll kann immer nur die nutzbare Kapazität sein, nie aber die komplette NAND Kapazität und die ist immer mindestens so um kanpp 7% größer!
"und dass das SSD gerade nicht nur (seq.) mit Videos beschrieben wurde, steht doch im Artikel." Dann ist das ein Schönwettertest - reine Gefälligkeit gegenüber dem Hersteller.
Im Gegenteil, denn das sequentielle Schreiben kommt der Performance doch entgegen und selbst wenn da nun nicht und ein Programm große seq. Datenvolumen ablegt, so ist das bei weitem nicht so schlimm für die Performance wie andauernde 4k Random Write mit hoher QD auf einer schon vollen SSD, was nun wirklich den Worst-Case darstellt.
Da von einem Schönwettertest zu reden ist völlig daneben.
Mal eine Frage zu SSDs die eine 256-Bit AES-Verschlüsselung anbieten - wie muss ich mir das vorstellen, kann dann wirklich niemand außer ich auf die Daten zugreifen, wenn man das Passwort nicht kennt?
Naja, von den Backdoors mal abgesehen, kann da niemand drauf zugreifen, sofern ein User Passwort für die Platte vergeben wurde. Mit dem Masterpasswort sollte man diese zwar entschlüsseln können, aber nur unter dem Komplettverlust aller Daten, da wird dann eben ein Secure Erease gemacht oder der Schlüssel getauscht.
Kannte sowas bisher mit BIOS + HDD Passwort, aber das ist ja nur für den PC im eingebauten Zustand beim booten, oder verwechsel ich gerade etwas gewaltig?
Genau dieses HDD Passwort wird als Freigabe des Schlüssels oder zur Erzeugung des Schlüssels verwenden, je nachdem wie das implementiert ist (bei Sandforce erstes, bei den anderen dürfte es auch so sein, denn bei zweitem lassen sich ja keine Backupdoors einbauen und die US Bestimmungen verlangen diese ausdrücklich).
Vergiss nicht, man darf ja auch nicht mit einem Verschlüsselten Datenträger in die USA einreise und sich weigern das Passwort rauszugeben, dann geht man in den Knast und was passiert wohl derweil mit einem Datenträger?
Die meisten SSDs verschlüsseln den AES-Schlüssel mit dem ATA-Passwort, sodass die Geschichte schon recht sicher ist. Bei guter Implementierung steht diese Lösung einer Software-Lösung wie TrueCrypt in wenig nach.
Bei der Implementierung liegt genau der Hase im Pfeffer, die kennt man eben nicht und genau deshalb vertraue ich bei Verschlüsselung nur auf OpenSource, dann da kann jeder den Quellcode einsehen und Backdoors können gefunden werden. In Deutschland wird sowas immer noch massiv unterschätzt und deshalb ist der Schaden den die deutsche Wirtschaft durch Spionage erleidet auch so gewaltig, denn alle denken dabei nur an 007 und Kino, halten das aber in der Realität für abwegig. Dabei gibt es gerade in Deutschland eine Menge Know-How auf das viele ausländische Firmen sehr, sehr scharf sind und die Geheimdienste diesen heute vor allem der Beschaffung von genau solchen Daten (und natürlich von Wirtschaftsdaten, gerade auch den Angeboten bei internationalen Ausschreibungen).
Die Verschlüsselung arbeitet transparent und ist immer aktiv. Der AES-Schlüssel ist "irgendwo" gespeichert (am besten direkt im Controller, weil er dort kaum auszulesen ist, außer mit enormen technischen Aufwand).
S.o. besser ist eine Implementierung, bei der der Schlüssel sich aus dem Passwort ergibt, z.B. aus einem Hash über Passwort und einem zufälligen Teil der intern gespeichert wird, denn damit sind Backdoors schwerer zu realisieren als wenn der Schlüssel komplett im Controller steckt.
Wenn ein ATA-Passwort gesetzt ist, wird der AES-Schlüssel mit diesem Passwort verschlüsselt. Der richtige AES-Schlüssel wird dann nur freigegeben, wenn das korrekte ATA-Passwort eingegeben wird.
Sicher? Das Passwort kann auch einfach nur als Schlüssel zum Safe dienen, der den Verschlüsselungsschlüssel enthält.
Wenn kein/ein falsches Passwort eingegeben wird, kann man mit der SSD nichts machen. Sie wird dann gar nicht erkannt. Eventuell ist sogar Secure Erase deaktiviert, sodass man die SSD nur wegwerfen (oder zum Hersteller einschicken) kann, wenn man das Passwort vergessen hat.
Eigentlich sollte jede Platte durch das Masterpasswort zu entsperren sein, halt unter dem Totalverlust der Daten aber zur Rettung der Hardware.
Dann müsste ich extra ein Testsystem auf machen und mir einen Cobol-Compiler besorgen.
Von nichts kommt nicht und ob Cobol da die passende Sprache ist? Ich würde auf irgendwas aus der C Familien (C, C++ oder C#) setzen, dass macht die Sache leichter.
Einfach h2testw mehrmals hintereinander (und parallel) reicht schon.
h2testw ist kein Benchmark sondern dazu gedacht die Datenintegrität zu prüfen, die Anzeige der Datentransferraten ist nur ein Nebenprodukt und nicht sehr genau.
