News AMD mit Radeon R7 SSD auf OCZ-Basis?

[tomturbo]

Na was ist der interne Cache unbekannter Größe jetzt?
DRAM oder NAND?
Wenn der Controler eh kein RAM hat, dann ist es doch kein Problem, es steht bei einem Stromausfall im NAND des Caches unbekannter Größe.
Deshalb braucht man offen bar kein FLUSH CACHE da alles sowieso geschrieben ist.
Beim Wiederaufwachen wird dieser Bereich halt recovered wie es das Journal bei einem Journaldateisystem gemacht wird.
Also ich sehe da keinen Datenverlust weit und breit.
Das einzige was verloren gehen kann ist das IO das gerade auf der Leitung ist, ok das tut es aber in jedem Fall.

 

[SPINA]

Na was ist der interne Cache unbekannter Größe jetzt? DRAM oder NAND?

NAND wäre dafür zu langsam und der Cache hat sich als flüchtig erweisen. Ob es SRAM, eDRAM oder was auch immer ist, hält SandForce geheim.

Zum Ausgleich wird der Controller RAM Inhalt deutlich öfters auf NAND geschrieben.

Es sei denn der SF-1200 ohne Stützkondensator wird mit einer SF-1500 Firmware versehen, so wie es OCZ bei der Vertex 2 gemacht hat.

 

[tomturbo]

OK, gut dann können wir das OT Thema damit bitte abschließen.
Wer möchte kann ja einen eigenen Thread aufmachen.

 

[Complicated]

Damit hast du natürlich Recht. In der Eile hat sich ein Denkfehler bei mir eingeschlichen.
Die SandForce Controller setzen zwar auf keinen externen DRAM Cache, aber ein interner Cache (unbekannter Größe) ist beim SF-1200 und den Nachfolgern vorhanden. Andernfalls könnte er zum Beispiel gar keine einkommenden Befehle mittels NCQ umsortieren; die Kompression muss sich auch irgendwo abspielen.

Nur um das abzuschließen: Dieser interne Controler RAM ist unter 100MB gross und wird bei den SF-1200 Controllern nicht auf die NANDs geschrieben bei Stromverlust. Das ist der gravierende Unterschied zwischen den SF-1500 und SF-1200 FW-Versionen. Die SF-1200 FW geht davon aus, dass keine Kapazitatoren verbaut sind und daher stoppt Sie alle Schreibopertationen bei Stromverlust. Zum Ausgleich wird der Controller RAM Inhalt deutlich öfters auf NAND geschrieben.
http://www.xtremesystems.org/forums/showthread.php?278816-SSD-s-cache-and-power-loss-protection

The SF-1200 firmware doesn’t assume the presence of a large capacitor to keep the controller/NAND powered long enough to complete all writes in the event of a power failure. As such it does more frequent check pointing and doesn’t guarantee the write in progress will complete before it’s acknowledged.

The SF-1500 is designed to complete any writes in progress in the event of sudden power loss. The SF-1500 firmware is configured to expect the presence of a capacitor and can write at full speed without any worries about power loss.

http://www.anandtech.com/show/3661/understanding-sandforces-sf1200-sf1500-not-all-drives-are-equal

As an enterprise class solution, the SF-1500 is designed to complete any writes in progress in the event of sudden power loss. The SF-1500 firmware is configured expecting the presence of the super cap we saw in the Vertex 2 Pro. As such it expects that it can write at full speed without any worries about power loss. In other words, it assumes you have power failure protection at the drive level.

The SF-1200 firmware on the other hand doesn’t assume the presence of a large capacitor to keep the controller/NAND powered long enough to complete all writes in the event of a power failure. As such it does more frequent check pointing and doesn’t guarantee the write in progress will complete before it’s acknowledged. It’s a subtle difference, but the SF-1500 with super cap may be necessary for some of SandForce’s enterprise customers.

 

[Holt]

Es ist nicht Off-Topic!

