MX100 schon defekt?

[Holt]

Skynet7, vorher sollte man aber mit FSUTIL behavior query disablelastaccess prüfen, ob es nicht schon so eingestellt ist, dann das macht Windows normalerweise per default. Außerdem wirkt die Einstellung nur auf die letzte Zugriffszeit und nicht auf die Zeit für das Erstellen und die letzte Änderung der Datei, es gibt ja bei NTFS mehrere Zeitstempel für die Dateien. Die ganze sogenannten "Optimierungen" sollte man lassen, das verschlimmbessert seid Win7 nur alles und Performance leidet, SSD muss man auch nicht schonen, die halt genug aus, meist viele Hundert TBW.

Demolition-Man das Tool zeit die Leserate der Dateien in Abhängigkeit ihres Alters an und wenn die MX100 so ein Problem wie die 840 Evo hätte, dann würde es die alten Dateien nicht mehr so schnell lesen wie die jüngeren, aber davon ist auf den Screenshot die hier gepostet wurden, nichts zu sehen.

 

[Skynet7]

Skynet7, vorher sollte man aber mit FSUTIL behavior query disablelastaccess prüfen, ob es nicht schon so eingestellt ist, dann das macht Windows normalerweise per default. Außerdem wirkt die Einstellung nur auf die letzte Zugriffszeit und nicht auf die Zeit für das Erstellen und die letzte Änderung der Datei, es gibt ja bei NTFS mehrere Zeitstempel für die Dateien. Die ganze sogenannten "Optimierungen" sollte man lassen, das verschlimmbessert seid Win7 nur alles und Performance leidet, SSD muss man auch nicht schonen, die halt genug aus, meist viele Hundert TBW.

Full Agree, es ging mir lediglich ums Benchen, denn das sollte noch mal je nach Controller etwas bringen wenn die SSD beim lesen nicht durch schreibzugriffe gestört wird. Praktisch für die die es an haben. Das mit den Optimierungen sehe ich anders, je nach OS kann man damit einiges herausholen. Alles von dem Artikel kann ich auch nicht empfehlen aber das meiste hat schon seine daseinsberechtigung.

 

[Holt]

Die "Optimierungen" aus diversen Anleitungen im Netz mögen in synthetischen Benchmarks teilweise Gewinne bringen, aber in der Praxis wird die SSD dadurch i.d.R. langsamer. Tomshardware hat das mal getestet und auch wenn die damals verwendeten SSD inzwischen veraltet sind, so stimmt das Ergebnis immer noch:





RAM ist eben noch immer schneller als eine SSD und wenn man unterbindet das Windows bestimmte Dateien ins sonst unbenutzte RAM lädt um diese bei Bedarf bereit zu halten, hat man Leistungseinbussen. Seid Win7 gibt es außer ggf. den Ruhzustand zu deaktivieren wenn man ihn nicht nutzt und vielleicht die Größe der Auslagerungsdatei auf 2GB fest einzustellen, nichts mehr zu optimieren. Man kann sich dann noch die Energiespareinstellungen ansehen, von Windows bis zu den C-States im BIOS (die zu deaktivieren bringt gerade bei den 4k Werte richtig was), aber das geht dann auch alles auf Kosten der Stromrechnung und Hitzeentwicklung, bewirkt also auch ggf. mehr Lärm der Lüfter. Da hat wohl jeder andere Preferenzen und eine pauschal als optimal anzusehende Einstellung wird man daher nicht finden können, nur den jeweils sinnvollsten Kompromiss zwischen Leistung und Leistungsaufnahme.

 

[Skynet7]

Das was die dort Tweaks nennen, nenn ich Pfusch! Geht doch schon los mit "Auslagerungsdatei Deaktivieren" was soll das? Linux ohne Swap kommt ja noch darauf klar, aber Windows, nein Danke. Den Rest hab ich mir garnicht erst zu gemüte geführt.

 

[Demolition-Man]

Puh war den ganzen Tag unterwegs.

Ich will natürlich nichts optimieren, was sich am Ende an schädlich erweist.

