Test Intel SSD 600p im Test: Die günstigste NVMe-SSD schlägt SATA nur knapp
- Ersteller MichaG
- Erstellt am
- Zum Test: Intel SSD 600p im Test: Die günstigste NVMe-SSD schlägt SATA nur knapp
- Registriert
- Juli 2010
- Beiträge
- 13.387
Wir können das nicht nachvollziehen, da wir keine Intel 600p mehr hier haben. Aber ich habe es mal in dem entsprechenden Abschnitt als Hinweis ergänzt: https://www.computerbase.de/2017-01...bschnitt_kein_fuaproblem_trotz_windowstreiber
Danke!
Danke!
G
Gerk
Gast
Gerk schrieb:
Kennt Ihr Clonezilla? Man bootet von CD/Stick, hangelt sich durch ein paar Textabfragen, und dann liest es meine 7GB Ubuntu von einer SSD und schreibt das komprimiert auf 2GB auf die Archiv-SSD. Nach dem Schreibvorgang werden die geschriebenen Daten zur Kontrolle gelesen und die Prüfsumme verglichen. Der PC hat 16GB Ram. Und nun stelle ich mir vor, es wäre nur in den Cache geschrieben worden und artig geprüft worden... Ganz großes Kino. Super Performance.
Da ich verschiedene Systeme habe und häufig von CD boote, will ich nicht jedes Mal trickreiche Einstellungen vornehmen. Ich verlasse mich auf den Sachverstand der Softwareentwickler und verwende deren Standardeinstellungen.
G
Gerk
Gast
Höhöhöhö... nach der Kompression hat mich das Programm nie gefragt. 
Ich stelle mir gerade vor, es läuft unkomprimiert und die Datenrate wird höher - dafür sind es aber mehr Daten und dauert dann genau so lange, etwa 30 Sekunden schreiben und 30 Sekunden überprüfen. 
Es ging doch um das Thema Cache, und das will gut überlegt sein. Und mit Benchmarks veralbert man pubertäre Jungs und Schwachköpfe. Ich frage mich nur, sind die Alltagswerte einigermaßen plausibel und brauchbar, und gehe zur Tagesordnung über.
Ich stelle mir gerade vor, es läuft unkomprimiert und die Datenrate wird höher - dafür sind es aber mehr Daten und dauert dann genau so lange, etwa 30 Sekunden schreiben und 30 Sekunden überprüfen. Es ging doch um das Thema Cache, und das will gut überlegt sein. Und mit Benchmarks veralbert man pubertäre Jungs und Schwachköpfe. Ich frage mich nur, sind die Alltagswerte einigermaßen plausibel und brauchbar, und gehe zur Tagesordnung über.
Es kann ja sein es mit Kompression am Ende schneller ist, nur sollte man sich dann eben nicht wegen der Schreibraten der SSDs aufregen, da diese ja dann wahrscheinlich gar nicht voll gefordert werden. Außerdem wäre es hilfreich die konkreten SSDs zu benennen, es gibt ja auch welche die bei vollem Pseudo-SLC Schreibcache wirklich nur mit 120MB/s schreiben können.
G
Gerk
Gast
Entschuldige bitte, falls ich mich wieder unklar ausgedrückt habe. Ich rege mich keinesfalls wegen der Schreibraten der SSDs auf. Ich habe mich einfach belustigt gewundert.
Mein 2. Lieblingsthema ist Datenschutz, aber weil Du's bist: Es geht um eine Toshi HG6 und ein Micron C400 und um ein Bord mit einem C600 Chipsatz mit Raid Erweiterung. Das Board hat 2 SATA3 Ports und 4 SATA2er am Raid-Controller. Und nun läuft dummer Weise kein ATAPI-Laufwerk sauber am Raid, also das DVD-Laufwerk, weshalb ich praktisch nur eine SATA3-SSD hatte. Nun habe ich das DVD-Laufwerk abgesteckt und die C400 an den Port - und am Ende habe ich verwundert festgestellt, dass es praktisch gar nichts gebracht hat. Meine Neugier ist befriedigt und damit kann ich sehr gut leben.
Also Leute, macht Euch nicht wegen albernen Benchmarkwerten verrückt und geht den breiten, standardisierten Alltagsweg, den die allermeisten User gehen. Damit sind die Geräte erprobt und wohl am zuverlässigsten. Zuverlässigkeit kommt bei mir zuerst.
(Und wieder bitte ich um Entschuldigung, denn hier geht es um Intel 600p.)
Mein 2. Lieblingsthema ist Datenschutz, aber weil Du's bist: Es geht um eine Toshi HG6 und ein Micron C400 und um ein Bord mit einem C600 Chipsatz mit Raid Erweiterung. Das Board hat 2 SATA3 Ports und 4 SATA2er am Raid-Controller. Und nun läuft dummer Weise kein ATAPI-Laufwerk sauber am Raid, also das DVD-Laufwerk, weshalb ich praktisch nur eine SATA3-SSD hatte. Nun habe ich das DVD-Laufwerk abgesteckt und die C400 an den Port - und am Ende habe ich verwundert festgestellt, dass es praktisch gar nichts gebracht hat. Meine Neugier ist befriedigt und damit kann ich sehr gut leben.
Also Leute, macht Euch nicht wegen albernen Benchmarkwerten verrückt und geht den breiten, standardisierten Alltagsweg, den die allermeisten User gehen. Damit sind die Geräte erprobt und wohl am zuverlässigsten. Zuverlässigkeit kommt bei mir zuerst.
(Und wieder bitte ich um Entschuldigung, denn hier geht es um Intel 600p.)
Gerk, vor allem alte ATAPI Laufwerke haben nun einmal oft Probleme mit dem AHCI Modus und wenn ein Intel SATA Host Controller im RAID Modus läuft, dann laufen die anderen Ports die nicht zum RAID gehören, nun einmal im AHCI Modus.
Bzgl. der Datensicherheit sind beide SSDs suboptimal, die C400 hat hoffentlich eine ausreichend aktuelle FW, die ist bei OEM SSDs wie es alle SSDs mit dem Micron Label sind, üblicherweise gar nicht einfach zu bekommen, aber ich meine es gibt von Micron ein öffentlich downloadbares FW-Update welches den 5184 Stunden Bug behebt, die C400 ist nämlich mit der Crucial m4 baugleich und hat daher auch die gleichen Probleme. Wenn die SSD dann plötzlich verschwindet weil noch keine FW mit dem Bugfix eingespielt ist, dann ist Datenkorruption nicht zu verhindern. Obendrein war die m4 immer reicht sensible auf unerwartete Spannungsabfälle, weshalb die Nachfolger mit Marvell Controllern dann auch Stützkondensatoren spendiert bekommen haben, auch wenn es nur die kleine Lösung für Data-at-rest war.
Die HG6 hat einen Pseudo-SLC Schreibmodus (der Reviewer spricht von einem adaptiven SLC-Schreibcache, aber ich bevorzuge das Wort Cache nur bei SSDs zu verwenden die dafür einen festen Bereich für das Pseudo-SLC verwenden (bisher waren das immer SSD mit TLC NAND) und sonst von einem Pseudo-SLC Schreibmodus zu reden, was für SSDs mit MLC NANDs typisch ist die Pseudo-SLC benutzen. Der Unterschied ist, dass bei so einem Pseudo-SLC Schreibmodus erst ein Bit in die freien NAND Pages geschrieben wird und dann erst später das zweite Bit, statt beide direkt hintereinander zu beschreiben. Danach werden die Daten dann noch mal umkopiert, was die Write Amplification erhöht, aber es erhöht auch das Risiko der Low-Page Corruption, etwas durch eine unerwarteten Spannungsabfall!
Die liegt daran, dass beim normalen Beschreiben der MLC NANDs, wenn als das erste Bit (die Low-Page) und gleich darauf das zweite Bit geschrieben wird, bei einem Spannungsabfall die Daten wahrscheinlich zu selben Datei gehören und dies vermutlich sowieso nicht zuende geschrieben wurde, weshalb das Journaling (auch NTFS hat sowas) dann dazu führt, dass diese Datei zwar verloren ist, aber mehr auch nicht, außer ggf. andere Dateien die auch gerade erst zusammen mit ihr geschrieben wurden. Wird aber ein Pseudo-SLC Schreibmodus verwendet, so wurden die Daten in die Low-Page lange vor dem zweiten Bit in diese Page geschrieben und fällt dabei die Spannung plötzlich ab, so werden Daten korrupt die zu einer Datei gehören die längst von Filesystem als sicher geschrieben wurden, schlimmstenfalls sogar Metadaten des Filesystems. Während im ersten Fall der Vorgang des Schreiben der Datei (ggf. der letzten Dateien) vom Journaling einfach "rückgängig" gemacht wird und das Filesystem wieder in den Zustand vor dem Schreibvorgang versetzt wird, geht das beim zweiten Fall nicht und daher erhöht sich das Risiko von Datenverlust durch solch einen Pseudo-SLC Schreibmodus höher.
Das macht so eine SSD nicht unsicher, aber Sicherheit ist immer relativ und fängt beim Schutz vor Datenkorruption bei ECC RAM und der passenden Plattform (CPU + MoBo) an und hört bei der passenden (Enterprise-)SSD noch nicht auf. Eine Samsung PM/SM863, Intel DC S3xxx oder von Micron eine mit DC am Ende, wäre die passendere Wahl gewesen.
Bzgl. der Datensicherheit sind beide SSDs suboptimal, die C400 hat hoffentlich eine ausreichend aktuelle FW, die ist bei OEM SSDs wie es alle SSDs mit dem Micron Label sind, üblicherweise gar nicht einfach zu bekommen, aber ich meine es gibt von Micron ein öffentlich downloadbares FW-Update welches den 5184 Stunden Bug behebt, die C400 ist nämlich mit der Crucial m4 baugleich und hat daher auch die gleichen Probleme. Wenn die SSD dann plötzlich verschwindet weil noch keine FW mit dem Bugfix eingespielt ist, dann ist Datenkorruption nicht zu verhindern. Obendrein war die m4 immer reicht sensible auf unerwartete Spannungsabfälle, weshalb die Nachfolger mit Marvell Controllern dann auch Stützkondensatoren spendiert bekommen haben, auch wenn es nur die kleine Lösung für Data-at-rest war.
Die HG6 hat einen Pseudo-SLC Schreibmodus (der Reviewer spricht von einem adaptiven SLC-Schreibcache, aber ich bevorzuge das Wort Cache nur bei SSDs zu verwenden die dafür einen festen Bereich für das Pseudo-SLC verwenden (bisher waren das immer SSD mit TLC NAND) und sonst von einem Pseudo-SLC Schreibmodus zu reden, was für SSDs mit MLC NANDs typisch ist die Pseudo-SLC benutzen. Der Unterschied ist, dass bei so einem Pseudo-SLC Schreibmodus erst ein Bit in die freien NAND Pages geschrieben wird und dann erst später das zweite Bit, statt beide direkt hintereinander zu beschreiben. Danach werden die Daten dann noch mal umkopiert, was die Write Amplification erhöht, aber es erhöht auch das Risiko der Low-Page Corruption, etwas durch eine unerwarteten Spannungsabfall!
Die liegt daran, dass beim normalen Beschreiben der MLC NANDs, wenn als das erste Bit (die Low-Page) und gleich darauf das zweite Bit geschrieben wird, bei einem Spannungsabfall die Daten wahrscheinlich zu selben Datei gehören und dies vermutlich sowieso nicht zuende geschrieben wurde, weshalb das Journaling (auch NTFS hat sowas) dann dazu führt, dass diese Datei zwar verloren ist, aber mehr auch nicht, außer ggf. andere Dateien die auch gerade erst zusammen mit ihr geschrieben wurden. Wird aber ein Pseudo-SLC Schreibmodus verwendet, so wurden die Daten in die Low-Page lange vor dem zweiten Bit in diese Page geschrieben und fällt dabei die Spannung plötzlich ab, so werden Daten korrupt die zu einer Datei gehören die längst von Filesystem als sicher geschrieben wurden, schlimmstenfalls sogar Metadaten des Filesystems. Während im ersten Fall der Vorgang des Schreiben der Datei (ggf. der letzten Dateien) vom Journaling einfach "rückgängig" gemacht wird und das Filesystem wieder in den Zustand vor dem Schreibvorgang versetzt wird, geht das beim zweiten Fall nicht und daher erhöht sich das Risiko von Datenverlust durch solch einen Pseudo-SLC Schreibmodus höher.
Das macht so eine SSD nicht unsicher, aber Sicherheit ist immer relativ und fängt beim Schutz vor Datenkorruption bei ECC RAM und der passenden Plattform (CPU + MoBo) an und hört bei der passenden (Enterprise-)SSD noch nicht auf. Eine Samsung PM/SM863, Intel DC S3xxx oder von Micron eine mit DC am Ende, wäre die passendere Wahl gewesen.
G
Gerk
Gast
OT
Bitte dort:
[Erfahrungsbericht] Ein paar Efahrungen mit (älteren) SSDs
https://www.computerbase.de/forum/t...ngen-mit-aelteren-ssds.1711794/#post-20463078
Bitte dort:
[Erfahrungsbericht] Ein paar Efahrungen mit (älteren) SSDs
https://www.computerbase.de/forum/t...ngen-mit-aelteren-ssds.1711794/#post-20463078
Sync-Faking, also so zu tun als wären die Daten aus dem Schreibcache schon aufs Medium geschrieben, auch wenn sie es gar nicht sind, ist eigentlich nur bei SSDs mit Full Power Loss Protection "erlaubt", so wie es bei prof. RAID Controllern nur mit BBU gemacht werden sollte. Nämlich wenn sichergestellt ist, dass die Daten auch bei einem unerwarteten Spannungsabfall nicht verloren gehen können. Trotzdem haben SSDs dies immer wieder getan ohne sicherstellen zu können, dass keine Daten aus dem Schreibcache bei einem unerwarteten Spannungsabfall verloren gehen können, z.B. die mit Sandforce Controllern. Man sieht es bei den SATA SSDs indem man den oberen Haken entfernt (beim Systemlaufwerk ist ein Neustart nötig!) und dann mit AS-SSD erneut bencht. Sind die Schreibraten, vor allem 4k Schreibend dann nicht massiv schlechter als mit dem oberen (oder beiden) Haken sondern immer noch bei einigen 10MB/s, so werden die Syncs gar nicht ausgeführt, sondern sofort bestätigt. Analog dazu sieht es mit dem FUA Befehlen bei NVMe SSDs aus.
Also entweder fakt die 600p nun mit der FW die Syncs, ignoriert also bei FUA Befehlen das diese erst quittiert werden dürfen wenn die Daten aus dem Schreibcache ins NAND geschrieben wurden oder Microsoft hat endlich das Verhalten des stornvme an das des storahci angegleichen.
Bartonius, dies könntest Du ja mal testen indem Du auch den oberen Haken entfernst, rebootestet und dann erneut mit dem AS-SSD bencht. Wenn die 4k Schreibend Werte praktisch unverändert bleiben, dann Fakt die 600p mit der FW sehr wahrscheinlich die Syncs, brechen sie ein auf einstellige MB/s Werte ein, so hat Microsoft den stornvme überarbeitet.
Also entweder fakt die 600p nun mit der FW die Syncs, ignoriert also bei FUA Befehlen das diese erst quittiert werden dürfen wenn die Daten aus dem Schreibcache ins NAND geschrieben wurden oder Microsoft hat endlich das Verhalten des stornvme an das des storahci angegleichen.
Bartonius, dies könntest Du ja mal testen indem Du auch den oberen Haken entfernst, rebootestet und dann erneut mit dem AS-SSD bencht. Wenn die 4k Schreibend Werte praktisch unverändert bleiben, dann Fakt die 600p mit der FW sehr wahrscheinlich die Syncs, brechen sie ein auf einstellige MB/s Werte ein, so hat Microsoft den stornvme überarbeitet.