Das ist exakt das Verhalten eines write back caches.
Der sagt dem Betriebsystem bei jedem sync es ist alles geschrieben.

Nein, das ist nicht richtig! Du kennst Du offensichtlich überhaupt nicht damit aus und versuchst auch nicht einmal Deine Aussagen zu belegen. Das ist nützlich, denn wenn man Quellen für seine Aussagen sucht, bekommt man entweder bestätigt das diese richtig sind oder kann seinen Irrtum gleich widerlegen finden:

Bei einem Schreibzugriff auf einen Block, der im Cache vorhanden ist, gibt es prinzipiell zwei Möglichkeiten:

* Zurückkopieren (write-back)

Beim Schreiben wird der zu schreibende Block nicht sofort in der nächsthöheren Speicherebene abgelegt, sondern zunächst im Cache. Dabei entsteht eine Inkonsistenz zwischen Cache und zu cachendem Speicher. Letzterer enthält somit veraltete Information. Erst wenn das Wort aus dem Cache verdrängt wird, wird es auch in die nächsthöhere Speicherebene geschrieben. Dazu bekommt jeder Cacheblock ein sogenanntes Dirty Bit, das anzeigt, ob der Block beim Ersetzen zurückkopiert werden muss. Das führt bei Speicherzugriff durch andere Prozessoren oder DMA-Geräte zu Problemen, weil diese veraltete Informationen lesen würden. Abhilfe schaffen hier Cache-Kohärenz-Protokolle wie z. B. MESI für UMA-Systeme.

* Durchgängiges Schreiben (write-through)

Der zu schreibende Block wird sofort in der nächsthöheren Speicherebene abgelegt. Damit ist die Konsistenz gesichert. Damit der Prozessor nicht jedes Mal warten muss, bis der Block in der nächsthöheren Speicherebene (die ja langsamer als der Cache ist) abgelegt ist, benutzt man einen Pufferspeicher (write buffer). Wenn dieser voll läuft, muss der Prozessor jedoch anhalten und warten.

Nur ein write through cache macht das nicht.

Das ist logisch, aber bei einem write through cache hat man ja auch keinerlei Verbesserung der Schreibleistung durch den Cache, weil die Daten ja beim Schrieben immer sofort auf der Medium geschrieben werden, was aber bei aktuellen SSDs nicht der Fall ist.

ATA Flush cache hat nichts mit sync des Betriebsystems zu tun!
Sync geht in den write back cache nichts weiter.

Und wie funktioniert ein sync auf Betriebssystem- bzw. Programmebene Deiner Meinung nach, wenn nicht durch übersetzen einer SATA Befehl durch den Treiber? Auf die Erklärung werde ich warten!

Im Consumerbereich ist write back dagegen meistens per default eingeschaltet.

Bei Consumer SSDs unter Windows wird der Schreibcache per Default aktiviert, das kannst Du doch leicht prüfen. Du hast Dir weder den Link angesehen diesen LINK angesehen, den ich schon im letzten Post schon gebracht haben oder es schlicht nicht auch nur ansatzweise verstanden.

Wenn allerdings flush cache "gefaket" wird dann ist das tatsächlich ein Mangel und Schummeln des Herstellers.

Davon rede ich doch, KLICK HIER DRAUF und lies noch etwas mehr auf der Seite, dann verstehst Du hoffentlich endlich, dass es genau das ist und das bei der Vertex4 und bei der ARC ist es eben auch so, sehr wahrscheinlich bei allen OCZ mit Barefoot3.

Die Frage ist eher ob man die SSDs auf write through umschalten kann.

Dazu habe ich eben nichts gefunden, zumindest nichts allgemeingültiges in der ATA Spezifikation und daher kann es nur darüber gehen, dass der Treiber nach dem Schreiben eben z.B. FLUSH CACHE bzw. FLUSH CACHE EXT nach jedem Schreibbefehl schickt, was dann auf das gleiche hinausläuft. Der Treiber meldet dann erst den Schreibvorgang als abgeschlossen an das Programm/Windows zurück, wenn er den sync als abgeschlossen bestätigt bekommen hat. Dann stoppen z.B. die Benchmarks die Time und ermitteln die Schreibrate oder Windows sagt dem Netzteil, dass es nun den Saft abdrehen kann.

