[Sammelthread] SSD: OCZ Core Serie OCZSSD2-1C[32/64/128]G

wichtiges feedback:

CERES schrieb:
nicht alle OCZ sind ein Fall für RMA.
Nach Deaktivierung des Schreibcache habe ich auch keine Hänger mehr bei Schreibzugriffen.

@z1erer
Zugriffszeiten sind auf jeden Fall ausgezeichnet, auch ohne Messungen (Xbench).
Die Gesamtleistung war unter OS X wie gesagt sehr angenehm, unter Vista 32 bit Ultimate SP1 (Bootcamp) hatte ich fast identische Ergebnisse wie auf dem Win-tel Notebook mit XP.

Gruß
Ceres
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
ich persönlich glaube nicht dass sie sich "im Umrechnungsfaktor" GiB - GB verstecken, was hier schon vermutet wurde.

Die Frage ist schwierig zu beantworten: Samsung gibt an http://www.samsung.com/global/business/semiconductor/products/flash/ssd/pdf/25_datasheet.pdf
Dabei ist eigentlich nur der Wert User Adressable Sektors wichtig.
Wenn ein Sektor laut Datenblatt 512 Byte hat und nicht Bit,
dann haben wir genau 64023257088 Bytes, was den 64 GB entspricht und nicht einem Wert von 64 GiB (sondern 59,6 GiB).
Der User hat wieder laut Datenblatt insgesamt also 64 GB zur Verfügung. Samsung spricht nicht von Ersatzzellen. Diese können unter diesem Wert Fallen oder auch nicht. Das Betriebssystem sollte neben den üblichen Formatierungsverlusten tatsächlich 64 GB zur Verfügung haben, was die meisten Partitionstools auch exakt so anzeigen sollten.
Konkret: Samsung könnte die volle Kapazität adressieren und keine Ersatzzellen anbieten. Andere Hersteller mit den gleichen Chips könnten weniger Zellen direkt adressieren, dafür aber Ersatzzellen anbieten. Warum haben die Supertalent nur 60 GB die OCZ gar nur 56Gb?
Die Erklärung dürfte nicht in der Umrechnung liegen:
Natürlich können wir hier einfach einem Hoax seitens Samsung aufsitzen, indem Samsung entweder in der Sektorgröße oder der Sektorenanzahl gelogen hat. Beide Werte scheinen aber plausibel.

Letzten Endes ist es uninteressant wie die Kapazität einer Flashzelle in GiB ausfällt, da einzig die Anzahl der adressierbaren Sektoren zählt, welche in der Firmware abgelegt ist. Theoretisch können in einer SSD Tausende an unbenutzten, vielleicht sogar defekten Zellen vorhanden sein, die von Samsung deaktiviert worden sind. Ähnlich einer 1-Platter HDD mit einem Lesekopf statt zweien. Da liegt die Hälfte der Kapazität brach.
http://www.ocztechnology.com/ssd/OCZ_Core_Series_SSD_SPEC.pdf
Das Datenblatt gibt nichts her, dass Rückschlüsse zuläßt. Die wichtigen Parameter (Anzahl der Sektoren, Bytegröße per Sektor) wurden nicht genannt.

Meine Vermutung geht dahin, dass der Speicherverlust neben der Ersatzellerklärung ziemlich simpel zu deuten ist.
OCZ kauft billige Chips von Samsung ein. Was macht diese Chips so billig, außer dass diese MLC Varianten sind? Diese Chips sind Abfallprodukte oder B-Ware mit Mängeln. Wie es in der Siliziumindustrie üblich ist, wird Abfall nicht gerne weggeschmissen, sondern was macht man? Man deaktiviert einen Teil der Chips z.B. per Lasercut.
Der Unterschied zwischen den Supertalent und den Core ist eindeutig die Chipbezeichnung, der Controller ist identisch. Hat OCZ die billigeren Chips aufgekauft, die mehr Mängel haben als die neuen Supertalent?
Ich weiß es nicht; aber zumindest ein Ansatz, um die Unterschiede der weitesgehend baugleichen SSDs erklären zu können.
OCZ könnte also
A) mit den 64 GB bewusst lügen.
B) beschönigen, da die Mängel-Chips unterschiedliche Kapazitäten haben und man den theoretischen Maximalwert der SSD angibt, der vielleicht sogar von einigen Exemplaren erreicht wird.
C) mehr Ersatzzellen aufkosten der nutzbaren Gesamtkapazität anbieten.
D) irgendeine andere Form von marketingtechnischen Möglichkeiten angewendet haben (z.b. Umrechnungs-, Rundungsfehler Byte zu Bit)

