AS SSD Benchmark [3]

Weiß ich nicht, aber die Zugriffszeiten habe ja eigentlich mit der Einstellung wenig zu tun, außer das beim Schreiben ja über einen größeren Adressbereich geschrieben werden kann und damit u.U. eben nicht mehr alle Zugriffe nur in den Cache bzw. auf Daten die nur im Cache stehen, gehen können.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
das war eben auch mein gedanke. die größe des zu lesen/schreibenden files, sollte die zugriffszeit ja nur indirekt beeinflussen. zumindest nicht in dem umfang, wie es bei mir mit der aktuellen version des tools der fall ist.

die zugriffszeit soll denke ich angeben, wie lange es dauert, auf ein angefordertes file oder einen angeforderten adressbereich zuzugreifen, nicht wie lange es dauert, diese auch komplett zu lesen bzw zu schreiben. die größe des files bzw des bereichs ist da ja, so mein gedankengang, erst mal sekundär. ich kenne die logik nicht, die im hintergrund diesen zugriff ausführt, aber selbst wenn sie mehr macht, als nur "doof" zugreifen bzw schreiben, so sollte doch unabhängig der größe, der vorgang der logik in abhängigkeit der letztendlichen dateigröße etwa gleich bleiben und somit auch die dafür benötigte zeit.

ist in etwa das gleiche wie die latenz aus der netzwerktechnik, so stelle ich es mir zumidnest vor. "egal" wie groß eine zu übertragende datei ist, die latenz oder paketlaufzeit wird nur indirekt und minimal beeinflusst. beteiligte komponenten müssen unter umständen mehr warteschlangen abarbeiten, sind evtl höher ausgelastet, die komplexität der übertragung steigt, aber im prinzip verändert das die paketlaufzeit nur minimal, denn der weg und die dafür benötigten schritte bleiben in etwa die gleichen.
 
Zuletzt bearbeitet:
Das funktioniert bei SSDs schon anders als im Netzwerk und erst recht auch anders als bei HDDs, zumal schreibend wo ja nie beschriebene LBAs überschrieben werden, man müsste ja den ganze Block löschen und alle noch gültigen Daten vorher auch noch auslesen. Deshalb werden die neue Daten immer in andere Flahadressen geschrieben und dann wird diese Adressen auf den LBA gemappt. Zugriffszeiten bei SSDs wie bei HDDs messen zu wollen, was AS-SSD probiert, ist technisch einfach unmöglich und daher auch recht unsinnig, eben wegen dem Mapping. Ob die Performance nun beim Messen der Zugriffszeiten / IOPS über einen kleineren oder größeren Adressraum schwankt, hängt eben davon ab wie der Controller die Mappingtabelle verwaltet und das ist zumindest beim Intel Controller der 730er keine Baumstruktur, sonder eine falche Tabelle, weshalb der so viele Cache-RAM braucht um die komplett im RAM halten zu können und beim Controller der 750 würde ich stark vermuten, dass es dort genauso ist. Das meiste von dem ganzen Cache-RAM geht also wie bei SSDs üblich für Verwaltungsdaten, eben vor allem diese Mappingtabelle von LBAs auf Flashadressen, drauf.
 
klar, es sind zwei völlig unterschiedliche dinge. es sollte nur noch mal veranschaulichen, welchen einfluss die dateigröße auf die zugriffszeit hat. und da sehe ich eben schon parallelen.

die ssd geht ihre tabelle durch und "sucht" einen freien platz zum schreiben.
der router geht ebenfalls seine tabelle durch und "sucht" eine route zum ziel.
möchte man das so ganz grob veranschaulichen.
beide machen das für jedes frame oder für jeden block einzeln, oder?

die ssd wir doch nicht gleich platz für 10GB suchen, sondern für jedes tröpfen "datei" einzeln und die speicherstellen der "einzelteile" entsprechend des dateisystems irgendwie sammeln, oder? wenn sie gleich 10GB "reservieren" will, dann kann es natürlich einen einfluss darauf haben, wie lange sie braucht um den platz zu finden in abhängikeit des benötigten platzes.
 
Zuletzt bearbeitet:
Die Parallelen sehe ich eher weniger und außerdem sind SSD Controller ja auf 4k (alignet) Zugriffe optimiert, ein LBA ist aber nur 512 Byte groß, nur kommen solche Zugriffe eben kaum noch vor. Wenn man Pech hat, bedeutet ein 512 Byte Schreibzugriff dann, dass der Controller mal eben die restlichen 3.5k in dem 4k Block auch noch liest und dann zusammen mit den neuen 512 Bytes woanders ablegt, damit er eben nicht auch noch kleinere Einheiten als 4k verwalten muss, denn damit wären die Verwaltuungsdaten mal eben 8 mal so groß, wenn man eine flache Tabelle nimmt wie Intel es bei eigenen SSD Controllern ja zuweilen macht. Außerdem landen die Daten normalerweise sowieso im Cache, schon um die Write Amplification gering zu halten.
 