Der Punkt ist hier nur, dass Sandforce Controller gar keinen Daten Cache benutzen danke Ihrer Dura Technik. Es werden auch die Daten nur komprimiert auf die NANDs geschrieben http://anandtech.com/show/2899/4

Ein Controller einer SSD ist ein Microprozessor, meist auf ARM oder MIPS Kernen basierend, also eine CPU und die braucht ein RAM, sonst funktioniert keine CPU der Welt. Da müssen auch die Daten liegen die ja beim SF beim schreiben auch immer noch komprimiert und verschlüsselt werden und beim lesen wieder entpackt und entschlüsselt. Das kann man nicht im NANDs machen, zumal NAND keinen wahlfeiren Zugriffe wie RAM erlaubt und viel zu langsam wäre, obendrein wäre die WA sonst weit von Gut und Böse, wollen man auch alle temporären Daten dort ablegen.

Da kann also gar nicht mit solchen Methoden beschissen werden. Das war übrigens auch der Grund warum ich mir damals auch eine Vertex 2 geholt habe. Keine Datencache.

Doch kann es und wird es und einen Datencache hat sie auch, nur nicht als externen RAM Baustein, sondern entweder Ondie oder als Multi-Die-Package im Gehäuse, so wie es ja auch Toshiba mit einen SSD Controllern macht die auf Marvell basieren, denn kein aktueller Marvell SSD Controller kommt ohne einen RAM Baustein aus, die anderen ja auch nicht. Das ist für eine Firma die sowieso RAM und NANDs herstellt und in Multi-Die Packages packt ja auch kein Akt da einen einen Controller Chip mit einem oder zwei RAM in einem Gehäuse zu kombinieren.

Aber hier wird ja kein Sandforce Controller verwendet bei AMDs SSDs...

Du hast diesen LINK auch nicht angeklickt. Ich bekomme das Bild von directupload.net hier nicht hochgeladen und die der anderen (Corsair Performance Pro + Samsung 830) bzw. der MX100 leider auch nicht. Zum Vergleich noch das einer Solidata mit SF-2281 da und bei der Vertex 4.

Es geht mir doch hier nicht darum euch zu verarschen, ich versuche euch zu zeigen, wie ihr von bestimmten Herstellern verarscht werdet und wenn ihr nun mal 5 Minuten annehmt ich könnte recht haben, den Links folgt und etwas nachdenkt, dann könntet ihr das vielleicht auch mal merken. Bei den Preise die für die AMD SSD aufgerufen werden, die liegen ja noch mal deutlich über denen der Samsung 850 Pro und Intel 730 und die schlagen die R7 eigentlich in jeder Hinsicht (Performance, Performance Consistancy, Garantie, Haltbarkeit und bei der 730 auch Enterprise Features wie Stützkondensatoren), wird die aber sowieso nicht viele Käufer finden, da stimmt dann zwar die Marge aber wohl kaum der Umsatz.

 

[tomturbo]

Direktes Schreiben geht beim Betriebsystem mit o_direct (oder was es halt beim Betriebsystem für einen call dafür gibt) aber nicht mit sync.
Sync ist ein Vorgang der vom Betriebsystemcache zum IO-Device regelmäßig (mehr oder weniger) stattfindet.

Ein IO weiß zu einem Zeitpunkt normalerweise nicht ob das Gerät einen writeback cache hat oder nicht.
Wenn dann dort ein writeback cache vorhanden ist dann ist sync beendet, wenn alles im write back cache ist bzw. das Gerät ok zurückmeldet.
Das hat nichts damit zu tun ob der cache jetzt voll oder nicht ist, das ist wieder eine vollkommen andere Baustelle.

 

