AS SSD Benchmark [3]

[Holt]

Wenn das Cache RAM defekt wäre, würde sie gar nicht laufen, da liegt ein Problem bei der Einstellung vor, denn die Nutzung des Schreibcaches wurde deaktiviert. Meist ist das bei Windows direkt, vielleicht ist es eine Einstellung des Treibers oder BIOS, die X79er ist ja eigentlich eine Enterpriseplattform und da ist dies nicht so selten, weil es die Datensicherheit bei plötzlichen Stromausfällen erhöht und richtige Storages sowieso über RAID Controller realisiert werden, die dann eine BBU haben und damit solche Einstellungen ignorieren, weil sie ja keine Daten verlieren würden, wenn der Strom plötzlich ausfällt.

 

[Juli112]

Okay es lag an dem Intel RSTe AHCI Treiber. Habe diesen durch den Microsoft Treiber ersetzt und kriege wieder 70MB/s 4K write.
Trotzdem vielen Dank für die Hilfe!

 

[Ralle86]

Hallo zusammen,

ich hab da mal ne kleine Frage. Ob es ein Problem ist, kann ich nicht genau sagen, vielleicht aber ihr

Und zwar ist im AS SSD Bench die Zugriffszeit beim Lesen bei meinen beiden SSDs höher, als sie beim Kauf war. Ob das normal ist oder an Windows liegt kann ich nicht sagen, hier hoffe ich auf eure Unterstützung. Außerdem erreicht meine Samsung SSD 830 im sequentiellen Schreiben deutlich weniger als die angegebenen 300 MB/s.

Samsung SSD 830 128GB:
18.11.2015: 19.05.2014:

Crucial M500 480GB:
18.11.2015: 17.05.2014 (neu):

Mit der Crucial bin ich bis auf den Unterschied in der Zugriffszeit beim Lesen zufrieden. Bei der Samsung bin ich mir bei der Zugriffszeit und der Schreibrate nicht sicher. Ich hoffe ihr könnt mir die Fragen beantworten. Danke schonmal.

Hier sind noch die CDI Screens:

Samsung: Crucial:

 

[Holt]

Vergiss die Zugriffszeit lesend, dass ist ein Bug im AS-SSD, siehe #1968 ff.:

Wird eigentlich bei der Ermittlung der Zugriffszeit Lesend darauf geachtet, dass die gelesenen LBAs überhaupt belegt sind? Wenn ich die Werte bei leeren und fast komplett vollen SSDs sehen und diese mit den 4k Lesend vergleiche, dann scheint mir das eher nicht der Fall zu sein, da die Zugriffszeit lesend extrem viel höher ist und die 4k Lesend praktisch gleich bleibt. Wenn man LBAs liest die nicht belegte (nie beschrieben oder wieder getrimmt) sind, dann liest der Controller nichts aus dem NAND, aus welche NAND Adresse auch? Dann gibt der Controller gewöhnlich einfach 00 zurück und das geht halt deutlich schneller als wirklich Daten zu lesen.

Wenn das nicht berücksichtigt ist, rüste das nach oder besser noch: Entferne diese Messung der Zugriffszeiten ganz, denn die aktuellen SSDs sind nicht mehr auf Performance bei 512 Byte Zugriffen ausgelegt, sondern auf 4k Zugriffe bei korrektem Alignment.

Nö. Es wird nicht geprüft ob der Sektor auch belegt ist. Und es soll die mittlere Antwortszeit des Controllers gemessen werden. 512 Bytes ist nur als kleinste ansprechbare Größe gewählt.

Das habe ich mir gedacht, deshalb ist der Wert aber leider total wertlos, weil eben die Reaktionszeit sehr davon abhängt ob der gelesene LBA nun wirklich auf eine Flashadresse gemappt ist und wirklich etwas aus dem NAND gelesen werden muss oder nicht. Das ist natürlich umso häufiger der Fall je voller die SSD ist. Die wirkliche Antwortzeit kann man so auch nicht ernsthaft ermitteln.

 