1 GB Testfile

as-ssd-benchcrucial_c3qovl.png


10 GB Testfile

as-ssd-benchcrucial_c0hqbd.png
 
als system volume schwanken die zahlen im seq. +-50mb/s in jedem run, das war als non system volume konsistenter. trotzdem hier mal der vergleich 1gb vs 5gb vs 10gb mit einer intel 750.



man kann sehen, dass der ram-cache keinen bis keinen nennenswerten einfluss auf die performance bzw den score hat. da hat der random faktor (+-50mb/s) weil system volume einen weit höheren einfluss.

als vorteil bei der höheren testgröße sehe ich den ausgewogeneren mittelwert bzw damit ein ehrlicheres ergebnis. läuft der test länger, weil das file größer, wird ein genauerer mittelwert gebildet, sodass das ergebnis damit an wert gewinnt. boostet eine ssd hoch im speed für einen augenblick oder droppt kurz, verfällscht das das ergebnis. lässt man den bench lang laufen, weil man ein großes testfile hat, kann die performance der ssd genauer bestimmt werden, weil peaks und drops gedämpft werden.
 
Zuletzt bearbeitet:
Der Großteil des RAMs wird bei SSDs eben zum Speichern der Verwaltungsdaten und nicht wirklich als Cache für die Userdaten verwendet. Von daher war auch für die Intel 750 das Update von AS-SSD nicht nötig. Übrigens nutzen auch nur HDDs einen Teil des angegebenen Caches wirklich als Cache, meist weniger als die meisten User sich wohl vorstellen, der Rest dient dem Controller einfach als RAM und für Verwaltungsdaten, wie eben die Verwaltung der wiederzugewiesenen und schwebenden Sektoren. Deshalb ist die Größe des Caches auch die wertloseste Angaben über eine HDD oder SSD.
 
genau so wird es sein. verwaltungsdatenspeicher, schnell und groß genug dem performance potential der ssd gerecht zu werden. kein reiner nutzdaten ram-cache. wenn die ssd noch so schnell ist aber der logik bzw dem controller der speicher für verwaltung ausgeht, wird das potential der ssd verschenkt. eine ssd, die so viel potential hat wie die 750, braucht einen großen ram.
 
Zuletzt bearbeitet:
Teilweise werden auch Nutzdaten gespeichert, sonst wäre die Performance zu schlecht und die Write Amplification zu hoch, denn die Pages sind bnei modernen NANDs ja 8k oder auch schon mal 16k groß und weniger als eine Page zu schreiben geht nicht, solange weniger im Cache steht, sollte man das möglichst nichts in NAND schreiben müssen. Das kann sich eine SSD mit ausreichend dimensionierten Stützkondensatoren (wie sie bei guten Enterprise DC SSDs üblich, aber bei Consumer SSD nur bei der Intel 730 und 750 zu finden sind) natürlich leisten, während andere SSDs damit das Risiko von Datenverlust bei plötzlichen Stromausfällen eingehen.
 
wenn zb die zu schreibenden daten in so winzigen stückchen bzw page für page aus dem system ram kommen müssten und garnichts der nutzdaten im ssd eigenen cache gelagert werden könnte, würde die ssd wohl brutal an speed verlieren, vor allem bei vielen zugriffen gleichzeitig. insofern kann ich dir folgen, hatte mich unvollständig/missverständlich ausgedrück, habs verbessert.

bewiesen ist jedenfalls, dass der verhältnismäßig große cache der 750 keinen wirklichen einfluss auf das ergebnis im as bench hat.
die vermutung lag aber nahe, dass eine ssd mit derart großem ram evtl mehr cached als die 0815 consumer ssd und dadurch evtl perfomance gewinnen könnte.
 
Zuletzt bearbeitet:
Natürlich hilft Cache auch immer der Performance, interessanter ist die neue Option mit dem Einstellen der Größe aber für solche blöden RAM Caches wie Samsungs RAIPD. Wichtig wäre es auch noch die Länge der Zugriffe bei den seq. Tests zu erhöhen, denn für die vollen Performance brauchen solch schnelle PCIe SSDs eben schon lange Zugriffe, wie man auch beim Vergleich der Ergebnisse von CDM und AS-SSD siehen kann, zumindest wenn das alte CDM 3.x verwendet wird.
 