Wahrscheinlich habe ich nur ein wenig Panik geschoben, da ich dachte SSD`s würden konstanter arbeiten.

Hat auch was mit meiner ersten SSD`s zu tun. Eine ältere Sandisk 128GB. Das war das eine schlechte SSD am
schlechtesten Controller (AMD 770 Chipsatz).

Der Controller von meinem jetzigen Board ist besser, hat alleine bei meiner alten Datenplatte 25Mb/s mehr gebracht.

Benchmarks hin oder her, ich habe mir vielleicht schon wieder(!) mehr von ner SSD erhofft.

Man gewöhnt sich vielleicht zu schnell an eine SSD.

Ich messe aber gelegentlich weiter, es kann immer was sein. Sieht man ja an Samsungs 840er Evos.

Nur toll, dass meine SSD doch nicht schon nach anderthalb Monaten schlapp macht.

 

[Holt]

On SATA 3Gb/s oder SATA 6Gb/s macht bei einer HDD keine 25MB/s aus, da hast Du wohl falsch gemessen. Bei HDDs sind ja auf den äueren Zylindern etwa doppelt so viele Sektoren wie auf den inneren und daher sind die Transferraten dann auch außen entsprechend höher. Wenn die HDDs also nicht mit nur einer Partition über die ganze Kapazität versehen sind und diese nicht firsch formatiert wurden, dann kann man die Werte von Benchmarks die auch Filesystemen basierten (AS-SSD, CrystalDiskMark, ATTO) oder auch beim Kopieren realer Daten die Werte nicht vergleichen, das geht dann nur mit Low-Level Benchmarks wie HD Tune, da diese das Filesystem schlicht ignorieren.

Und ja die alten "namenlosen" SanDisk werden mit der Zeit immer langsamer, gerade wenn sie nicht getrimmt werden, was auch bei anderen altmodischen SSDs nicht ungewöhnlich war, etwa bei denen mit dem alten Phison 3105.

Übrigens hier mal ein Hinweis aus Anandtechs Review der Transcend 370:

Another intriguing feature is what Transcend calls StaticDataRefresh Technology. As the 840 EVO performance degradation bug taught us, the charge in cells degrades over time, which results in errors when the cell is read. ECC can fix a certain number of error bits, but if the limit is exceeded corrupted data will be sent to the host. The StaticDataRefresh technology monitors the error rates and when a preset threshold value is reached, the data will be rewritten to restore the correct cell charge level. I suspect all SSDs do this because it's vital to ensure the health of old data, but it's the first time I've seen it mentioned in a data sheet.

Schaut man sich die S.M.A.R.T. Werte z.B. einige alter SF SSDs an die gewaltige Erease Datenvolumen aufweisen, so könnte das damit zusammen hängen.

 

[Heen]

@Skynet7: Na ja, das einzige was man ihnen vorwerfen kann, dass erst die Anleitung zum deaktivieren gezeigt wird und dann im Nachhinein die Hinweise, welche Einschränkungen der Tipp mit sich zieht. Das Fazit jedenfalls ist diesbezüglich diplomatisch.

Ich habe Windows 7 seit Release und erst im Mai 2013 mit Wechsel zur größeren SSD erstmals die Auslagerungsdatei aktiviert. Die Abstürze, die ich hatte, waren in einem Fall auf defekte RAM-Riegel zurückzuführen, und im anderen auf instabile bzw. inkompatible Grafiktreiber.
Da gab es nur das Mehr an Speicher für mich, sonst keine Nachteile.

Die Trickserei am Rechner ist wie eine Pfanne auf dem Herd. Stell sie drauf, schalt den Herd ein. Doch wenn es stinkt, geh dich nicht duschen, erinnere dich an die Pfanne und guck erst in die Küche. Und daran hapert es oft.

 

[Hallo32]

File Bench: Was soll ich da benchen?

Ob das Alter der Dateien einen Einfluss auf die Leserate hat! Das ist ja das Problem der 840 (Evo) und wenn Du schon den Zuammenhang herstellen willst, dann solltest Du das auch prüfen, sonst ist das ganze nur dumme Polemik.

Darum ging es mir in diesen Fall nicht.

FileBench liest nur Sektoren, die belegt sind (es liest nur existierende Dateien) und somit in der FTL auf eine Flash Adresse gemappt sein müssen.

Wie die unbelegten Sektoren mit Bezug auf dem FTL behandelt werden, ist bei MX100 scheinbar nicht bekannt. Somit sollten diese unbelegten Sektoren beim Benchen ausgeschlossen werden, damit diese nicht das Ergebnis verfälschen. Dieses macht FileBench im Vergleich zu HD Tune und HD Tach und schließt somit eine mögliche Fehlerquelle aus.

 

[Holt]

Werden unbelegte Sektoren gelesen die gemappt sind, wird einfach 00 zurückgegeben, was man mit Trimcheck auch leicht prüfen bzw. sehen kann.

 

[Hallo32]

Werden unbelegte Sektoren gelesen die gemappt sind, wird einfach 00 zurückgegeben, was man mit Trimcheck auch leicht prüfen bzw. sehen kann.

Was gelesen wird, spielt eigentlich keine Rolle.
Die Frage ist nur, wie lange das Suchen in der FTL braucht. Wenn die Anzahl der Einträge in der FTL konstant ist, dann ist die benötigte Zeit zum Suchen ebenfalls konstant. Ist die Anzahl der Einträge nicht konstant, dann variiert auch die Zeit zum Suchen.

Die Frage ist nun, mappt die Crucial die leeren Sektoren in der FTL und benötigt somit eine konstante Zeit zum Suchen oder werden alle Sektoren die nicht in der FTL sind als 00 zurückgegeben und variiert die Zeit zum Suchen?

 

[Holt]

@Hallo32, lies man den Artikel von Anandtech zum Controller der Intel DC S3700 durch, dann solltest Du eine realtiv gut Abschätzung machen können, wie sie Antwort lauten dürfte, spätestens wenn Du Dir das Verhältnis der Cachegröße zur Kapazität bei der SSDs ansiehst.

The downside to all of this is the DRAM area required by the new flat indirection table. The old binary tree was very space efficient, while the new array is just huge. It requires a large amount of DRAM depending on the capacity of the drive. In its largest implementation (800GB), Intel needs a full 1GB of DRAM to store the indirection table. By my calculations, the table itself should require roughly 100MB of DRAM per 100GB of storage space on the drive itself.

Über die Größe des Caches schweigt sich Crucial bei der MX100 aus und ich finde nur Review der 512GB die 512MB Cache hat, bei der praktisch baugleichen m550 gibt Anandtech 512MB für alle bis 512GB und 1GB RAM für die 1TB an, es wäre demnach also gerade so genug Platz im Cache für eine falche indirection table vorhanden, sollte die Schätzung mit 1MB RAM pro GB Nutzkapazität hinkommen. Die Intel 730 480GB hat aber 1GB Cache "two 512MB DDR3-1600 packages", die hat ja den gleichen Controller wie die DC S3700. Anandtechs Schätzung dürfte also noch zu gering gewesen sein und wenn ich mir das Abscheinden er Crucial bei Anandtechs Performance Consistancy Tests ansehe, dann würde ich bei den Crucial nicht auf eine flache Tabelle tippen, aber letzlich wissen wird es nur Crucial selbst und die meisten Hersteller dürfte bei dem Thema auch weniger offen als Intel sein.

 

[Hallo32]

@Holt

Wie die Map implementiert ist, spielt in den aktuellen Fall doch keine Rolle. Es wird nur eine SSD betrachtet und diese wird während der Laufzeit den Aufbau der Map wohl nicht ändern.

 

[Holt]

Wie die Map implementiert ist, spielt in den aktuellen Fall doch keine Rolle.

Wieso das plötzlich nicht?

Die Frage ist nur, wie lange das Suchen in der FTL braucht. Wenn die Anzahl der Einträge in der FTL konstant ist, dann ist die benötigte Zeit zum Suchen ebenfalls konstant.
..
Die Frage ist nun, mappt die Crucial die leeren Sektoren in der FTL

LBAs ohne gültige Daten zu mappen (dann auf den Hinweis das es dafür keine Daten gibt) würde nur bei flachen Tabelle Sinn machen, da werden ja dann die Daten aller LBAs an einer festen Position stehen und man greift da einfach rein (bzw. es nicht einzelne LBAs gemappt, sondern wohl jeder achte wegen der Optimierung auf 4k Zugriffe) und damit macht es keinen Sinn die nicht belegten raus zu nehmen, jeder hat ja eine feste Position.

Bei einer Baumstruktur werden die gelöschten dann wieder entfernt, das macht ja keinen Sinn diese länger zu halten. Das müsste man aber messen können, indem man statt eines Secure Erease (dabei wird ja wohl der ganze Baum gelöscht) einfach alle LBAs trimmt und dann die Zugriffszeit erneut bencht. Man müsste mal eine neue SSD benchen, z.B. mit h2testw fast komplett füllen, erneut benchen und dann die h2testw Dateien löschen (TRIM muss funktionieren), etwas warten und erneut benchen. Beim zeiten Bench wäre die Zugriffszeit lesend sicher höher und wenn sie beim dritten Bench auch noch so hoch ist, dann werden wohl auch die Baumeinträge wohl gelöscht. Bei einer Intel DC S3x00 oder 730 sollten die Zeiten dagegen etwa gleich bleiben.

Eine andere Ursache könnte aber auch bei AS-SSD liegen, denn das ist ja ein Filesystembasierter Benchmark und nur beim Messen der Zugriffszeit lesend wird auf das Physikalische Laufwerk zugegriffen, also Low-Level gebencht. Was wenn dabei beliebige LBAs gelesen werden in denen gar nichts steht? Um das zu vermeiden müsste ja eine Datei angelegt und ermittelt werden welche LBAs diese belegt und nur diese könnten dann gelesen werden oder schaut sich die gesamte Belegung an, aber das dauert bei vollen SSDs länger als AS-SSD braucht um den Test zu starten, wird also wohl sicher nicht gemacht.

Deshalb dürfte AS-SSD bei der Ermittlung der Zugriffszeit vermutlich am Ende den gleichen Fehler machen den auch Low-Level Bechmarks die ja beim Lesen nicht gemappter LBAs sehr hohe Leseraten anzeigen, wie bei diesem Test einer Intel X-25V bei awardfabrik.de schön zu sehen ist:

bzw.

Die getestete SSD kann gar keine 200MB/s oder gar mehr lesen, die Kurven zeigen nur da die reale Geschwindigkeit halbwegs richtig an, wo der Speicher auch wirklich belegt ist. So schnell kann die lesen, wenn man auch wirklich Daten zum Lesen hineingeschrieben hat, die hat ja nur 5 Kanäle des Controllers mit NAND belegt:

Wegen der in der Standardeinstellung nur 64k kurzen Zugriffe bei HD Tune zeigt das nur so 150MB/s wo etwas belegt ist, man sieht schon daran wie ungeeignet HD Tune für SSDs ist.

Zwischen den beiden Benches von HD Tune und HD Tach wurde auch zwischen 20GB und 24GB noch etwas geschrieben, da ist dieLesengeschwindigkeit nun geringer, da muss ja nun wirklich etwas aus den NAND gelesen werden. Hätte man nun vorher und nachher einfach beliebe LBAs gelesen, so wäre der Mittelwert schon deshalb schlechter, weil beim zweiten mal in 10% der Fälle nun reale Daten ausgelesen werden müssen (eben in Bereich zwischen 20 und 24GB) wo das vorher weder nötig und noch möglich war.

Von daher kann man ohne den Quellcode oder wenigstens die Funktionsweise von AS-SSD beim Ermitteln der Zugriffszeit lesend zu kennen, nicht ausschliessen das der ganze Test schlicht falsch funktioniert und die Unterschiede in der Zugriffszeit nur daher kommen, dass bei leeren SSDs dabei fast nur LBAs gelesen werden, die nicht belegt sind und bei vollen dann eben fast nur wirklich belegte LBAs und der Unterschied alleine daher stammt.