[Ralle86]

Alles klar. Danke dir. Und wie ist das mit der sequientiellen Schreibrate der Samsung SSD? Liegt das daran, dass dort Windows installiert ist?

 

[Holt]

Möglich, vielleicht ist sie auch zu voll oder das Filesystem ist massiv fragmentiert und weisst keine großen, zusammenhängenden Bereich freier Cluster mehr auf. Dann werden ja statt weniger langer und schneller (also sequentieller) Zugriffe viele kurze zufällige Zugriffe nötig um das Testfile zu schreiben und das geht dann langsamer, obwohl Windows das bei SSDs sogar parallel macht, aber parallel Schreibzugriffe sind nicht die Stärke der 830er. Benche mal im Abgesicherten Modus von Windows und schau mit contig (von sysinternals) (gib vorher schon contig -a C:\AS-SSD-TEST42\test.bin in einer Eingabeaufforderung ein) und lass es während des seq. Benchmarks laufen. Bei mir kommt raus:

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

C:\AS-SSD-TEST42\test.bin is in 18 fragments

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

Mein Testfile hat also 18 Fragmente, es ist also keine zusammenhängende Datei und wahrscheinlich sind deshalb 17 zusätzlich Zugriffe auf die SSD nötig.

 

[Ralle86]

Bei mir ist die Datei in 17 Fragmente aufgeteilt. Danke dir. Das sollte der Grund dafür sein. Dann bin ich ja beruhigt. Kann man das mit defragmentieren wieder hinbekommen oder macht das keinen Sinn?

gesendet von meinem Xperia Z2

 

[Holt]

Du kannst es mit dem Defragmentieren versuchen, MyDefrag ist ganz gut weil es auch recht volle Filesysteme defragmentiert, da es nicht unbedingt den Ehrgeiz entwickelt jede Datei in genau einem Fragment abzulegen und daher auch Dateien defragmentiert, bei denen das gar nicht möglich ist. Das Ziel ist ja vor allem die unbelegten Cluster in möglichst zusammenhängenden Bereichen zu haben, damit eben die neuen Dateien wie die Testdatei von AS-SSD nicht so gewaltig fragmentiert und damit langsam geschrieben werden. Bei den alten Dateien auf der SSD ist es ja fast egal wie fragmentiert diese sind, die lassen sich immer noch recht schnell lesen solange die Fragmentierung nicht wirklich extrem ist, wie Du ja selbst siehst hat die Leserate darunter praktisch nicht gelitten, jedenfalls bei weitem nicht so wie die Schreibrate.

Das Defragmentieren schadet den SSDs auch nicht oder bringt sie gar um, es sind für die SSDs Lese- und Schreibzugriffe wie andere auch und das die Daten intern sowieso ganz woanders stehen ist zwar korrekt, aber für das Filesystem und die Zugriffen (Anzahl und Länge, also wie viele LBAs pro Befehl adressiert werden) sowieso egal. Es kostet halt einen oder zwei P/E Zyklen, bei voller Platte und extremer Fragmentierung vielleicht auch mehr, die NANDs haben ja genau und wie man gerade diesem Thread mal wieder sieht, reichen die meist für Jahrzeehnte bis Jahrhunderte aus. Wenn also eine SSD bei der Defragmentierung stirbt, waren die NANDs so am Ende, die wäre dann auch sowieso bald verreckt.

 

[Ralle86]

Dann schau ich mir das mal an. Danke noch mal.

 

[Majohandro]

4790k
Asus Maximus VII Formula Z97
Win 10 Home






MFG

EDIT:

Rapid Mode

 

[Holt]