[Cappuandy]

OK, gut dann können wir das OT Thema damit bitte abschließen.
Wer möchte kann ja einen eigenen Thread aufmachen.

Jupp, wenn man Thread Aboniert hat denkt man da gibts wirklich was neues aber nee ne Diskusion über andere SSDs u. wie/was funktioniert.
Das ist ja wie die unnötige Diskusion und vergebliche überredungsversuche einen zu einem anderen Produkt zu bewegen.

Topic: aber hey, die R7 SSD o. die ARC 100 wird wohl f. mein FM2+ geholt. (jenachdem wie sich der Marktpreis einpendelt v. beiden)
Die reicht locker f. dessen Aufgabe > OCZ weiterhin unterstütze gegen die anderen Marktriesen!

Gruß

 

[SPINA]

Die reicht locker f. dessen Aufgabe > OCZ weiterhin unterstütze gegen die anderen Marktriesen!

Wenn du die "Kleinen" unterstützen möchtest, warum nimmst du dann keine SSD von Corsair? Qualitativ scheinen die SSDs von Corsair sogar besser zu sein als diejenigen von OCZ. Man liest jedenfalls von deutlich weniger Zwischenfällen, obwohl sich Corsair immer wieder auf "Experimente" einlässt. Beispielsweise bei der Neutron GTX mit LAMD Controller oder bei der besonders günstigen Force LX mit Silicon Motion Controller. Das hebt sie von anderen kleinen Herstellern ab, die lediglich gängige OEM Produkte mit eigenem Label versehen. Wobei "klein" immer relativ ist. Corsair hat rund 800 Angestellte (Stand 2012) und produziert außerdem DRAM Module sowie einiges mehr. Mit Toshiba im Rücken gehört OCZ dagegen mittlerweile zu den ganz "Großen" am Markt, selbst wenn man ihnen das nicht gleich auf Anhieb ansieht. Unterstützung haben sie nicht mehr nötig. Wenn es darum geht, ist dein Geld woanders besser aufgehoben.

 

[Holt]

Direktes Schreiben geht beim Betriebsystem mit o_direct (oder was es halt beim Betriebsystem für einen call dafür gibt) aber nicht mit sync.

Windows sync Tool, Linux man(8) sync Befehl, Linux man(2) sync Funktion, Linux man(2) open mit den Falgs O_DIRECT und O_SYNC. Alles keine ATA Befehle und müssen daher in solche übersetzt werden, aber ich erkenne die Sinnlosigkeit des Unterfangens in ein Sieb Wasser zu füllen an und höre hier auf.

 

[Complicated]

Wird auch Zeit, denn da kommt wenig sinnvolles zu dem Thema. Da werden Programmierbefehle mit SATA Standards vermischt und sämtliche verlinkten Quellen enthalten nicht mal ansatzweise die Informationen die dort angeblich vorhanden wären. Zitate aus den elend langen Texten werden auch nicht geliefert um zumindest zu zeigen dass man vielleicht etwas überlesen hat.

Alles Zeitverschwendung ohne Nutzen. Aus cache flushes werden gefakte syncs die in MySQL geschrieben sind...also so ein durcheinander wie hier betrieben wird. Und mit jedem Nachweis dass dies Blödsinn ist, kommt noch etwas hahnebücheneres aus dem Ärmel geschüttelt wie der letzte Link....was hat das denn bitte mit SSDs zu tun?

Soll ich dir noch 20 links geben die das Wort "sync" enthalten und nicht mit dem Thema zu tun haben?

 

[Holt]

Auf SATA Ebene wären das die Befehle FLUSH CACHE - E7h oder FLUSH CACHE EXT - EAh (bei Laufwerken die 48bit Adressierung unterstützen) und das darf maximal 30s dauern.

Das Faken besagt, dass der Befehl sofort als ausgeführt behandelt wird, ohne die Daten wirklich auf die Datenträger zu schreiben