und E) die relevanten Daten uns deswegen vorenthalten.
 
Zuletzt bearbeitet:
ok danke ...

es hat mich einfach technisch interessiert ... der von dir geposteten Youtube-videoserie zufolge sind Consumer-Flashchips definitiv aus den "minderwertigen" Bereichen auf dem jeweiligen Wafer.
Das was nach qualitativ Industry & Military-grade eben übrig bleibt. Aber eben dafür preiswert.

Auch mMn dürfte die Erklärung nicht in der Umrechnung, in Rundungsfehlern byte-bit o.ä. liegen.

Aus den Bildern vom Innenleben diverser SSDs schließe ich (da eben offensichtlich keine "zusätzliche Kapazität" an Chips aufgelötet ist), dass eventuelle Ersatzzellen/Ersatzblöcke in den einzelnen Chips liegen. Der Controller / die Firmware kümmert sich um die Adressierung bzw. um das Ausgrenzen gestorbener Zellen.

Hoffen wir auf qualitative Verbesserungen in der NAND-Flash-Produktion. So dass bessere Flash-Chips den Consumermarkt erreichen.

---------------
guru3d review, vs 3 HDDs ... und OCZ SSD Config und Setup Guide
 
Zuletzt bearbeitet:
Also wenn ich mir die Testergebnisse und Erfahrungsberichte aus dem Guru3D Test der OCZ Core 64GB anschaue, ist das Ergebnis ja eigentlich recht positiv bis auf wenige Schwachpunkte...

Was mir allerdings nie gefällt, daß nicht auch mal aktuellere Modelle einer HDD mit einbezogen werden z. B. Samsung F1 etc...
 
Ich werde dann mal warten!

Nachdem mein Händler den Liefertermin für das 128G SSD nun zum dritten mal verschoben hat und die Beiträge auf Controllerprobleme hindeuten, habe ich als Linux/ICH8M/AHCI Nutzer jetzt erst mal die Bestellung für das 128G SSD aufgehoben.

Sollte die Preis/Leistungsentwicklung so weitergehen und die Marketingzahlen (Geschwindigkeit/Zuverlässigkeit) nach einem Firmwareupdate des SSD wirklich geliefert werden, werde ich gerne ein paar SSD kaufen. Im Augenblick wird mir das Thema zu heiss. Ach ja, eine venünftige SMART Implementierung würde auch nichts schaden. Hat mal jemand ausprobiert, ob das SSD SMART Infos rausgibt?

Mein jetziges Bild: Der J-Micron Controller scheint Probleme damit zu haben, dass Daten im Cache sind, wenn die Spannung weggenommen wird. Ausserdem ist das Wearleveling wohl etwas ungünstig und wenig fehlertolerant implementiert (soll heissen: Ich kann das besser und habe übrigens ein Flash-Metafilesystem '98 auch für eine hochverfügbares System entwickelt, welches bis heute sehr stabil funktioniert. Der Algorithmus arbeitet auf dem Flash transaktionsbasiert und kann zu jedem Zeitpunkt einen konsistenten Zustand herstellen. Der Einbau eines Caches zur Performancesteigerung wäre Möglich, ohne die Datenintegrität zu verletzen. Overhead sind 5% der Flashkapazität bei 512Byte Blockgrösse und 64K Sektoren - dieser Layer lässt sich mit wenigen Parametern auf die genutzten Flashbausteine anpassen. Sollte ich wieder erwarten den JM ARM Code / die Chipset Dokumentation bekommen, werde ich mir das gerne mal anschauen; die Entwicklungsumgebung ist vorhanden) :d
 
Stellt man die Windowscluster zu klein ein, dann hat man genau die gleiche Auswirkung und dazu meist deutlich mehr Speicherverlust als bei einer zu großen Einstellung.
Sollte die OCZ Aussage stimmen, dass die SSDs mit Clustern von 4 096 Byte arbeitet, dann sollte man dies als optimale Windowsclustergröße auch wählen.


Wenn man die Clustergröße unter Windows größer als die wirkliche Clustergröße der SSD wählt, belastet man die Flashzellen um so mehr, da SSD-intern mindestens 2 Cluster bearbeitet werden müssen.

Das hängt von der Controller Implementation ab, aber ich geb dir recht, ist ziemlich sicher so.

Cluster ist die atomare Filesystem Einheit für's OS. Sprich, wenn was gelesen oder geschrieben wird, dann wird immer ein Cluster angefordert oder gespeichert. Hat man ne Cluster-SIze von 4KB und n 10Byte File fordert das OS den 4KB Cluster an.

Theoretisch könnte der Controller, wenn er aufgefordert wird 8KB zu schreiben, zuerst diese 8KB lesen und überprüfen ob der INhalt der Zellen anders ist als der neue sein soll, und die Zelle nur beschreiben, falls der Inhalt ändern soll.
Wenn ich es mir recht überlege sollte er das eigentlich sogar tun. Ist ja nicht besonder schwer zu implementieren, die Adressleitungen muss man eh entsprechend setzen etc. - sollte also nicht all zu lange dauern (-vermindert aber nichts desto trotz die Schreibleistung, erhöht dafür die Lebensdauer).

der @OCZ Core verbaute Micron SSD Controller unterstützt 2/4KB SSD Zellgrössen. Das ist dann die atomare Flash-Speicher Einheit. D.h. Anzahl Adressen * grösse atomare Einheit = Speicherplatz.
Wie schon angetönt, ist es also nicht klar, welche Zell-Grössen bei den Disks verbaut werden.
MEINE Vermutung ist, dass nur die 128GB Disks die 8x16GB Konfiguration haben, die 64GB hat dann 8*8GB (mit vermutlich halber Zellgrösse und gleicher Adress(leitungs)zahl), und die 32GB hat dann 8*4 oder 4*8.

Auf der Micron SSD Präsentation stand aber auch was von Multi-Channel Controllern. D.h. Controller, welche gleichzeitige auf / von mehrere Flash-Chips schreiben / lesen können.
oder anders gesagt: Mit welchen der Controller ein AID0 machen kann.
Ergo wir nehmen 16KB Cluster und erhalten so eine atomare Einheit à 16KB.
Der SSD Controller liest und schreibt dann jeweils 4 Zellen à 4KB, d.h. à la AID0 mit 4 Channels.

Multichannel macht man, damit man die Bandbreite einfach in die Höhe treiben kann, während die Flash Chips nicht viel schneller werden müssen. Man gewinnt damit eben Bandbreite und die Latenzzeit bleibt gleich (eben, wie AID0 und wie Dual-Channel Ram - wobei AMDs neueste CPU Generation ja nicht mehr Dual Channel sondern 2x Cores mit dediziertem Channel sind).

Ich hätte mir von höherer CLuster-Size also u.U. eine bessere Performance erhofft. Aber wenn ich mir es recht überlege, spielt es dem Controller wohl keine Rolle ober eine 16KB Anforderung oder 4x4KB Anforderung kriegt (vermutlich kriegt er sie sowieso immer als 4x4KB Anforderung - durch die Abstraktion des Filesystem / Treiber Layers).
Ich gehe aber schon davon aus, dass der OCZ Core Controller Multi-Channel ist, sonst dürften die Transferraten tiefer liegen...
 
der OCZ Core Controller (JFM602) ist definitiv ein Multi-Channel Controller ... genauer ein 8-Channel ... siehe hier, Seite 12. deine Vermutung diesbezüglich ist also richtig. der Nachfolger hat dann DRAM Cache und ist wieder ein 8-Channel.
 
Nochmals zur optimalen Clustersize und warum ich Multichannelbetrieb in dem Punkt nicht erwähnenswert finde.
http://www.ocztechnologyforum.com/staff/ryderocz/ssd/ssd_config.pdf

Nochmals der alte Auszug aus dem Link, auf den unsere Daten basieren, zuzüglich des Wissens um den JM 602 :
SSDs use a completely different address system, which is based on “chips,” “planes,” “blocks,” and “pages.” Each page contains 4 Kbytes of data, however, because of the parallelism at the back end of the controller, every access includes simultaneous opening of 16 pages for a total accessible data contingent of 64 Kbytes. Each block contains 128 pages and the number of blocks per chip defines the total density of the chip.

Was wissen wir: SSDs emulieren HDDs. Es existiert in der Firmware immernoch eine Sektorgröße und entsprechende Addressierungsbereiche. Bisher gehen wir bei den Cores von einer Sektorgröße von 4096 bytes aus. Der Controller öffnet pro Chip immer 2 Pages, insgesamt 16 pages. Ein "Erase Block" siehe Zitat müßte 524kBytes groß sein. Weder sind ein MFT (http://managedflash.com/index.htm) noch LogFS oder ähnliche System auf der SSD zu finden.

Problem 1 : Der OCZ Link ist unspezifisch, Daten könnten nur auf eine andere Baureihe zutreffen. Der JM 602 könnte auch 2048 Bytes adressieren (aber unwahrscheinlich).
Problem 2 - HDD Emulation: Gleichzeitig können bestenfalls 64kB von der SSD gelesen werden, aber nur wenn die Daten alle im Leserahmen (16 pages) liegen. Diese 16 Pages sind immer die selben und können nicht dynamisch ausgetauscht werden. Gehen wir von Random Read aus sind es meist 4k bzw. eine Page, die effektiv genutzt werden kann. Man erhöht mit einem Multichannelsytem also primär nur die sequentiellen Lesewerte. Bei sequentiellem Betrieb spielt die Clustergröße des Dateisystems aber auch nur eine untergeordnete Rolle, da die Daten auf einer SSD gleichgültig welcher Clustergröße hintereinander in einem Block gefunden werden. Für das Schreiben wären theoretisch riesige 524kB Cluster optimal. Da braucht man dann wirklich schon Controllerkarten mit Cache. Ansonsten wird man das System mit größeren Clustern jenseits der 4k im Random Read möglicherweise ausbremsen, im Random Write ist dies ziemlich gleichgültig, da die Eraseblockgröße sowieso nicht erreicht wird.
Zugegebenermaßen kann man beim 8 fach Multichannel statistisch hier das ein oder andere Mb/s auch in den Random Werten noch herausholen. Generell sollte man die Clustersize entweder der Sektorgröße/Pagegröße anpassen oder wie auch bei einer normalen HDD, den Mittelwert der Dateigröße sämtlicher Dateien anpeilen.
 
Vielen dank an ScoutX und BLJ (und diejenigen die ich jetzt vergaß). Eure Posts sind großartig :bigok:
 
Yep, spot on für diese Beiträge, die nicht erst seit gestern eine derart hohe Qualität aufweisen.
 
jo absolut klasse ! nur allzuviel verstehe ich bald nicht mehr^^ weiß nur eins ich kauf mir keine(leider :( ) aber dafür hab ich jetzt eine velociraptor 300gig gekauft :fresse: ist die nicht (fast)genau so schnell wie ne ocz ssd?
 
Wenn nicht Random gelesen oder geschrieben wird (was zu 99% der Fall ist), dann ja :-))))
 