Der RAPID Mode ist reiner (Selbst-)beschiss, Windows cacht ja normalerweise in sonst unbelegtem RAM selbst schon. Genau das versuchen Benchmarks wie der AS-SSD aber zu umgehen um wirklich die SSD und nicht das RAM zu benchen, aber bei solchen RAM Caches wie RAPID klappt genau das nicht. Natürlich ist Performancegewinn in einem Benchmarks wie AS-SSD immens, da werden ja auch die Daten geschrieben und sofort wieder gelesen, stehen also alle immer artig im Cache. AS-SSD schreibt außerdem in der Standardeinstellung ja nicht auf mehr als 1GB Adressraum und das dafür wiederholt, da braucht beim Schreiben also auch nicht mal der Cache geleert zu werden, wenn die gleichen Adressen wieder überschrieben werden. Aber schau Dir mal diesen Test an, vor allem Seite 5 mit Aufgaben wie dem Kompilieren von Firefox, FileCopy, Bittorrent tranfer, Video Transcoding und Virenscan dann sieht man was für eine Bremse dieser Cache in der Realität sein kann.

Und hier gibt es einen Test der 840 Pro 256GB mit RAPID, 5127 Punkte bei AS-SSD statt nur 1143 Punkte ohne, aber beim PC Mark 8, der reale Anwendungsszenarien durchtestet sind es dann nur noch 5057 statt 5006 Punkte ohne RAPID.

Warum ist es so, dass die Performance teils schlechter wird? Nun ja, jeder Cache will auch verwaltet werden, da gibt es immer einen Overhead. Hier mal 3 Benchmarks meiner 950 Pro mit dem Samsung NVMe Treiber und unterschiedlichen Einstellungen zum Schreibcache:

Wenn man das von Windows eranlasste Leeren des Cache deaktiviert, bringt es kaum etwas, aber man beachte die 4K (QD1) Lesend, die sind mit nur 45MB/s deutlich geringer als wenn man nur den oberen Haken setzt und damit nur den Schreibcache aktiviert, wo man auf 50MB/s kommt. Lässt man den auch weg, erschrickt man wie lahm NAND Flash wirklich ist, aber bekommt mit 53MB/s bei 4k Lesend sogar den besten Wert, da offenbar in keinem Cache mehr geschaut werden muss, ob die Daten dort ggf. drin stehen und damit schneller geliefert werden können. Anders als bei 4k_64 Lesend und beim seq. Lesen stande die Chance die Daten Cache zu finden bei 4k (QD1) wohl so schlecht, dass es im Ergebnis sogar ein Nachteil war den Cache zu haben.

 

[HisN]

Hier mal meine drei verbauten SSDs.
Ich hab mich von allen "normalen" SSDs getrennt. Spart 12 Kabel im Rechner und ich kann den SATA-Onboard-Controller abschalten



Samsung XP941, SM951 NVMe und Samsung SM951 AHCI alle 512GB
Laufen wohl nicht so superoptimal wie beim Holt, aber ich muss zugeben dass ich keine Lust habe da einzugreifen.

 

[Holt]

Vor allem die 4k lesend sind nur etwa halb so hoch, hast Du da irgendwelche Energiesparmassnahmen aktiviert, wie PCI Express Active State Power Management (ASPM)?

 

[HisN]

Nicht das ich wüsste, aber alle CPU-Stromsparmechanismen sind angeschaltet, auch die "tieferen" C-States.

 

[Suichi]

Samsung 850 EVO 250GB an einem B85M-Pro4:

Kann ich zufrieden ins Bett gehen?

 

[Holt]

Ja, Gute Nacht!

 

[Suichi]

Ehrlich? Die Werte alle so ok?

Dann gute Nacht oder wie die Israelis auf hebräisch sagen: לילה טוב!

 

[sledhammer]

Samsung SM951 NVMe 512GB im NoName PCIe Adapter

 

[Maxis]

Samsung SSD 950PRO mit 256GB an PCIex4 über Delock PCIe Adapter

 

[Shagnar]

ich habe meine 950pro gerade getestet, bin soweit zufrieden nur die 4k (QD1) werte kommen mir mit 35mb/s etwas niedrig vor:



im bios war während der installation m2 mode sata express eingestellt, habs erst nachträglich auf nvme geändert. kann es daran liegen?

c states sind an, samsung nvme treiber ist installiert, win 10.

 

[Holt]

Die 4k hängen vor allem vom System und dessen Energiespareinstellungen ab, meine 950 Pro 512GB schafft 50,48MB/s bei 4k Lesend mit dem Samsung NVMe Treiber im Ultra-M.2 Slot des ASRock Z97 Extreme 6 mit i7-4790K@Stock. Was für ein Board hast Du?

 

[Shagnar]

habe ein asus z170-pro, die ssd ist direkt im m2 slot auf dem mainboard angeschlossen.

 

[falken1]

Hallo, wollte auch meine olle SSD Samsung 840Evo 250Gb mal hier zeigen.

- - - Updated - - -

ups, mal einen kompletten Durchlauf........

 

[thb]

Das sind keine Ergebnisse der SSD sondern vom RAM.
Vermutlich mit Samsung Magician das System "optimiert"

 

[NoPainNoGain]

Und ich dachte schon, meine Samsung 850 Pro 256 GB wäre Schrott, weil ich nur etwa 1100 Punkte erreicht habe

 

[BarneyRubble]

Crucial MX100, 256GB, 13 Monate alt. Stimmt hier noch alles?

 

[Holt]

Sieht doch alles gut aus. Achte mal drauf ob sich der Rohwert von C7 ändert, es gab mal ein Problem mit dem SATA Kabel, aber der wurde vermutlich schon behoben, denn sonst wäre der Zählerstand in einem Jahr deutlich höher. Die NANDs haben 18 von 3000 spezifizierten P/E Zyklen runter, also so 0.6%. Bei dem Verbrauch würden die spezifizierten P/E Zyklen noch für über 200 Jahre reichen, Du brauchst Deine SSD also nicht zu schonen, so lange wirst Du sie bestimmt nicht nutzen und vorher geht wohl auch was anderes kaputt, im Zweifel der User.

 

[BarneyRubble]

Hallo Holt,

die wird nicht geschont. Nur als Sys SSD kommt da nicht viel zusammen...

Hätte noch gerne Deine Meinung zu folgendem:

WD Green, zwischen links und rechts liegen 13 Monate. Sicherung ist vorhanden..



Eine Crucial C300, 5 Jahre alt..

 

[Holt]

Da gibt es 9 schwebende Sektoren und das offenbar schon länger. Schwebende Sektoren sind Sektoren deren Daten nicht mehr zur ECC passen, da gibt die Platte statt der Daten einen Lesefehler als Anwort wenn man versucht diese zu lesen. Das kann auch anderen Gründe als defekte Oberflächen haben, z.B. einen Stromausfall während eines Schreibvorgang der dazu führt, dass eben nicht die ganze Daten plus der neuen ECC geschrieben wurden oder wegen eines Stoßes oder Vibrationen ist der Kopf beim Schreiben aus der Spur gekommen und hat Daten auf der Nachbarspur überschrieben.

Die Controller merken sich die schwebenden Sektoren und prüfen die Daten nach dem erneuten Schreiben auf diese Sektoren, dann verschwinden diese einfach oder werden eben durch Reservesektoren ersetzt. Wenn es dann wiederzugewiesene Sektoren gibt, dann hatte die Oberfläche dort wirklich einen Schaden.

Die C300 ist ja noch fast neu, die 285 verbrauchten P/E Zyklen sind nur gut 5% der spezifizierten P/E Zyklen, die NANDs wirst Du bei der Nutzung nicht kaputtgeschrieben bekommen, wenn Du weiter nur 1% der spezifizierten P/E Zyklen pro Jahr verbrauchst.

 

[FastAndy]

Zwei 950er im raid1, passt das so?