Aus cache flushes werden gefakte syncs die in MySQL geschrieben sind

Was hat das mit MySQL zu tun? Habe ich MySQL irgendwo erwähnt? Was rauchst Du da gerade?

Mit wurde unterstellt den Begriff sync-Faking selbst erfunden zu haben, das ich mit diesem Link widerlegt haben, der ebenfalls davon spricht, das es vorkommt, dass ein sync nicht wirklich ausgeführt wird und das als Faking bezeichnet. Das es dort um Datenbanken geht, ist egal, der wichtige Satz ist "Rumors are some ATA drives also do not implement cache flush command or lie about their cache settings." Das Datenbanken darunter generell besonders leiden, sollte auch klar sein, aber es ist nicht Datenbanken noch auf MySQL beschränkt: "Some people blame it as entirely MySQL problem - it is not the case. I've seen similar problems reported on PostgreSQL mailing list as well as by Oracle users. All disk based databases require pretty much same requirements from OS to function."

 

[Complicated]

Ja ganz toll der spricht über Sync faking in MySQL Datenbanken und OS Befehlen. Du hast lediglich den Zusammenhang zu SSDs erfunden, denn dort steht absolut nichts darüber, worüber du hier sprichst. Ich glaube langsam du kannst kein Englisch.

The fact however is, these exected guaranties are void from time to time. Depending on OS version, file system, hardware
configuration and even a way IO is performed. you may get a confirmaition when data is not on the disk yet. Two most well known cases are perhaps Linux 2.4 with ATA/SATA drives and OS X. In most 2.4 kernel versions (2.6 are told to be fixed in some cases, but I did not check) ATA/SATA will have drive cache enabled by default and it will not be flushed on fsync(), which means if you power down the box cache content will be lost leading to transaction loss or even database corruption. OS X just sellected fsync() not to be real fsync as users typically care about performance more than about
consistency It also will not flush cache on ATA/SATA drives. Apple however at least is clear about this and provided
special fcntl() call to perform real fsync. So latest MySQL versions can cope with it.

Ich weiss wirklich nicht wie du die Kurve zu SSDs bekommst, wenn hier uralte Linux Kernels und deren Verhalten bei jeglicher Festplatte beschrieben wird. Das kommt daher dass du nie Zitate aus deine Quellen lieferst.
Lern mal Englisch und lies meine Signatur.

---------- Beitrag hinzugefügt um 09:13 ---------- Vorheriger Beitrag um 08:58 ----------

Das es dort um Datenbanken geht, ist egal, der wichtige Satz ist "Rumors are some ATA drives also do not implement cache flush command or lie about their cache settings." Das Datenbanken darunter generell besonders leiden, sollte auch klar sein, aber es ist nicht Datenbanken noch auf MySQL beschränkt: "Some people blame it as entirely MySQL problem - it is not the case. I've seen similar problems reported on PostgreSQL mailing list as well as by Oracle users. All disk based databases require pretty much same requirements from OS to function."

Und das ist echt mal wieder die Krönung und zeigt dein mangelndes Textverständnis. Denkst du wirklich ich meinte spezifisch MySQL? Und PostgreSQL und Oracle verändert irgendetwas am Argument? Es sind "Requirements of the OS" und nicht der Festpatte. Und schon gar nicht ist das etwas SSD spezifisches. Soll ich mal Forenlinks aus der Zeit raus kramen als es noch keine AHCI Treiber gab und dir mal erklären wie beschissen SSDs ohne diese Funktion laufen? Oder wie schlecht die SSDs Daten übertragen wenn sie mit IDE Kabel angeschlossen werden?

 

[Holt]

Ja ganz toll der spricht über Sync faking in MySQL Datenbanken und OS Befehlen.

Löse Dich doch von den Datenbanken, da wird das Problem ja nur sehr offensichtlich. Den passenden Satz hast Du doch selbst gefunden und im Zitat auch nicht hervorgehoben: "same requirements from OS to function.""

