Test Patriot P210 SSD im Test: Der günstige Griff ins Ungewisse
- Ersteller MichaG
- Erstellt am
- Zum Test: Patriot P210 SSD im Test: Der günstige Griff ins Ungewisse
Dein beschriebener Failover hat nicht mit den zwei Slots zu tun. Schon seit Jahren wird bei allen Herstellern die FW nicht nur an einer Stelle in den Flash geschrieben sondern an mehreren, um genau dort eine Redundanz für Fehler zu haben. Mehrere FW Slots bei NVMe Devices kommt ursprünglich aus dem Enterprise Bereich und wird dort in verschiedenen Szenarien genutzt (Das wird auch der Grund sein warum Intel, welches ja Enterprise SSDs anbietet das in der FW drin hat. Die FW wird ja auch nicht für jede SSD komplett neu geschrieben). Dein Dual Bios Vergleich stimmt aber wohl in der Hinsicht, dass du natürlich zwei verschiedene Konfigurationen fahren kannst die man bei Bedarf umschaltet.GrumpyCat schrieb:
Das habe ich doch gar nicht geschrieben? Ich habe gesagt, dass nur weil sich SSDs in Features unterscheiden, man doch deshalb nicht automatisch sagen kann das eine ist besser als das andere. Das was du angedeutet hattest.GrumpyCat schrieb:
Interessant, NVMe als Protokoll gibts gerade mal knapp 9 Jahre oder willst du andeuten, dass SMART für ATA Devices und SMART bei NVMe das gleiche ist? Das ist nämlich mit nichten der Fall. Das SMART Log bei NVMe hat aber wohl das gleiche Grundproblem was schon das SMART bei ATA Devices hat - die Hersteller wollen sich nicht in die Karten blicken lassen und setzen auf herstellereigene Attribute (im Fall von ATA SMART) bzw. Custom Log Pages (im Fall von NVMe) für die wirklich technisch interessanten Werte, welche dann nur mit den herstellereigenen Tools komplett interpretiert werden können. Aber auch um Endkunden vor falschen Schlussforderungen zu schützen .GrumpyCat schrieb:
Einfach mal als Beispiel das NVMe Error Log. Die Anzahl an Error Log Entries wird im SMART Log festgehalten, aber mit den eigentlichen Error Log Entries kann ein Endkunde gar nichts anfangen. Die Command IDs kann man als technisch versierter User noch in der NVMe Spec nachgucken um zu sehen was für eine Art Kommando den Fehler ausgelöst hat, aber wenn man dann die Ursache wissen will, brauch man nen Trace der PCIe Kommunikation - es gibt keinen anderen Weg die Infos sonst komplett zu interpretieren. Und ne steigende Anzahl an Fehlern suggeriert doch erstmal ein Problem oder? Kann, muss aber nicht sein, wie z.B. im Fall das der Linux Treiber standardmäßig TCG bezogene Kommandos beim booten schickt und wenn die SSD das nicht unterstützt wird sofort ein Error Log Entry erzeugt obwohl mit dem Device alles in Ordnung ist. Einfach mal als Beispiel warum beim NVMe SMART Log das interpretieren genauso wenig einfach ist wie beim ATA SMART. Oder auch bei deiner Aussage zum Temperature Threshold:
Das sind die Schwellen ab denen das Device throttelt um nicht zu heiß zu werden - warum sollten da höhere Werte schlechter sein? Je höher diese sind, umso heißer darf das Gerät werden bevor es drosselt, es heißt nicht dass das Gerät heißer wird.GrumpyCat schrieb:
Die eigentliche Idee, festzuhalten welche Features ein Produkt beim Test hat, durch Präsentation von Device Capabilities und SMART Werte ist durchaus gut. Aber ich persönlich finde man sollte unbedingt darauf achten , dass man nicht zu Halbwissen einlädt, weil es eben nicht trivial ist die gezeigten Werte zu interpretieren.
Siehe als aktuelles Beispiel auch dieses Thema hier im Forum: https://www.computerbase.de/forum/threads/ssd-stribt-warum.1996088/
Dort wird einem User ein Tausch der SSD ans Herzen gelegt obwohl diese technisch einwandfrei ist... Verursacht durch Halbwissen wie SMART Werte zu interpretieren sind.
Firmware Slots: Ok! 
SMART-Werte an sich würden nichts zu einem Testartikel beitragen: sehe ich auch so.
Device Capabilities auflisten: fände ich gut, ggf. mit Erklärungen, dann erfüllt man auch einen Lehrauftrag.
Bei der ADATA SX6000, die ich hier hatte, habe ich übrigens in den Error Logs keine Fehler gesehen, sondern beim Auslesen der Logs ist ein Fehler aufgetreten, das hatte ich evtl. nicht genau formuliert. Wirklich großartige Firmware! Das Sahnehäubchen ist da noch, dass meine 6000 offensichtlich defekt ist (Lesezugriffe werden mit der Zeit immer langsamer; Daten, die seit ca. zwei Wochen auf dem Riegel sind, sind nur noch schlecht und mit Command Timeouts lesbar; nach noch mehr Zeit fällt das Gerät teilweise ganz beim Lesen aus und kommt selbst nach Soft Reboot nicht am Bus zurück; nach Erase macht die NVMe aber dann erstmal wieder einen guten Eindruck), aber das in den SMART/NVMe-Werten komplett unsichtbar ist. Großer Spaß, das Ding so als Garantiefall zurückzugeben. - Naja, ich hab den Thread jetzt glaube ich genug gekapert, bin auf den nächsten NVMe-Test gespannt und vielen Dank für den hier.
SMART-Werte an sich würden nichts zu einem Testartikel beitragen: sehe ich auch so.
Device Capabilities auflisten: fände ich gut, ggf. mit Erklärungen, dann erfüllt man auch einen Lehrauftrag
.Bei der ADATA SX6000, die ich hier hatte, habe ich übrigens in den Error Logs keine Fehler gesehen, sondern beim Auslesen der Logs ist ein Fehler aufgetreten, das hatte ich evtl. nicht genau formuliert. Wirklich großartige Firmware! Das Sahnehäubchen ist da noch, dass meine 6000 offensichtlich defekt ist (Lesezugriffe werden mit der Zeit immer langsamer; Daten, die seit ca. zwei Wochen auf dem Riegel sind, sind nur noch schlecht und mit Command Timeouts lesbar; nach noch mehr Zeit fällt das Gerät teilweise ganz beim Lesen aus und kommt selbst nach Soft Reboot nicht am Bus zurück; nach Erase macht die NVMe aber dann erstmal wieder einen guten Eindruck), aber das in den SMART/NVMe-Werten komplett unsichtbar ist. Großer Spaß, das Ding so als Garantiefall zurückzugeben. - Naja, ich hab den Thread jetzt glaube ich genug gekapert, bin auf den nächsten NVMe-Test gespannt und vielen Dank für den hier.
