News Aktualisierte SSD-Firmware für Crucial M4

070H ? die m4 läuft und läuft, das sollte sie doch, täglich 4-5 Stunden in Betrieb , keine Bluscreens, keine Aufhänger, keine "Laufwerk wird nicht gefunden" Probleme, keine CRC Fehler, keine defekten Sektoren keine E/A Errors. Was ausgelassen ? ;)

IRRTUM ! Ich hatte noch die 0309 drauf, allerdings hab ich zurückgflasht von 070H, eigentlich...normal kann ichs nicht lassen eine Firmware zu testen.

Hiern paar Shots, sieht durchschnittlich aus, hm, doch diverse Fehler , aber ob die SO gravierend sind ?
hm , 4% Lebendauer sind hin bei ca. 8000h Crystal "sagt" gut.

Der Benchmakr war auf SATA II Intel, hab sonst nix frei.
 
Zuletzt bearbeitet von einem Moderator:
Auf meiner M4 ist ebenfalls die 070H und läuft ohne Probleme.

@emeraldmine

Man kann die SN auch über eine Option in CDI ausblenden.
 
emeraldmine schrieb:
070H ? die m4 läuft und läuft, das sollte sie doch, täglich 4-5 Stunden in Betrieb , keine Bluscreens, keine Aufhänger, keine "Laufwerk wird nicht gefunden" Probleme, keine CRC Fehler, keine defekten Sektoren keine E/A Errors. Was ausgelassen ? ;)

Bis auf Deinen Irrtum mit der Versionsnummer kann ich zumindest einen problemlosen Betrieb mit der 070H bestätigen und das nach dem dritten Umzug der M4. Zuerst war sie an nem P8Z77 Asus am werkeln, dann hab ich sie in mein 8 Jahre altes Toshi NB noch mit SATA 3G verfrachtet und vor kurzem durfte sie wieder in mein neues Asus NB umziehen. Das Ding läuft noch fehlerfrei, auch mit der 070H und hat dem NB quasi Flügel verliehen, im Gegensatz zu der verbauten HDD. Wenn sie morgen stirbt, egal, ich mache regelmäßige Backups. Dieser ganze synthetische Benchmark Mist geht aber auch auf den Keks, man kann sich auch verrückt machen. Entscheidend ist, wie die Kiste sich anfühlt beim arbeiten.
 
emeraldmine schrieb:
keine CRC Fehler, keine defekten Sektoren keine E/A Errors. Was ausgelassen ? ;)
Die Ultra-DMA CRC Fehler kommen eigentlich immer vom SATA Kabel, das ist kein Fehler der SSD selbst, außer die Platine oder der SATA Stecker haben einen Schaden. Deine hat aber schon ein paar Wiederzuweisungen, was aber kein Problem ist und auch aufgrund der unerwarteten Stromausfälle passieren kann, wenn dabei gerade ein Block gelöscht wird.
 
Sind die irgendwie reparabel , oder sind entgülig ausgetausch und zugewiesen ? Low-Level usw. ;) ? Könnte mans damit nochmal "berichtigen" !?

Die Absicht ist NICHT das Ding zu verkloppen : D , die behalte doch gerne selbst dann.
 
Normalerweise verwenden die Controller das ganze NANDs ständig und ein Teil davon wird nun eben nicht mehr verwendet, aber das macht nichts. Damit hat der Controller ein paar MB weniger Free Area, aber er hat selbst bei einer 64GB SSD immer noch einige GB davon.
 
GigaBytes , so viel, wußte ich gar noch nicht. Dann ists ja so i.O. wenn ein Sektor nur 4Kbyte hat. Oder ist das schon ein Cluster ? Ich wußte das mal, zuletzt im vorigen Jahrtausend benützt . :D
 