Du hast lediglich den Zusammenhang zu SSDs erfunden,

Nein, den habe ich weder er- noch gefunden. Schau doch mal bitte hier rein, den Thread hatte oben schon verlinkt mit der eindringlichen Bitte dort mal drauf zu klicken und sich die Images der verschiedenen SSD, z.B. der MX100, Solidata und der Vertex4 anzusehen. Wenn Dir da kein krasser Unterschied vor allem bei den 4k Schreibrate bei der MX100 auffällt, der bei der Solidata und der Vertex4 nicht vorhanden ist, dann weiß ich auch nicht weiter. Leider kann ich die Images hier nicht direkt einbinden, aber noch mal die Links direkt:

Corsair Performance Pro: 85,21MB/s bei 4k QD1 Schreibend mit Schreibcache, 3,14MB/s ohne Schreibcache
Samsung 830: 90,2MB/s bei 4k QD1 Schreibend mit Schreibcache, 2,33MB/s ohne Schreibcache
MX100: 110,66MB/s bei 4k QD1 Schreibend mit Schreibcache, 2,33MB/s ohne Schreibcache
Solidata: 106,81MB/s bei 4k QD1 Schreibend mit Schreibcache, 104,78MB/s ohne Schreibcache
Vertex 4: 108,21MB/s bei 4k QD1 Schreibend mit Schreibcache, 109,14MB/s ohne Schreibcache

NAND kann man schneller auslesen als beschreiben, die 4k QD1 Lesend liegen bei den genannten SSDs zwischen 21 und 31MB/s. Jetzt beantworte Du Dir mal selbst die Frage, welchen Trick die Solidata mit dem SF-2281 und die Vertex4 wohl anwenden, damit die Schreibrate auch ohne Schreibcache praktisch unverändert bleibt, während sie bei anderen SSDs von 85 bis 110MB/s brutal auf so 2 bis 3 MB/s fällt.

Dann überlege auch mal, ob es einen Zusammenhang zwischen dem Satz "Rumors are some ATA drives also do not implement cache flush command or lie about their cache settings." und SSDs geben könnte.

denn dort steht absolut nichts darüber, worüber du hier sprichst.

Das es dort nicht steht, wundert wohl nicht, wenn Du Dir das Datum mal ansiehst: 2005-03-21

Ich glaube langsam du kannst kein Englisch.

Nein, aber irgendwie habe ich es trotzdem geschafft in England zu studieren

Und das ist echt mal wieder die Krönung und zeigt dein mangelndes Textverständnis.

Die Ehre gebührt doch ganz klar anderen Leuten hier.

 

[Complicated]

Was hast denn dort studiert? Königliche Gerüchteküche?
Wenn alle ATA Drives betroffen sind, die einen cache nutzen ist das ein SSD Problem?
Logik erwünscht. Dort gehts um Programmierung.

Du solltest dir eher mal überlegen wieso du einen Link hier postest aus der Pre-SSD Zeit zu einem uralt bekannten Problem dem du hier eine relevanz zusprichst die dort nicht bestehen kann.

---------- Beitrag hinzugefügt um 12:53 ---------- Vorheriger Beitrag um 10:18 ----------

Jetzt beantworte Du Dir mal selbst die Frage, welchen Trick die Solidata mit dem SF-2281 und die Vertex4 wohl anwenden, damit die Schreibrate auch ohne Schreibcache praktisch unverändert bleibt, während sie bei anderen SSDs von 85 bis 110MB/s brutal auf so 2 bis 3 MB/s fällt.

Dann überlege auch mal, ob es einen Zusammenhang zwischen dem Satz "Rumors are some ATA drives also do not implement cache flush command or lie about their cache settings." und SSDs geben könnte.

Nun nach reiflicher Überlegung habe ich festgestellt, dass eine SSD die KEINEN Cache hat wohl auch keinen ATA flush cache Befehl benötigt. Und wie soll denn ohne den flush cache Befehl ein "gefakter sync" erfolgen?