Wenn nicht Random gelesen oder geschrieben wird (was zu 99% der Fall ist), dann ja :-))))

ach nö jetzt :( man ist doch scheisse wenn man kein plan von der sache hat^^ hab ein test gesehen das stand auch so ca.125-135mb/s mit der velo.rapt.also schnell ist sie aber nur bei sachen wo eh kaum benutzt wird richtig?(aber es ist doch immo die schnellste hdd die es gibt oder)
 
Das ist der Grund warum die SSDs so "rasend" schnell sind.
Wenn Du 1000 winzige Dateien laden musst, dann wartest Du bei einer Festplatte mit 7ms Zugriffszeit 7 Sekunden nur auf die Positionierung der S/L-Köpfe. Egal wie viel Datentransferrate die Platte nun wirklich hat.
Diese 7 Sekunden gibt es bei den SSds nicht. (Jedenfalls ist diese Zeit dort nicht relevant).

Und jetzt schau Dir mal mit Jdiskreport Dein Systemlaufwerk an.

Oder das Laufwerk auf dem Deine Programme liegen


Oder das Laufwerk auf dem Deine Games liegen.


Praktisch alles bis auf Video-Dateien auf einem Desktop-PC besteht aus winzigsten Datei-Fragmenten.

Aber mit der Velozi haste schon nix falsch gemacht meiner Meinung nach.
 
Zuletzt bearbeitet:
sehe eben das es auch eine 150gig velo.rap.gibt ist die jetzt total neu oder gibt es die schon länger? ach man :( oder soll ich doch noch warten ob sich das mit den oczs noch gibt(vllt.werden auch deshalb immo keiner ausgeliefert weils probs gibt)

edit:sry for ot.....würde die velo.rap.an geschwindigkeit verlieren wenn man sie partitionieren würde? und stimmt es, dass man eine raid0 hdd nicht partitionieren soll?
vielen dank für tipps/hilfe
 
Zuletzt bearbeitet:
Hab jetzt auch meine OCZ Core (64GB) und möchte meinen Senf dazugeben ;)

Also HDTune zeigt genauso seltsame Schreibraten an wie bei allen anderen.
Sequentiell schreiben kann sie etwa 70MB/s (grosse Datei von anderer Platte draufschreiben), nachdem ich den Controller auf RAID gestellt habe (also kein AHCI).

Davor mit AHCI ist die Schreibrate immer kurz unter 20MB/s gefallen.

Zu den langsamen Random Writes kann ich nicht viel sagen, spürbar ist jedenfalls nix.
Kennt jmd. ein gutes Programm, um Random Write Acces Time zu benchen, ausser IOMeter?
 
@idle: Die 150 VR ist ja noch nicht kaufbar, nur erstmal gelistet, dauert sicher noch paar Wochen.
@cbot: HDBench

aha dachte ich mir fast :( trotzdem schlecht 150 hätten mir vollkommen gereicht brauch aber jetzt schon ne platte^^...brauch wer noch ne 37gig raptor?
 
Mit der Core habe ich das gefühl das ich beim Installieren von Servicepacks schon länger braucht.

Die ladezeit ist schon kürzer ins Windows, aber wenn ich auf dem Desktop bin kann ich erstmal nix machen weil die Core noch Sachen nachläd.

Was sollte man alles ausschalten? AHCI und Schreibcache oder nochwas?
 
Wenn ich die Lebenszeit eines SSD mit der Anzahl der Schreibvorgänge errechnen wollte, wie mache ich das? Ich weiß, dass Windows im normalen Betrieb ca. 7 Schreibzugriffe pro Sekunde veranlasst. Ich weiß jedoch nicht, wie viele Bit (also Zellen) diese 7 Schreibzugriffe mir einschließen. Kann ich das irgendwie herausfinden?

Edit: Eigentlich waren es bisher nur AHCI und Schreibcache. Auch die timestamps und die Hintergrunddefragmentierung kannst Du abschalten.
 
Zuletzt bearbeitet:
Windows-Protokolle (incl. Datenträger) macht man mit Systemsteuerung/Verwaltung/Leistung. Rechter Klick ins Diagramm ermöglicht neues Kurzzeitdiagramm. Für Langzeitprotokoll rechter Klick in Leistungsindikatorenprotokolle -> Neue Protokolleinstellungen. Namen vergeben und Indikatoren hinzufügen. Mit dem Zeitplan kann man das Protokoll starten und anhalten. Es wird eine Binärdatei geschrieben, die man später im Diagramm anschauen kann.
 
Timestamps abschalten mit "fsutil behavior set disablelastaccess 1". Für Hintergrunddefrag. in der Registry nach "EnableAutoLayout" suchen. Indizierung: bei den Diensten den Indexdienst abschalten.
 
Timestamps abschalten mit "fsutil behavior set disablelastaccess 1". Für Hintergrunddefrag. in der Registry nach "EnableAutoLayout" suchen. Indizierung: bei den Diensten den Indexdienst abschalten.

Ok, Danke. Das finde ich unter XP nicht. Dann gilt dies nur für Vista.
 
Wie ist das eigentlich mit SSDs, darf man die auch partitionieren oder würde das auf die Performance drücken... würde - wenn ich eine hätte - die SSD als Systemscheibe mit 3 Partitionen verwenden wollen...
 
Man kann alles mit der SSD machen was mit einer normalen Festplatte auch machen kann. Dazu gehört auch partitionieren und eine array configuration
 
@dpante1s
Bei einem Laufwerk das nicht mechanisch ist, wirkt sich die Partitionierung nicht auf die Performance aus.
Hinzugefügter Post:
Ok, Danke. Das finde ich unter XP nicht. Dann gilt dies nur für Vista.

Geht bestens unter XP. Einfach in die Console Hämmern
 
Zuletzt bearbeitet:
Bei meinem Vista x64 Home Premium ist die Timestamp Funktion Original schon auf 1 in der Regedit. Sollte somit bei Vista nix bringen wenn das Default abgeschaltet ist. Aber bei XP evtl. anders
 
Zuletzt bearbeitet:
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