Lynxx, viele Hersteller sparen an der Größe der Platine, das senkt die Kosten und eine 4TB Version der PM863 gibt es schon, die der 850 Evo (und wohl auch Pro) ist schon angekündigt. Das sind deswegen keine 1.8" SSDs, denn die 2.5" werden mit 5V versorgt, die 1.8" dagegen mit nur 3.3V.
Wurde die SSD einmal komplett beschrieben und wird sie nicht getrimmt, dann bleibt sie für den Controller immer randvoll, allen LBAs bleiben immer gültige Daten zugeordnet, auch wenn man die SSD komplett formatiert und aus sich des Anwenders damit keine gültigen Daten mehr vorhanden sind. Da bleiben dem Controller nur die paar Prozent Free Area die ab Werk immer da sind, denn eine 512GB (512.000.000.000 Byte) SSD hat immer mindestens 512GiB NAND (512*1024^3 Byte NAND Kapazität, also fast 7% mehr. Ein Teil davon geht für Verwaltungsdaten wie die Mappingtablle und die FW ab, der Rest ist Free Area und das ist für eine gute Performance recht wenig, zumal wenn der Controller eben nicht gleich jeden Block aufräumt in dem von 512 oder 1024 Pages nur ein paar wenig ungültige Daten enthalten.
Andererseits muss es bei vielleicht 6% Free Area auch Blöcke löschen bei denen nur 4 von 512 Pages schon ungültige Daten enthalten, sonst hätte er bald gar keine leeren Pages zum Schreiben zur Verfügung! Das bedeutet aber auch, dass er die Daten von 508 Pages intern kopieren muss, was eine hohe Write Amplification erzeugt, also einen hohen Verschleiß der NANDs und wenn es während eines Schreivorgangs passiert, hat er danach nur noch 4 Pages für neue Daten zur Verfügung, keine 10% der Kapazität des Blocks! Wenn diese 508 Pages aber Daten enthalten die den Anwender schon gar nicht mehr interessieren, weil sie eben z.B. zu Dateien gehören die schon gelöscht wurden, dann kann er sich das Kopieren sparen und er kann so einen Block in dem alle Pages nur noch ungültige Daten enthalten auch einfach so löschen, ohne überhaupt was kopieren zu müssen und das schon vor dem Schreibvorgang.
Daher ist TRIM für jede SSD nützlich, egal was für NAND sie hat und daher kann auch die interne Idle-GC des Controllers niemals ersetzen, weil die eben nicht wissen kann, welche Daten für den Nutzer schon nicht mehr wichtig sind, das teilt das Betriebssystem der SSD ja gerade über diese TRIM Befehl mit, deswegen hat man die ja eingeführt.
Der einzige Weg ohne TRIM auszukommen und trotzdem volle Performance zu haben ist genug Overprovisioning, also nur einen Teil der Kapazität zu nutzen und die anderen LBAs nie beschrieben zu haben. Treiber man es auf die Spitze und lässt 50% ungenutzt, so kann man die anderen 50% auch jederzeit (ggf. mit Pausen dazwischen) mit der vollen Geschwindigkeit überschreiben, da ja der Controller dann genug freie Pages hat, die eine Hälfte ist ja unbenutzt. In die freien NAND Page kann der Controller dann schreiben, nach dem Überschreiben der LBAs in dem genutzten Adressbereich weiß er dann auch, dass die ganze alten Daten nun ungültig sind und kann sie dann löschen (eben ggf. in der nächsten Pause wenn er wieder Idle ist) um für den nächsten Schreibvorgang wieder genug freie Pages zu haben.
Im Consumer Segment gibt es nur die 850er mit 2TB, von daher kann man da kaum von normalen Preisen reden.Marcel55 schrieb:
Ein SATA 12Gb/s wird es nie geben, da man dafür andere, viel aufwendigere Stecker und Kabel brauchen würde, wie man bei SAS 12Gb/s sieht, dort macht es wegen der vielfach genutzten Multiplexer auch Sinn, aber eine HDD kann bisher nicht einmal die Bandbreite von SATA 3Gb/s auslasten, geschweigen denn die von SATA 6Gb/s und daher hat man sich für SSDs für PCIe entschieden, da ist man bei PCIe 3.0 x4 schon bei real über 3GB/s Nettobandbreite.Marcel55 schrieb:
Für die 840 Evo gibt es einen Bugfix und bei der Vorgängerversion 840 (ohne Zusatz) gibt es keinen echten Beleg für den Bug, von den Leute die das meinen wurde mit total ungeeigneten Benchmark getestet.FUSION5 schrieb:
Nein, jedes NAND muss ab und zu refresht werden, wenn das der Bugfix ist, wurde das nur nicht oft genug gemacht. Außerdem haben die NANDs der Evo mit 1200 spezifizierten P/E Zyklen genug Haltbarkeit, da kann man jeden Monat einen Refresh machen und das 100 Jahre lang und wer viel auf die SSD schreibt, also selbst viele Zyklen verbraucht, hat keine alten Daten, da schon wegen dem Wear-Leveling die alten Daten dann öfter mal intern umkopiert werden müssen. Wo ist das also das Problem? Ich kann da einfach keines sehen.FUSION5 schrieb:
Ja das Optane (aka 3D XPoint) klingt interessant, vor allem weil es die 4k QD Lesend noch mal deutlich steigern wird und davon hat man im Alltag am Meisten, aber das dürfte Intel sich wohl leider auch teuer bezahlen lassen, zumal am Anfang. Da immer was neueres, besseres, schnelleres, billigeres etc. angekündigt wird und irgendwann kommt, muss man aber irgendwann mal zuschlagen, sonst kommt man ja nie zum Zuge und ich habe ja noch einen PCIe 3.0 x16 Slot und 4 Lanes direkt von der CPU in meinem Z97 Extreme 6 frei.FUSION5 schrieb:Ja die 950 Pro ist schon ein Leckerbissen. Halte mich bisher nur aufgrund Intels Optane Ankündigung zurück, aber ob ich das durchhalten werde...
Und das ohne TRIM, da kann die Performance nur im Keller landen und die Samsung Consumer SSDs mögen das nicht wirklich gerne, die erwarten schon getrimmt zu werden. SSDs die auch ohne TRIM die Performance gut halten, aber dafür eine sehr aggressive Idle-GC und die schleißt die NANDs dann ganz schon auf, die alten Indilinx Barefoot sind dafür ein gutes Beispiel und offenbar auch die Plextor M5 Pro (wie z.B. dieser Fall zeigt), zumindest hat Plextor die FW der M6 Pro ganz anders ausgelegt und die kommt nun ohne TRIM auch nicht mehr besonders gut klar, im Gegenteil leidet die Performance dann auch massiv.C2KXDeaf schrieb:
Natürlich "braucht" auch eine SSD mit SLC NAND TRIM, bzw. profitiert auch bei denen die Schreibperformance davon wenn sie getrimmt werdne. Denn auch wenn bei denen das Schreiben schneller geht und daher das Fehlen von TRIM weniger massive Performanceeinbrüche bedeutet, so bleibt es doch dabei, dass dem Controller beim Schreiben großer Datenvolumen auf eine SSD die nicht so viel freien Platz hat, irgendwann die freien NAND Pages ausgehen und dann muss es während des Schreibvorgangs neue freie Pages schaffen. Er muss als die NAND Blöcke fürs Löschen aussuchen, die noch gültigen Daten erst einmal auf Pages in dem zuletzt gelöschten Block kopieren und dann den Block löschen. Gültig sind für den Controller alle Daten die einmal geschrieben wurden, bis der LBA dem sie zugeordnet sind wieder überschrieben wird oder eben bis er getrimmt wird (oder bis zu einem Secure Erease Befehl, aber das lasse ich mal weg, der gehört ja nicht zum Alltag einer SSD).C2KXDeaf schrieb:
Wurde die SSD einmal komplett beschrieben und wird sie nicht getrimmt, dann bleibt sie für den Controller immer randvoll, allen LBAs bleiben immer gültige Daten zugeordnet, auch wenn man die SSD komplett formatiert und aus sich des Anwenders damit keine gültigen Daten mehr vorhanden sind. Da bleiben dem Controller nur die paar Prozent Free Area die ab Werk immer da sind, denn eine 512GB (512.000.000.000 Byte) SSD hat immer mindestens 512GiB NAND (512*1024^3 Byte NAND Kapazität, also fast 7% mehr. Ein Teil davon geht für Verwaltungsdaten wie die Mappingtablle und die FW ab, der Rest ist Free Area und das ist für eine gute Performance recht wenig, zumal wenn der Controller eben nicht gleich jeden Block aufräumt in dem von 512 oder 1024 Pages nur ein paar wenig ungültige Daten enthalten.
Andererseits muss es bei vielleicht 6% Free Area auch Blöcke löschen bei denen nur 4 von 512 Pages schon ungültige Daten enthalten, sonst hätte er bald gar keine leeren Pages zum Schreiben zur Verfügung! Das bedeutet aber auch, dass er die Daten von 508 Pages intern kopieren muss, was eine hohe Write Amplification erzeugt, also einen hohen Verschleiß der NANDs und wenn es während eines Schreivorgangs passiert, hat er danach nur noch 4 Pages für neue Daten zur Verfügung, keine 10% der Kapazität des Blocks! Wenn diese 508 Pages aber Daten enthalten die den Anwender schon gar nicht mehr interessieren, weil sie eben z.B. zu Dateien gehören die schon gelöscht wurden, dann kann er sich das Kopieren sparen und er kann so einen Block in dem alle Pages nur noch ungültige Daten enthalten auch einfach so löschen, ohne überhaupt was kopieren zu müssen und das schon vor dem Schreibvorgang.
Daher ist TRIM für jede SSD nützlich, egal was für NAND sie hat und daher kann auch die interne Idle-GC des Controllers niemals ersetzen, weil die eben nicht wissen kann, welche Daten für den Nutzer schon nicht mehr wichtig sind, das teilt das Betriebssystem der SSD ja gerade über diese TRIM Befehl mit, deswegen hat man die ja eingeführt.
Der einzige Weg ohne TRIM auszukommen und trotzdem volle Performance zu haben ist genug Overprovisioning, also nur einen Teil der Kapazität zu nutzen und die anderen LBAs nie beschrieben zu haben. Treiber man es auf die Spitze und lässt 50% ungenutzt, so kann man die anderen 50% auch jederzeit (ggf. mit Pausen dazwischen) mit der vollen Geschwindigkeit überschreiben, da ja der Controller dann genug freie Pages hat, die eine Hälfte ist ja unbenutzt. In die freien NAND Page kann der Controller dann schreiben, nach dem Überschreiben der LBAs in dem genutzten Adressbereich weiß er dann auch, dass die ganze alten Daten nun ungültig sind und kann sie dann löschen (eben ggf. in der nächsten Pause wenn er wieder Idle ist) um für den nächsten Schreibvorgang wieder genug freie Pages zu haben.
Ergänzung ()
Auch so, Du meinst den Pseudo-SLC Schreibcache? Ja der wird immer vom Controller gelöscht, sobald er Idle ist und steht damit immer wieder für schnelle Schreibvorgänge zur Verfügung, aber der bringt halt nur für ein paar GB etwas. Beim normale Windows Desktopbetrieb reicht das, aber wenn man einige Hundert GB Backup drauf schreibt, dann ist das eben der Grund warum die ersten x GB schnell gehen und der Rest dann wieder langsam, zumal wenn die SSD voll und nicht getrimmt wurde. Man sieht ja wie hier die ersten paar GB schnell geschrieben werden, die gehen in den Pseudo-SLC Schreibcache:Hallo32 schrieb:
2000 GB SSD für 700 Euro das finde ich sehr teuer 