Warum Sandforce keine Einbrüche hat liegt einfach daran, dass sie immer keinen Cache verwenden..das liegt in deren Controller Technik und den Kompressions Algorythmen.
Darin unterscheiden sich nämlich SSD Controller grundsätzlich: in der Art wie Daten auf die NANDs geschrieben werden. Durch Kompression und Deduplizierung schreiben Sandforce Controller deutlich weniger Daten in die NANDs als andere. Windows7+Office benötigt z.B. ca. 25 GB Daten, doch auf einer Vertex2 werden lediglich 11 GB tatsächlich in NAND geschrieben. Und dass 11 GB schneller geschrieben werden als 25 GB sollte auch deine "verdächtigen" Werte erklären, die keinen Unterschied mit oder ohne Cache haben.
http://www.anandtech.com/show/2899/3

Der Witz dabei ist, dass ich vor 3 Jahren schon mit dir diese Diskussion geführt hatte (Bei Computerbase), doch damals hast du es auch nicht verstanden. Und heute hast du wieder irgendwas anderes gefunden aus dem selben Mangel an Verständnis was Komppression und Deduplizierung sind. Deine mangelnden Fachkenntnisse sind ja nicht neu, wie ja schon Mitarbeiter von SSD Herstellern festgestellt haben:
http://www.computerbase.de/forum/showthread.php?t=877875&p=9776047#post9776047

Da hier nun doch von den beiden chaosmayhemsoap und holt relativ viel gefährliches Halbwissen verbreitet wurde, sollte man nun doch noch einige Sachen klarstellen.
Es ist keine sachliche Diskussion, wenn man Seriösität für sich beansprucht, andere dann aber als Fanboys tituliert. Ebenso ist es genauso unseriös anderen zu unterstellen Sie würden für Hersteller arbeiten, nur weil sie eine andere Meinung vertreten als Ihr. Oder zu unterstellen man würde Sachen 'falsch' verstehen. Auch mir zu unterstellen ich würde unsere Produkte 'in den Himmel loben' ist falsch, weil das habe ich mit keinem Wort getan und wenn es so wäre hätte sich schon einer der Mods bei mir gemeldet.
Auf so einer Ebene weiterzudiskutieren ist unnötig.
Im Gegensatz zu den kruden Theorien die hier unter dem Deckmantel der Anonymität verbreitet werden, weiss man dass ich für ein Unternehmen arbeite, das seit mehreren Jahrzehnten im Halbleiterbereich (DRAM und Flash) aktiv ist. Ich werde hier im Gegensatz zu anderen deswegen keine Behauptungen auftsellen die unwahr sind.
Wenn man dann allerdings soviel Halbwissen oder gar Unwissen zeigt, dann muss man sich fragen was das eigentlich soll:
Die von Euch genutzten Quellen sind teilweise so abstrus, wie die Schlussfolgerungen die ihr daraus zieht:

Die detaillierte Aufdeckung des selben Blödsinns wie hier teilweise immer noch verbreitet wird kann ja jeder dort lesen wenn er das wünscht. Dazu gelernt scheinst du nichts zu haben in 3 Jahren was Zuverlässigkeit und Substanz deiner Informationsquellen angeht.

 

[eratte]

Don't feed the Troll.

 

[Complicated]

Hast ja recht...

 

[Holt]

1.) Das der SF doch einen Cache haben muss, wurde ja schon beschrieben, die Vertex4 hat einen und auf die gehst Du natürlich nicht ein.
2.) Deduplizierung findest Du bei dem Phison 3108, der SF hat eine echte Datenkompression, aber das nur am Rande.
3.) Halte ich mich jetzt auch an erattes Rat, denn Dein ganzen Verfahlen im Thread hier und in anderen zeigt, dass Du nur auf Krawalle aus bist, aber nichts lernen möchtest.

 

[Complicated]

Arbeitsspeicher eines Controllers ist kein Cache.

Was Deduplizierung ist hast du immer noch nicht verstanden.

Da es nichts zu lernen gibt von dir, setz ich dich auf die Ignoreliste.
Normal sag ich das zwar nicht an, doch damit du merkst wie absurd deine letzte Behauptung wieder mal war, dass ich auf Krawall aus sei.

3 Punkte und erneut 3 Mal Unsinn erzählt....ist wirklich ausreichend.

 

[Scour]

Willkommen im Club

Manche listen die 240GB-Variante als verfügbar, der Preis ist mir allerdings viel zu hoch

http://geizhals.at/de/ocz-amd-radeon-r7-ssd-240gb-radeon-r7ssd-240g-a1154205.html

 

[Woodstock]

Die ist doch noch ganz frisch
Warte mal noch ein paar Tage. Dann dürften sie sich dem Preisniveau der Mitbewerber annähern.

 

[Scour]

Sollten sie auch

Besonders da es genügend gibt die 256GB offerieren

Wäre trotzdem nett wenn man Alternativen zu der Flut an Marvell, SF (immer noch) hat

 

[Holt]

Na was ist der interne Cache unbekannter Größe jetzt?

SRAM, ich wusste, ich hatte es mal irgendwo gelesen und bis gerade drüber gestolpert:

In nearly all of these configurations, volatile memory (DRAM) is used as cache for pending operations (Intel and SandForce excluded, they cache in SRAM)

NAND wäre dafür zu langsam und der Cache hat sich als flüchtig erweisen.

SanDisk schneit sein nCache mal so verwendet zu haben, vielleicht in dieser alten, namenlose SSD mit der lahmen Random Performance, die sich damit gut erklären würde.

Ob es SRAM, eDRAM oder was auch immer ist, hält SandForce geheim.

Dem Anand haben sie es dich verraten.

 

[Gast29012019_2]

Hat jede SSD, z.b Crucial M4 oder neuerer einen Pufferkondensator, im Falle eines Stromausfalles. Da ja hier das Problem des Wiedererkennung bestand, zu spekulieren ist auch das hier der OnBoard Cache im Write Through arbeitet, im vgl. zu einem Raid-Controller mit Speicher, und einer idealerweise vorhandenen Pufferbatterie im Write Through Modus, sofern man das überhaupt vergleichen.

 

[SPINA]

Hat jede SSD, z.b Crucial M4 oder neuerer einen Pufferkondensator, im Falle eines Stromausfalles?

Nein, nicht alle modernen SSDs haben Stützkondensatoren. Diese Bauteile lassen sich jedoch leicht auf dem PCB ausmachen.

Man muss demnach nicht ellenlange Datenblätter studieren. Ein Blick auf die nackte Platine reicht in der Regel vollkommen aus.

 

[Holt]

Eigentlich haben nur die wenigsten Consumer SSD Stützkondensatoren, während das bei "richtigen" Enterprise SSDs normal ist, bei den oft auch als Enterprise SSDs vermarkteten Modellen die eher als OEM SSDs in normalen PCs landen, wie etwa der Intel Pro 2500 oder den SanDisk X Modellen, ist der meist auch nicht vorhanden, da muss man aber im Einzelfall immer genau hinsehen.

Von den Consumer SSDs hat nur die komplette aktuelle Crucial Liene (seid der m500) diese Kondensatoren, aber die reichen laut Anand Vermutung wohl bei den Crucial nur für das Schreiben der Verwaltungsdaten, was im Anbetracht des Tests mit und ohne aktivem Schreibcache auch plausible ist. Dann hatte die Intel 320 Kondensatoren, aber da lief wohl was schief, den 8MB konnten sie nicht verhindern und die Intel 730 hat welche, die stammt ja auch direkt von der DC S3500 ab und solche Data Center SSDs haben i.d.R. alle welche. Wer noch eine andere Consumer SSD mit Stützkondensatoren kennt, kann die Liste gerne erweitern.