Wenn ich die 8GB für RAISE abziehe, da diese ja nur Verwaltungsdaten enthalten und niemals Nutzerdaten, dann komme ich auch 56GB für Nutzdaten. Davon sind 55 verfügbar, was dann keine 2% Over-provisioning ergibt.
Waren es vorher 4GB, so gab es 0% Over-provisioning.
Hat die Die nur halb so viel Kapazität wie ich eben unterstellt haben, so waren es vorher 62GB (2 für RAISE) und damit 3,3% Over-provisioning, jetzt wären es dann 9%. Irgendwie komme ich nicht auf gleichbleibend 7%.
Moment, wir wollen jetzt nicht alles durcheinander bringen. Ich gebe zu, es ist etwas verwirrend. Halten wir uns deshalb einfach an die
Definition von SandForce.
Over-provisioning = (Rohkapazität - Nutzkapazität) : Nutzkapazität
IDEMA Spezifikation zu den Vertex 2 Extended Modellen:
SF-SSD 60GB:
32Gbit --> (64GB - 60GB) : 60GB = 7% OP
64Gbit --> (64GB - 55GB) : 55GB = 16% OP
SF-SSD 120GB:
32Gbit --> (128GB - 120GB) : 120GB = 7% OP
64Gbit --> (128GB - 118GB) : 118GB = 8% OP
Die Unterschiede im OP liegen allein an RAISE und der höheren Speicherdichte der 64Gbit Chips. Nur daraus ergeben sich diese krummen Zahlen. Ab 180GB haben dann alle Laufwerke, egal ob 32Gbit oder 64Gbit immer 7% OP.
Holt schrieb:
Das werden sie wohl hoffentlich tun, denn auch da gab es so einige, die still und heimlich die NAND Bestückung geändert und dadurch nur noch die Hälfte der Kanäle bestückt haben.
Du scheinst da mehr zu wissen als ich. Wer hat denn da noch still und heimlich gewechselt?
Holt schrieb:
Bei dem von SF favorisierten ATTO Benchmark fällst das nicht auf, aber mit realen Daten schon.
Was sind für dich denn "reale Daten"?
Holt schrieb:
Weniger als 1.0 werden aber wohl auch SF Controller nicht hinbekommen, wenn die Daten nicht komprimierbar sind. Wenn die SSD dann noch sehr voll ist, bleibt dem Controller auch keine andere Wahl als immer wieder viele Pages zu kopieren, damit er eine Cell in der eben Pages mit unvalid Daten sind flashen und wieder Daten schreiben zu kann. Einige Controller sind da sicher agressiver und flashen Cells schon, wenn nur wenige Pages darun unvalid geworden sind um so möglichst immer volle Schreibperformance zu bieten.
Wenn es sich ausschließlich nur um unkomprimierbare Daten handelt, dann kann man sicher nicht unter 1 kommen. Der SF-Controller kann aber unter 1 kommen (auch wenn nur unter einer bestimmten Rahmenbedingung), andere Controller können das bisher nicht.
Holt schrieb:
Eben, solche Daten lassen sich normalerweise nicht mehr verlustfrei komprimieren und deshalb finde ich Aussagen wie "SF hat eine WA von 0.5 und ist damit 20mal besser als der Standart" sehr unseriös, weil dies nur auf spezielle Fälle zutrifft. Das ist so, als würde man behaupte auf deutschen Strassen gäbe es kein Tempolimit.
Ich habe es schon einmal geschrieben, aber ich tue es gerne nochmal. Das sind Angaben, die der Controller unter bestimmten Rahmenbedingungen erreichen kann. Um deiner Logik zu folgen wären die oftmals angesprochenen 1,1 für eine Intel ebenfalls als unseriös zu bewerten. Man könnte sogar soweit gehen und behaupten, dass alle Werte von jeden x-beliebigen Hersteller unseriös wären. Da wäre dann nämlich keiner besser als der andere. Ich verstehe deshalb nicht, was dich so sehr am SF-Controller stört. Das sind typische Werbeaussagen, die man von jeden Hersteller zu hören bekommt.
Holt schrieb:
Ist ja auch eine gute Idee, nur schade, dass man dies dazu (miss/ge)braucht hat um die Leistungswerte nur mit ATTO und seinen unrealistisch komprimierbaren Daten anzugeben.
AS SSD Werte sind für den SF-Controller genau so unrealistisch. Die Wahrheit liegt irgendwo zwischen AS SSD und ATTO. Der SF-Controller hat seine Stärken, wenn man ihn als Systemplatte/Programmplatte einsetzt. Mein Gefühl sagt mir, dass die meisten Leute eine SSD auch für diesen Einsatzzweck auch nutzen wollen und da hat man es ganz sicher nicht nur mit unkomprimierbaren Daten zu tun.
Ich verstehe deshalb das Problem nicht. Zeig mir doch bitte ein Nutzerprofil bei dem der SF-Controller
nur mit unkomprimierbaren Daten zu tun hat. Denkst du wirklich das wäre dann realistischer?
Einzig bei der Videobearbeitung sehe ich den SF-Controller von der Leistung her im Nachteil.
Holt schrieb:
Irgendwo hatte ich mal gelesen es wären zwei ARM Cores. Aber egal, der Kompressionstest von ASS zeigt deutlich, dass bei 50% komprimierbaren Daten die Werte keineswegs doppelt so gut sind wie bei unkomprimierbaren Daten. Wenn man sich überlegt, wie wenige RAM im Controller vorhanden sein dürfte und wie gering die Leistungsaufnahme und damit der Takt sein düfte, dann sind gewaltige Kompressionsraten da nicht zu erwarten, zumal bei der Datenrate. Hatte gerade heute eine Datei die NTFS auf ca. 50% komprimieren konnte, 7zip auf 25%.
Du verkrampfst dich viel zu sehr auf die negativen Aspekte, die eigl. keine sind. Betrachtet man es aus einer anderen Perspektive, kann dir die Kompression bei 50% einiges an Daten wegkomprimieren, somit muss weniger in den Flash geschrieben werden. Die begrenzte Haltbarkeit des Flashs wird dadurch effizienter ausgenutzt. Nochmal: Der Schwerpunkt beim SF-Controller liegt nicht auf Leistung, sondern auf Haltbarkeit.
P.S. So langsam müsste man mich für den Support hier bezahlen... 
Zum Glück hab' ich mich daran erinnert, was ich hier im Forum öfter mal als Tipp gelesen hab: Rechner ausschalten, SSD für ein paar Minuten stromlos machen und wieder anschließen. - Glücklicherweise hat das Bios die OCZ 60 GB E SSD danach wieder erkannt und es scheint nun auch alles wieder normal zu laufen. *puh* 