daran habe ich auch schon gedacht. erhöht man bei einem derart großen ram den platz für nutzdaten, zb. über ein firmware update, sollte das teil doch an speed gewinnen können (je nach szenario)
 
Zuerstmal braucht man ja bei einer größeren Nutzkapazität auch mehr RAM für die Verwaltungsdaten, daher kann man nicht einfach den Platz für Nutzdaten nach Belieben anheben.
 
dazu müsste man den verbrauch an verwaltungsdaten/nutzdaten im ram natürlich kennen um das auf speed zu "tunen". intel wird aber schon wissen, warum sie der enterprise series und damit der 750 so viel ram verpasst haben und wie genau sie diesen aufteilen.
 
Zuletzt bearbeitet:
auch beim Crystal Disk Mark nimmt die testfile größe nicht wirklich großen einfluss auf die Ergebnisse, von daher war es fast schon vorhersehbar
 
eingangs gins ja hauptsächlich um die 750, so zumindest die argumentation von nsa wegen dem update mit testfilegrößen und von der gabs soweit wohl noch nicht so viele vergleiche in dieser richtung ;-)
 
Zuletzt bearbeitet:
Nur weil sich keine Köpfe bewegen müssen, bedeutet das eben nicht, dass Fragmentierung überhaupt keinen Einfluss auf die Performance hat, er ist nur weitaus geringer und daher wird gerne pauschal behauptet er wäre nicht vorhanden. Nur da er sich eben gerade in den Benchmarks zeigt, wäre es gut doch auch eine Anzeige dafür zu haben, was sehr bei der Diagnose von scheinbar nachlassender Performance im Alter helfen würde, was seid der 840 Evo ja ein großes Thema ist welches viele User besorgt.

Die interessante Frage dabei: wie kriegt man die Performance wieder hin,. bzw. beseitigt man das Problem (von Defragmentierung spricht man hier wohl besser nicht?). Image ziehen, wieder einspielen? Zwischendurch löschen?
 
Einfach Defragmenteiren, das ist auch für eine SSD kein Problem, dabei wird nur gelesen und geschrieben und wenn eine SSD dadurch wirklich kaputt geht, wäre sie sowieso bald hin gewesen. Die ein oder zwei P/E Zyklen die das kostet machen für die Haltbarkeit auch nichts aus. Im Prinzip könnte man das bei SSDs auch anders lösen, wenn man in der Lage wäre nur das Mapping von Daten zu ändern ohne sie wirklich neu zu schreiben, aber so eine Möglichkeit gibt es eben nicht, also defragmentiert man sie eben, wenn die Fragmentierung so groß wird, dass sie sich in der Perfromance bemerkbar macht. Leider prüft AS-SSD ja nicht, wie viele Fragmente das Testfile aufweist, aber wenn man es zur richtigen Zeit mit dem TaskManager abschiesst und dann mit Contig von Sysinternals nachsieht, erfährt man das ja auch.
 
zum Thema Defragmentierung kann ich nur immer wieder sagen das bei sämtlichen SSD´s bei denen ich das bisher getestet habe (und das waren einige) es der Leistung eher unzuträglich war
 
je nach SSD war es bei meinen SSD´s mehr oder weniger gravierend das die Leistung schlechter wurde, bei den Barefood hat man es deutlich gesehen, Sandforce mag es auch nicht so sehr.
Beim Marvel meiner MX 100 macht es nicht so viel aus.
Auch die Samsung 830 reagiert ein wenig negativ drauf (test mehrfach wiederholt)

Vor Defragmentierung
vorlaq4q.png


Nach Defragmentierung
nachvbqkh.png
 
Die Defragmentierung dient ja auch dazu neben der Dateien die Lücken des Filesystems, also die unbelegten Cluster, zusammen zu führen. Damit kann dann ein Benchmark wieder wirklich seq. benchen und natürlich ist es sinnvoll nach dem Defragmentieren dem Controller eine Pause zu gönnen, damit die Idle-GC Zeit zum Arbeiten hat. Da der Leistungsverlust wegen der extrem geringen Zugriffszeiten sehr, sehr viel geringer ist als bei HDDs und teils sendet Windows wohl auch die Befehle parallel, womit der Effekt nochmal geringer wird, braucht eine Defragmentierung nur sehr selten ausgeführt zu werden. Zuweilen hilft es aber, wenn bei den Benchmarks gerade die seq. Schreibrate auffällig gering ist, was natürlich auch andere Ursachen haben kann, etwa den Virenfinder.
 