Zuletzt bearbeitet von einem Moderator:
Deine m4 64GB hat 64GiB NAND Kapazität (eigentlich sogar noch mehr, weil jede Page und auch noch jeder Block noch extra Byte enthalten), was 64*1024³ Bytes = 68.719.476.736 Bytes entspricht. Nutzen kannst Du aber nur etwa 64*1000³ Bytes = 64.000.000.000 Bytes. Damit sind etwa 7% mehr NAND als Nutzkapazität vorhanden und die teilen sich die FW, Verwaltungsdaten und eben die Free Area, aus der sich auch die Reservesektoren speisen.

Bei Deiner sind 0x26800 = 157696 Sektoren ausgetauscht, was bei einer SSD ausrangiert meint, worden. Ein Sektor in den S.M.A.R.T. Werten bezieht sich normalerweise immer auf die Größe eines LBAs, also eigentlich immer auf 512 Byte. Somit sind 80740352 Bytes nicht mehr Nutzbar, also 77MiB von den über 4GB. Die Zahl ist so hoch, weil SSD immer ganze Blöcke ausrangieren, was eben 0x4D = 77 mal passiert ist (Rohwert von C4) und damit ist klar, dass jedes mal ein Block ausrangiert wurde, denn die sind bei der SSD genau 1MiB groß.
 
Ich hab noch mal meine S-ATA Treiber aktualisiert und das OC optimiert - zumindest vom Score her scheint sie gut zu laufen. Bin zufrieden.

as-ssd-bench M4-CT128 M4SSD2  05.08.2014 17-45-35.png
 
Sieht auch gut aus und wenn man beim OC den CPU Takt festsetzt und die C-States deaktiviert, dann bringt das auch vor allem bei den 4k Werten ordentlich was.
 
Wie alltagstauglich solche Einstellungen sind, steht natürlich auf einem anderen Blatt, aber man bekommt damit eben die Highscores im Benchmark.
 
Hab gerade mal den Benchmark von letztem Jahr wiederholt (allerdings mit neuerer AS SSD-Version) und war überrascht, dass meine Werte trotz sonst identischer Hardware doch relativ stark abgesunken sind. Ist das normal?
 

Anhänge

  • as-ssd-bench M4-CT128M4SSD2 A 26.07.2015 09-16-19.png
    as-ssd-bench M4-CT128M4SSD2 A 26.07.2015 09-16-19.png
    33,3 KB · Aufrufe: 571
Dr.Death, bei Dir ist auch die seq. Schreibrate sehr gering, das hatten wir ja auch schon bei den Fällen weiter oben. Die 4k_64 lesend sind aber noch noch, die scheint noch bei 100% Restleben zu stehen, denn normalerweise fallen die auf den Wert von etwa 120MB/s wie bei Mr. Incredible zu sehen. Vielleicht ist bei das Filesystem auch nur sehr voll und stark fragmenitiert, denn wird ja weniger seq. Geschrieben, sondern die Testdatei muss in viele kleinen Lücken mit einer Menge Randomzugriffen verteilt werden. Wenn das System länger nicht neu aufgesetzt wurde, wäre das nicht ganz unwahrscheinlich, Du kannst ja mal mit MyDefrag eine Analyse vornehmen, da sieht man unter View->Statistic am Ende auch wie große die Lücken (Durchschnitt und Median) sind und wie groß die größte Lücke ist.
 
Trim hat aber nichts mit Defragmentierung zutun. Ein Laufwerk ist dann fragmentiert, wenn zwar genug Platz frei ist, dieser Platz aber nicht zusammenhängend ist. Das kommt bei normaler Nutzung von selbst zustande, gerade bei Systemlaufwerken, man löscht Daten ja normaler Weise nicht in der Reihenfolge, wie sie entstanden sind. Bei einer SSD ist das nicht so tragisch wie bei eine HDD, denn die SSD kann viel schneller die erste Hälfte einer Datei in eine Lücke rein schreiben und dann bei der nächsten freien Stelle weiter schreiben, als es eine HDD könnte.
Das und weil die Schreibzyklen bei einer SSD endlich sind ist der Grund, warum eine SSD in der Regel nicht defragmentiert wird. Trim teilt dem Controller der SSD nur mit, dass bestimmte Bereiche auf der SSD wieder zur Beschreibung zur Verfügung stehen, der Controller markiert sie sozusagen als frei und damit geht das Wiederbeschreiben dann schneller, da gleich bekannt ist, wo etwas frei ist. Das ändert aber nichts an der Fragmentierung, da diese durch bestehende Daten ausgelöst wird, also durch Datenblöcke, die nicht wieder neu beschrieben werden können/sollen.
Solche Testprogramme schreiben in der Regel einen großen, zusammenhängenden Block, kriegt die SSD aufgrund der Fragmentierung diesen nicht am Stück unter, muss natürlich zwischendurch auf andere, freie Speicherzellen zurück gegriffen werden. Das kostet natürlich insgesamt etwas Performance, dürfte sich bei den Datengrößen, die im Alltag und vor allem auf einem Systemlaufwerk geschrieben werden, aber relativ wenig auswirken.

Lasse mich gerne berichtigen, falls ich irgendwo daneben liege.
 
Eben, Fragmentierung ist eine Sache des Filesysstems und hat mit dem darunter liegenden Medium auch gar nichts zu tun, das hat Einfluss darauf wie stark sich die Fragmentierung auf die Performance auswirkt. Zunächst mal folgendes, was viele oder alle nicht zu wissen scheinen die sich gegen eine Defragmentierung von SSD aussprechen, weil es nichts bringen würden und die SSDs ja die Daten intern sowieso anders anordnen und quer über die NANDs verteilen, als es von außen scheint:

Weder SSDs noch HDDs kennen Partitionen, Filesystem, Dateien, Verzeichnisse oder auch eine Fragmentierung! Das alles sind Geschichten die auf einer logischen Ebene darüber passieren, nämlich im Betriebssystem und dessen Routinen zu Verwaltung der Datenträger, zu denen auch das Filesystem gehört, denn ein Filesystem ist mehr als seine Datenstrukturen auf dem Datenträger, es gehört auch eine Menge Software dazu!

HDDs wie SSDs stellen nur eine Menge LBAs zu Verfügung, die i.d.R. je 512 Byte verwalten und es werden dann ATA Befehle benutzt, die fast immer einen LBA X und Y folgende LBAs auslesen oder beschreiben. Bestimmte Daten an bestimmten Adressen werden dann vom Betriebssystem eben entsprechend interpretiert, die selben Bytes am Anfang im MBR die Partitionstabelle ausmachen, könne an anderer Stelle die Pixel in einem Bild darstellen, das weiß weder eine HDD noch eine SSD. Es stimmt das die Controller von SSDs die Daten quer über die NANDs verteilen, aber das hat einen Sinn, denn so können bei langen Zugriffen wegen der internen Parallelität die sequentiellen Transferraten gesteigert werden, aber die maximalen Transferraten erreichen SSDs eben erst, wenn die Zugriffe auf über viele aufeinanderfolgende LBAs erfolgen und ein ATA EXT Befehl kann bis zu 2^16 LBAs adressieren denn es ja wird nicht LBA für LBA gelesen, was bei 512 Byte pro LBA dann 32MiB sind. Moderne SATA SSDs erreichen oft erst bei Zugriffe von 512 Kilobyte ihre vollen Transferraten und PCIe SSDs brauchen dafür sogar noch längere Transfers. Im IDE Modus werden nur ATA Befehle unterstützt, die maximal 2^8 LBAs adressieren können, also 128k, was nicht reicht und daher haben die SSDs im IDE Modus dann auch immer deutlich geringere sequentielle Transferraten, meist knapp über 300MB/s.

Was hat das nun mit der Fragmentierung zu tun? Filesysteme bemühen sich die Dateien in einem Fragment abzulegen, also die Dateien ab einem bestimmten LBA (bzw. Cluster, aber das ist für das Thema egal, denn ein Cluster lässt sich nach der Formel "Offset der Partition + Clusternummer * LBAs pro Cluster" fix in LBAs umrechnen und das muss das Betriebssystem auch machen, da die Platten eben nur LBAs und keine Cluster verwalten) und dann auf allen folgenden zu legen. Nur wachsen eben Dateien wie Logdateien oder auch der Aufsatz über Fragmentierung an dem man scheibt und der immer länger wird während er zwischendurch immer mal gespeichert wird oder es gibt keine Lücke im Filesystem um die Datei aufzunehmen. Lücken im Filesystem sind Bereiche von LBAs die nicht von Dateien belegt sind, wo also neue Dateien abgelegt werden können.

Ist es nun nicht möglich eine Datei in einem zusammenhängenden LBA Bereich zu speichern, spricht man von Fragmentierung, weil Dateien dann eben nicht mehr nur in einem Fragment abgelegt sind, Fragmentierung betrifft also auch immer nur einzelne Dateien, mal mehr mal weniger auf einer Partition, denn es ist ein Problem des jeweiligen Filesystems und nicht das muss nicht mit der Platte identisch sein, es kann über mehrere Platte gehen so wie eine Platte mehrere Partitionen und damit Filesystem haben kann, aber wie gesagt ist dass nur eine logische Aufteilung des Betriebssystems und der Controller der Platte, egal ob SSD oder HDD, weiß nichts davon.

Was passiert nun wenn eine Datei fragmentiert ist? Nun ein Befehl kann bis zu 32MiB adressieren und ab etwa 512k erreichen moderne SSDs ihre volle Performance. Bei 4k (8 LBAs) sind es viel weniger (ein Blich auf die 4k Ergebnisse von AS-SSD oder CrystalDiskMark zeigt das auch deutlich), 4k sind die kleinste Clustergröße bei den meisten aktuellen Filesystemen, ein Cluster ist auch die kleinste mögliche Größe eines Fragments. Nun liest ein Betriebssystem beim Lesen einer Datei mit einem Befehl immer nur bis zur Grenze eines Fragmentes und dann mit einem weiteren Befehl ab dem Anfang des nächsten Fragmentes bis zur Länge des Puffers oder bis zum Ende des Fragmentes.

Dann müssen bei einer HDD die Köpfe an die neue Position fahren, wo das nächste Fragment anfängt und fast alle die über Fragmentierung fahren, was länger dauert und das ist der einzige Aspekt an fast alle bei Fragmentierung denken. Das hört man oft auch, das dauert, da spürt man die Fragmentierung. Das ist aber nicht die Fragmentierung, es ist nur ein Ergebnis der Fragmentierung und das fällt bei SSD in der Tat weg, da diese sehr kurze Zugriffszeiten haben, aber deswegen bleiben sie von Fragmentierung nicht unberührt, denn durch die Fragmentierung werden mehr Zugriffe nötig und die Länge der Zugriffe, also wie viele LBAs mit einem Befehl adressiert werden, wird dadurch kürzer und das beeinflusst eben auch bei SSD die Performance, wenn auch längst nicht so massiv wie bei HDD!

Um die Einflüsse von Fragmentierung besser zu zeigen, sollte man sich einen Extremfall ansehen, den kann man auch mit etwas Programmiererkenntnissen leicht nachstellen: Man erstellt eine Partition, formatiert sie mit 4k pro Zuordnungseinheit (Cluster), bencht mit AS-SSD, formatiert noch mal und beschreibt diese Partition mit 4k großen, durchnummerierten Dateien. Dann löscht man z.B. alle Dateien mit gerader Endziffer (oder alle mit einer 0 hinten, das verschärft den Test noch, da moderne NAND durchaus 16k Pagesize haben) und bencht erneut. Man darf dann auch der SSD Zeit für die Idle CG lassen und nochmal benchen, damit die Effekte der internen Datenorganisation keine Rolle spielen. Die sequentiellen Transferraten (vor allem Lesend) werden schlechter sein, mindestens um 100MB/s bei SATA SSDs im AHCI Modus und bei einer schnellen PCIe SSD wie der SM951 oder im IDE Modus noch viel deutlicher!

Was passiert bei dem Test? Nun statt weniger Zugriffe mit 1MB (oder weniger, je nachdem was der Treiber darauf macht) werden viele Zugriffe mit 4k erfolgen und selbst wenn diese parallel erfolgen, sind die Transferraten deutlich geringer, schon weil mehr Overhead nötig ist. Die Befehle und Bestätigungen etc. müssen ja auch über den SATA Kanal mit seinen maximal 600MB/s und pro FIS (Übertragungspaket, je mit Overhead wie z.B. eigner CRC) werden maximal 8k übertragen und bei nur 4k pro Befehl gehen eben auch über SATA 6Gb/s maximal so 400MB/s.

Fragmentierung hat also auch auf SSDs einen Einfluss, weil es die Art und Länge der Zugriffe ändert, nicht aber den Effekt wie bei HDDs, weil eben die Zugriffszeiten von SSDs kürzer sind. Wenn ein Treiber sowieso nur 1MiB pro Zugriff liest und alle Fragmente genau ein MiB groß sind, wird es keinen Einfluss auf die Performance einer SSD haben, ist aber jedes Fragment nun genau 1028k lang, so wird für jede Fragment neben dem 1024k langen Zugriff noch ein weiterer mit nur 4k nötig und damit fällt die Performance.

Defragmentieren schaden SSDs auch nicht wirklich, sie wissen ja auch nicht was es ist. Für den Controller der SSD sind es Lese- und Schreibvorgänge wie alle anderen Lese- und Schreibvorgänge auch und die bewirken einen bestimmten Verschleiß also Verbraucht von P/E Zyklen der NANDs, aber ordentliche SSD mit NANDs in normalen Qualitätsstufen wie sie für SSDs gedacht sind, können so viele P/E Zyklen vertragen, da macht das keinen Unterscheid. In allen Endurancetests haben die SSDs viele Hundert TB bis einige PB ausgehalten, ein normaler Heimanwender schreibt kaum 10TB im Jahre, nur wenige schaffen mehr und die werden sich meist auch regelmäßig die neuste, größte, schnellste SSD kaufen. Außerdem ist der Effekt von Fragmentierung bei SSDs eben viel geringer als bei HDDs die muss man bei weitem nicht so oft defragmentieren wie HDDs.

Böse Schatten oder hat die Defragmentierung keinerlei Nachteile außer ein wenig Verschleiß? Doch, es gibt noch einen Aspekt, das Schattenfilesystem, welches viele SSD Controller führen. Die kennen ja nun einmal keine Dateien und verteilen die Daten so über die NANDs, dass diese möglichst schnell geschrieben und gelesen werden können. Daher können sie das nur aufgrund der Lese- und Schreibbefehle entscheiden, welche Daten zusammengehören und das bezeichnet man als Schattenfilesystem. Werden beim Defragmentieren nun stark fragmentierte Dateien aus vielen kleinen Bereichen auf einen zusammenhängenden Bereich von LBAs kopiert, so kann der Controller der SSD dies eben nicht als eine zusammenhängende Datei erkennen und legt diese Daten so ab, als wenn es einzelne kleine Dateien werden, er rechnet also nicht damit, dass dieser neu geschaffene Bereich dann später zusammenhängend gelesen werden wird. Deshalb funktionieren ja auch Low-Level Benchmarks wie HD Tune bei SSDs nicht korrekt. Außerdem liest HD Tune in der Standardeinstellung auch nur alle paar MB mal 64k, was eben nicht reicht um bei SSDs die maximalen sequentiellen Leseraten zu erzielen.
 
Danke dafür, wahnsinnig interessant, das so zu lesen.
Was heißt das jetzt aber für mich mit einer SSD, die schon ziemlich im Einsatz ist? Macht es Sinn, hin und wieder mal zu defragen, oder wird das ganze durch das Schattenfilesystem im Endeffekt langsamer?

Meine M4 mit 64 GB erreicht nur zwischen 50 und 60 MB/s sequenzielle Schreibrate.
 
Welche Windows hast Du? Bei Windows 8 gibt es so ein light-defrag wenn volume snapshots aktiv sind, was z.B. dann der Fall ist wenn die Systemwiederherstellung aktiviert ist. Das log kann man in einer Powershell mit folgender Abfrage ansehen:

get-eventLog -logname application -source "microsoft-windows-defrag" | sort timegenerated -desc | fl timegenerated, message

Bei mir steht z.B.:
Code:
TimeGenerated : 22.07.2015 16:44:35
Message       : The storage optimizer successfully completed retrim on (C:)

TimeGenerated : 22.07.2015 16:44:35
Message       : The storage optimizer successfully completed defragmentation on (C:)
Das fügt aber die Lücken im Filesystem, also die unbelegten Cluster, nicht wieder zusammen, was man auch bei einer Analyse mit MyDefrag sehen kann, einmal auf dem Screenshot und dann unter View->Statitics sehen kann, da kommt bei mir raus:

MyDefrag_Analyse_C_Stat.png

Es soll nur verhindern, dass eine Datei das Limit "maximum file fragmentation" erreicht und wie man sieht gibt es bei mit massenhaft Lücken (gaps) und das Median gab ist nur 12k, also 3 Cluster klein. Außerdem gehören 75% der belegten Bytes zu fragmentierten Dateien und so viel hat sich seid dem 22. dann da auch nicht geändert. Das ist also keine klassische Defragmentierung bei der alle Dateien zusammengeführt und z.B. alphabetisch nach Ordnern sortiert angeordnet werden, es dürfte nur dazu dienen zu viele zu kleine Fragmente zu verhindern und dabei versuchen möglichst wenig zu bewegen.

Das reicht für bestehende Dateien auch vollkommen aus, aber schau Dir die Lücken bei mit an, die größte hat 1,77GB, aber wenn diese z.B. im für den MFT reservierten Bereich liegt, würde Windows so lange wie möglich vermeiden diese mit normalen Dateien zu belegen, die durchschnittliche Größe ist 19MB, die 1GB Testdatein von AS-SSD dürfte dann also in mehrere Fragmenten abgespeichert werden. Kommen noch vorher ein paar andere Dateien hinzu die die großen Lücken füllen, wären es noch mehr und irgendwann kann man dann nicht mehr von einer Messung der sequentiellen Transferraten reden.

Man kann das ja auch selbst testen, eine einfach Cmd.exe "Als Administator" und den AS-SSD starten, dann während der Test der seq. Leserate läuft contig -a c:\AS-SSD-TEST42\test.bin ausführen, das sollte man aber vorher schon eingegeben und einmal ausgeführt haben, denn man muss schnell sein und beim ersten Start gibt es einen Hinweis wegen der License.

Bei mir kommt raus:
Code:
C:\>contig -a c:\AS-SSD-TEST42\test.bin

Contig v1.55 - Makes files contiguous
Copyright (C) 1998-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\AS-SSD-TEST42\test.bin is in 13 fragments

Summary:
     Number of files processed   : 1
     Average fragmentation       : 13 frags/file

Wenn es das nicht ist, so gibt es im Sammelthread ja auch gerade einige bei denen bei der seq. Schreibrate einige MB/s fehlen, keine Ahnung was da für eine SW ggf. reinfunkt die offenbar selbst im Abgesicherten Modus aktiv ist oder ob MS oder ein (anderer) Hersteller z.B. eines Antivirenprogramms bei den letzten Updates was gemacht hat.
 
Zurück
Oben