Ich würde sagen das Defragmentieren nicht bei jeder SSD ein Allheilmittel ist, bei Sandorce SSD´s würde ich grundsätzlich abraten, mir viel bei den Sandforce SSD´s aber auch auf das diese eine weitaus geringere Fragmentierung aufweisen, legen die Daten also scheinbar von haushaus so ab das es keine große Fragmentierung gibt wie es scheint, bei den Crucials MX100 hat es keinen negativen Effekt und bei den Samsung 840 Evos kann es durchaus vorteilhaft sein.
3 Controller die komplett unterschiedlich auf das Defragmentieren reagieren.
Bei der von mir oben getesteten Samsung 830 hat es einen marginal negatieven einfluss auch nach längerer IDL Phase bleibt das dann so, auch ein manuel ausgeführter trim wirkt diesem dann nicht entgegen jedoch dürfte diese leichte Verschlechterung der Ergebnisse der obigen Samsung 830 nicht den geringsten unterschied in alltagsnutzen bewirken.
 
Zuletzt bearbeitet:
Die Fragmentierung ist eine Sache des Fileystems und nicht der unterliegenden Platte, womit auch der Controller der SSD total egal ist und keinen Einfluss auf die Fragmentierung hat und auch nicht haben kann. So weit das die Controller der SSDs das Filesystem selbst verwalten, was sehr sinnvoll wäre weil dann das Defragmentieren dann wirklich komplett unnötig wären (heutige SSD Congtroller haben dafür genug Power), es gibt nur bisher eben kein solche Filesystem. Von daher ist es auch Unsinn und beruht auf Zufall zu behaupten, dass SSDs mit Sandforce "eine weitaus geringere Fragmentierung aufweisen" würde.
 
Seit einer Weile werkelt die 850 Pro in einem Dell M6800 bin extrem zufrieden mit der SSD:

attachment.php


Schade das Dell nicht direkt solche SSDs im Onlineshop anbietet, aber ist nicht weiter tragisch ist ja schnell eingebaut.
 

Anhänge

  • 850pro512gb_Dell_M6800.png
    850pro512gb_Dell_M6800.png
    15,4 KB · Aufrufe: 335
ich habe ja nun einige SF SSD´s hier (6) welche alle genutzt werden und mit Daten belegt sind, deren Fragmentierung beläuft sich durchgehend zwischen 0,5 und 1,5% laut O&O.
Bei der Samsung, der MX100 und der Vertex 4 war die Fragmentierung durchwegs über 1,5%
Natürlich mag das zufall sein, dennoch fiel mir das auf als ich die tage mal Defrag tests machte
 
Zuletzt bearbeitet:
pinki, Du weißt gar nicht was die Fragmentierung ist und wo die passiert, oder?
 
Die "holtsche Fragmentrierung" ist die gleiche die es schon immer gab und die wurde noch nie vom Datenträger selbst verursacht, sondern hatte schon immer ihre Ursache im Filesystem. Statt so einen Blödsinn zu schreiben, solltest Du Dich mal damit auseinandersetzen und Dich richtig informieren.

Schau Dir mal den ATA Befehlssatz an, da gibt es kein Format, Create Directory, Write File oder Open File, das sind Befehle die das Fielsystem, genauer dessen Treiber im Betriebssystem und der übersetzt diese dann in Lese- und Schreibbefehle auf bestimmte LBAs der Platte und genau solche Befehle gibt es praktisch nur im ATA Befehlssatz. Wo welche Datei landet und ob das nur in einem Fragment passiert, also in aufeinander folgenden LBAs oder eben in viele kleinen Fragmenten, das entscheidet eben auch nur das Filesystem, ganz egal auf welche Platte es liegt. Sonst könnten alte Platten ja auch niemals mit neueren Filesystemen, RAIDs oder SW-Verschlüsselung funktionieren.
 
Zuletzt bearbeitet:
Die Fragmentierung findet nicht auf dem Datenträger statt, das Filesystem, genau der Softwareteil im Betriebssystem, erzeugt die Fragmentierung wenn er entscheidet wo welche Datei gespeichert wird. Die Fragmentierung zeigt sich nur auf dem Datenträger und bei HDDs hört man sie auch oft genug, wenn die Zugriffe laut genug sind und spürt sie massiv, weil die Zugriffe wegen der Kopfbewegungen immer recht langsam sind.

Das die SSDs die Daten der LBAs intern noch einmal ganz anders ablegen und diese Flashadressen dann auch LBAs mappen, hat mit Fragmentierung auch nichts zu tun, denn bei der Fragmentierung geht es immer nur um die Zugriffe die vom Rechner auf eine Platte erfolgen, nicht um die interne Anordung der Daten. Die ist bei HDDs aber mit Ausnahme der wiederzugewiesenen Sektoren nur "zufällig" eben so, dass die aufeinanderfolgenden LBAs eben i.d.R. auch auf den Platten nebeneinander liegen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh