AS SSD Benchmark

Status
Für weitere Antworten geschlossen.
Na bei Win7 ist AHCI sicher an. Zumindest wenn man die Benchmarkwerte anschaut.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
ich schlag euch alle :fresse:
attachment.php
 

Anhänge

  • as-ssd-bench SAMSUNG HD080HJ  07.11.2009 19-23-53.png
    as-ssd-bench SAMSUNG HD080HJ 07.11.2009 19-23-53.png
    12,4 KB · Aufrufe: 354
Die ist zumindest genauso groß wie Intel.:fresse: Wobei 17ms zugriffszeit etwas hoch sind (AAM aktiviert?).
 
AAM ?
ist nur win7 drauf, warte bis die 160 intel da ist. Meine SDHC Card ist glaub ich schneller^^. denke die HDD wird nicht mehr lange leben
 
Es fasst die für die SSDs relevanten tests zusammen und ist einfacher zu verwenden als z.B. IOmeter. Durch 1gb Testgrösse ist es genauer als die meisten anderen Benchmarks die 4k-Tests durchführen. Außerdem kommen vieleicht noch andere Tests dazu die nicht von den sonstigen Benchmarks durchgeführt werden. Ihr dürft nicht vergessen dass es sich hier um eine beta-version handelt wo noch nciht alle Funktionen enthalten sind. Ich würde es in der Form nicht veröffentlichen, aber ohne dass ihr es auf vielen verschiedenen SSDs testet, finde ich keine Bugs.

Ich möchte die 1 GB Test Size für 4k Tests kritisch hinterfragen:

Macht die 1 GB Größe wirklich Sinn bei 4k Tests? Mir ist nämlich im Crystal Benchmark aufgefallen, dass es bei meiner SSD einen Unterschied im Faktor 10 macht, ob ich mit einer 100 MB oder 1 GB Test Size benche. Nun ist die Frage, was ist realistischer um die reale Performance im Alltagsbetrieb zu beurteilen?

Hier meine Werte (nach oben hin leider durch meinen Mainboard Chipsatz begrenzt):



1 GB bedeutet, dass 250.000 4k Dateien am Stück gelesen oder geschrieben werden. Wann passiert das in der Realität - beim normalen Arbeiten mit dem PC? Ich vermute, so gut wie niemals. Nun kann man sagen, 1 GB Test Size wäre genauer, weil ich halt den Mittelwert aus 250.000 Messungen bilde und das ist genauer als den Mittelwert aus 25.000 Messungen - aber ich denke, da macht man sich etwas vor. 25.000 Messungen sind bereits enorm viel. Wenn diese Genauigkeit nicht ausreichen würde und die 250.000 Messungen unbedingt nötig wären, müsste man bei sequentiellen Read/Write Tests übrigens nicht eine 1 GB Test Size sondern eine Test Size von 250 GB (oder mehr) einstellen.

Nun kann man natürlich argumentieren: mehr Messungen, ergeben einen genaueren Mittelwert und sind damit doch immer besser. Ja. Es sei denn es schleicht sich dabei ein systematischer Fehler ein - so wie es bei einigen SSD Modellen der Fall zu sein scheint.

Es gibt SSDs die brechen im 4k write auf die Performance einer HDD ein, wenn sie mit 250.000 4k writes am Stück bombadiert werden. Anscheinend streicht dann in dieser speziellen Situation der Cache die Segel und wedelt mit der weißen Fahne. Dies ist bei nur 25.000 4k random writes am Stück nicht der Fall. Und das ist eine für den realen Anwendungsfall bereits unrealistische hohe Anzahl.

Nun kann man sagen, aber wir wollen die Performance der SSD ohne ihren Cache messen. Dazu könnte ich nur "häh?" entgegnen. Der Cache einer SSD ist ein Teil von ihr, ist ein Teil der Blackbox. Also macht es keinen Sinn ein Testverfahren so zu wählen, dass der Cache bei bestimmten Modellen neutralisiert wird.

Zusammenfassend: Ich vermute, der AS SSD Benchmark kann, so wie er derzeit funktioniert, nicht die Performance von allen SSDs korrekt abbilden, weil er von urealistischen Annahmen ausgeht.
 
Nun kann man sagen, 1 GB Test Size wäre genauer, weil ich halt den Mittelwert aus 250.000 Messungen bilde und das ist genauer als den Mittelwert aus 25.000 Messungen - aber ich denke, da macht man sich etwas vor. 25.000 Messungen sind bereits enorm viel. Wenn diese Genauigkeit nicht ausreichen würde und die 250.000 Messungen unbedingt nötig wären, müsste man bei sequentiellen Read/Write Tests übrigens nicht eine 1 GB Test Size sondern eine Test Size von 250 GB (oder mehr) einstellen.

Ja, die Bedingungen sind unrealistisch, wenn jedoch ein SSD langsamer wird, dann gehört das auch dargestellt. Da das Problem anscheinend bei 25.000 vs. 250.000 Zugriffen noch zum Tragen kommt ist genau DAS die Rechtfertigung und Daseinsberechtigung für 1 GB Testsize!

Benchmarks sind schon von sich aus unrealisisch, allerdings braucht man eine gewisse Vergleichbarkeit - in diesem Fall ist der eben durch die Testgröße gegeben. Außerdem werden nur Caches vom Betriebssystem deaktiviert, die SSD-Caches kann man eh nicht beeinflussen.

Freu dich über die gute Realperformance deines Mtron SSDs und denk dir einfach im Hinterkopf, dass die Werte bei 1 GB 4k-write zwar recht unrealistisch, aber eben so sind wie sie sind. Offensichtlich brechen die Mtrons eben bei dieser Testgröße ein, so what?
 
Ja, ich ich bin ja auch zufrieden - es ist rein akademisches Interesse.

Ja, die Bedingungen sind unrealistisch, wenn jedoch ein SSD langsamer wird, dann gehört das auch dargestellt. Da das Problem anscheinend bei 25.000 vs. 250.000 Zugriffen noch zum Tragen kommt ist genau DAS die Rechtfertigung und Daseinsberechtigung für 1 GB Testsize!

Dann wäre es aber sinnvoller, dies einen Stresstest zu nennen, und zu gucken, wie lange die SSD fehlerfrei funktioniert. Es ist kein Performance Test mehr, wenn man weit ausserhalb realer Anwendungsfälle, bei einem Teil der Untersuchungsobjekte Ausfälle provoziert und dies dann fälschlich als einen für den Betrieb der SSD relevanten Performance Unterschied darstellt.

Benchmarks sind schon von sich aus unrealisisch, allerdings braucht man eine gewisse Vergleichbarkeit - in diesem Fall ist der eben durch die Testgröße gegeben. Außerdem werden nur Caches vom Betriebssystem deaktiviert, die SSD-Caches kann man eh nicht beeinflussen.

Benchmarks mögen unrealistisch sein, aber sie sollten doch versuchen mir Hinweise auf die reale Leistung zu geben.

Wenn ich die Windgeräusche von Autos bei hoher Geschwindigkeit miteinander vergleichen möchte, dann fahre ich mit den Autos mit hoher Geschwindigkeit über eine Teststrecke und messe die Lautstärke - ich schweiße sie aber nicht auf einen Kampfjet, fliege mit Mach 1 im Tiefflug über die Autobahn und messe dabei die Lautstärke.

Und ein Viertelmillion 4k random writes am Stück sind total unrealistisch. Der SSD Cache meiner SSD wird zwar nicht aktiv deaktiviert aber irgendwie überlastet, so dass er dabei aussetzt. Weiß der Geier warum - ist ja auch irrelevant, weil es ausserhalb eines realen Anwendungsfalls liegt.

Ich finde es halt nur Schade, dass der Benchmark anscheinend nur für einige SSDs funktioniert und nicht für alle. Und wer weiß welche SSDs noch davon betroffen sind?

Und da Feedback, denke ich zumindest, bei einer Beta Version prinzipiell erwünscht ist, wäre mein Vorschlag, in Abhängigkeit von dem, was getestet wird (sequentiell vs 4k), unterschiedlich große Test Sizes zu nutzen. Dann muss man halt mal überlegen wie viele 4k am Stück überhaupt eintreten können.

Den Ansatz von CDM, verschiedenen Test Sizes wählen zu können, halte ich für vielversprechend - AS SSD könnte sogar noch einen draufsetzen und verschiedene variable Test Sizes pro Fall (Seq. vs 4k) zulassen. Es wäre dadurch ein besserer Benchmark.

Weiterhin könnte man übrigens auch ein variables Scoring Modell einbauen - vielleicht mit ein paar pre-sets für typische Anwender wie Office, Gamer, Multimedia, Programmierer und eine freie Gewichtung. Aber das ist ein ganz anderes Thema.

Weiterhin ist die Plausibilität der Ergebnisse des AS SSD Benchmarks im Bereich 4k-64 etwas merkwürdig. So verwundert es schon, dass eine SSD, die mit einer Zugriffszeit von 0,3 ms gemessen wird, eine 4k Datei im 4k-64 Bench binnen 0,071 ms liest (siehe Post #1110). Sie greift auf die Datei zu und liest sie also dreimal so schnell wie der Zugriff alleine dauert. Hmmmh. Da frage ich mich schon, wie geht denn das?

Freu dich über die gute Realperformance deines Mtron SSDs und denk dir einfach im Hinterkopf, dass die Werte bei 1 GB 4k-write zwar recht unrealistisch, aber eben so sind wie sie sind. Offensichtlich brechen die Mtrons eben bei dieser Testgröße ein, so what?

Ich freue mich ja und bin zufrieden.

Aber vielleicht möchte ich irgendwann mal (auch wenn es eher unwahrscheinlich ist) auf eine K5 oder so upgraden - dann wäre es halt schön einen Vergleich zu haben, was ich an Leistungszuwachs zu erwarten hätte. Mit dem AS SSD Benchmark geht das jetzt halt nicht.

Rein akademisches Interesse.
 
Zuletzt bearbeitet:
Wieder diese Mtron Besitzer...:heuldoch:
Die anzeige von 5MB/s bei CDM ist schlichtweg falsch!(schau in den Datenblatt der SSD da steht 120iops!!(0,5MB/s) hatte ich schonmal verlinkt). 1GB testsize ist wegen größe des Caches so festgelegt. Klar zeigt der 5MB/s an wenn der großteil der Schreibzugriffe im Chache landet. :stupid:

Bei der Mtron SSD da sogar 0,24iops

http://www.mtron.net/upload_Data/Spec/ASiC/MOBI/PATA/MSD-PATA3018_ZIF1_rev0.1.pdf

Datenblatt (Seite 8(9)).

60iops*4k=240KB/s=0,24MB/s
 
Zuletzt bearbeitet:
Wieder diese Mtron Besitzer...:heuldoch:

Sorry, ich wollte nur helfen, dein Prorgamm zu verbessern. Es gibt für mich auch kein Grund zu heulen, denn für mein Anwendungsprofil (als Boot- und Programmplatte) sind 4k random writes sowieso vollkommen irrelevant.

Ich wollte dir nur helfen, dein Benchmarkprogramm zu verbessern.

Die anzeige von 5MB/s bei CDM ist schlichtweg falsch!(schau in den Datenblatt der SSD da steht 120iops!!(0,5MB/s) hatte ich schonmal verlinkt). 1GB testsize ist wegen größe des Caches so festgelegt. Klar zeigt der 5MB/s an wenn der großteil der Schreibzugriffe im Chache landet. :stupid:

Ist sie nun falsch, in dem Sinne, dass CDM einen Bug hat? Das stimmt nicht, denn dann müsste der Bug auch mit anderen Laufwerken reproduzierbar sein, was definitiv nicht der Fall ist.

Und der Cache der SSD ist ein Hardware Bestandteil der SSD. Natürlich landen 4k Writes im Cache. Wo sollen sie auch sonst hin. Also gehört die Leistung des Caches auch zur Leistung der SSD.

Die 120 iops die du aus dem Datenblatt anführst, ist übrigens kein technisches Datum der SSD - es ist das Ergebnis eines Benchmark. Und guess what: 1 GB Test Size. Steht in der Fußnote. (Unter Vorbehalt: Falls ich das richtig verstehe)

Oder meinst du mit Cache einen Cache aus dem Betriebssystem? Wo wäre damit das Problem? Nun, mir ist ehrlich gesagt egal, wo gecached wird. Und dich scheint es ja auch nicht zu stören - freust du dich doch über 60 MB/s random 4k-64 read bei deiner SSD (Post #1) - dir ist schon klar, das dieser komplette read pro 4k Datei fast dreinmal so schnell ist wie die allein die Zugriffszeit deiner SSD auf eine Datei. Faszinierend. Naja, wie sagte schon Orwell: all animals are equal - but some animals are more equal.

Ich bleibe dann mal besser bei Crystal Mark, denke ich. Schade, so ein paar weitere Anpassungmöglichkeiten wären nett gewesen.
 
Zuletzt bearbeitet:
4k-64thread read liest ja auch alle Dateien zusammen und nicht 4k datei->warten->nochmal 4k datei. ;) Siehe NCQ. Der 4k-writetests testen eine Programminstallation und diese ist fast immer größer als 100mb. Bleib halt bei CDM. Mein Benchmark dauert auf einer Mtron eh viel zu lange.
 
Ach so, dann hatte ich die Erklärung von 4k-64 falsch verstanden.

Und es stimmt, dass Programminstallationen über 100 MB schreiben - aber wenn ich mir z.B. mein Open Office 3 angucke, dann sind das bei 400 MB nur 4.000 Dateien. Weit entfernt von einer Viertelmillion.

Aber ich sehe schon, weiteres Argumentieren würde nichts bringen und nur in Streit enden. Genauso wenig, wie diese IOPS Messung, die ich gerade gemacht habe, etwas bringen würde. Eine Mtron mit gemessenen 2096 IOPS beim 4k random Schreiben...

.... obwohl - :heuldoch: - hier ist der Beweis:



Mtron Pro, 4k random write: 2096 IOPS.

Noch ein Programm mit einem Fehler?

EDIT:

Ach, ich sehe gerade, auf dem Bild sieht man gar nicht, dass es ein crystal mark 4k random Test ist. Naja, du, nsa666, musst es mir nicht glauben - andere interessierte Mtron User können es ja einfach nachvollziehen -> Verknüpfung zum CDM in den Autostart legen, mit Bootvis booten, schnell einen Test und 50 oder 100 MB einstellen, nur 4k testen und nach dem Beenden wieder zumachen. Bumms. Da hat man die IOPS aufgezeichnet.

Die 4k random read Werte sind übrigens nur so grottig, weil das System noch extrem busy war. Vielleicht brauche ich doch mal einen dual core...
 
Zuletzt bearbeitet:
Solange die 4k-writes im cache (32MB ist der glaube) landen könnens schon 2000iops und sogar viel mehr sein. Sobald du eine 400MB installation startest ist der Cache aber sofort voll und du bist bei den 60iops..

Und eine Datei kann aus mehr als einem 4k sektor bestehen.

P.S.: Und wenn selbst Mtron 1GB Testsize für richtig hällt(sonst würden die es nicht ihr Datenblatt schriben) hab ich wohl Recht.
 
Zuletzt bearbeitet:
Also ich bitte dich. Eine 400 MB Installation besteht doch nicht nur aus 4k Dateien. Open Office 3 - ca. 400 MB mit ca. 4.000 Dateien. D.h. die Dateien sind im Schnitt 100 kB groß. Die flutschen dort wie nichts durch den Cache durch, weil das ja quasi schon sequentielles Schreiben (=fünfstellige IOPS) ist.

Und die Mtron Pro ist ja selbst mit 5,6 MB/s 4k random write vergleichsweise lahm. Nur sind die 600 kb/s oder was auch immer dein Benchmark suggerieren möchte totaler Unsinn.

In der Realität wird man nie bei diesen 60iops landen, da sie nicht technisch begründet sind, sondern auch nur auf einem Benchmark mit vermutlich ungünstiger Test File Size (1 GB!) beruhen (- anders wären die Bootvis und CDM Ergebniss rechnerisch gar nicht zu erklären - auch nicht mit 32 MB Cache). Man mag sich wundern warum Mtron eine ungünstige Test File Size wählt - die Antwort ist vermutlich simpel: die Größe galt für alle Tests und die maximale sequentielle Übertragungsrate kommt mit 1 GB Test File Size höher daher. Und da die maximale sequentielle Übertragungsrate der SSD die Megapixel der Kleinbildkamera "sind"...
 
Zuletzt bearbeitet:
Es ist kein Unsinn. Das ist der Wert der die SSD eben erreicht. Keine andere SSD hat mit 1GB testsize probleme (nicht mal die indilinx MLC). und 60iops SIND technisch begründet. Der Controller ist so alt dass es kein Write-Combining kann. Bei den ersten 32MB erreicht der vielleicht 40-100MB/s wenns dann aber an das eigentliche schreiben ins Flash geht brichts auf die 60/120 iops ein(je nach Modell). Und da es schon SSDs mit mehr als 128MB Cache gibt macht eine Messung mit 100MB testsize keinen Sinn. Ich will ja den Flash-Speicher messen nicht den Cache.... Sogar manche festplatten haben 64MB Cache.

Kauf dir eine neue SSD, und diesmal nicht sowas uraltes wie Mtron, wenn du bessere Werte willst.

Übrigens: eine IO-Operation ist nicht unbeding 4kb ;).
 
naja das nutzt euch jetzt doch nix
Wo bleibt die einsicht das es nunmal keinen Benchmark gibt der für ALLE nutzer eine reale umgebung wiederspiegelt da diese bei jedem anders ist, je nach art der nutzung und je nach SSD.
Somit dient jeder bench als grober anhaltspunkt der nicht 1:1 auf die realität übernommen werden kann, man kann beim programmieren eines solchen benches lediglich versuchen so nahe wie möglich an ein realistisches ergebniss ran zu kommen.
Oder seh ich das so falsch nsa?
 
Zuletzt bearbeitet:
@pinki: genau. Es ist nicht ohne weiteres möglich reale Nutzung zu simmulieren. Die ist bei jedem anders. Zumal es eben ein synthetischer Benchmark ist. Der misst die Leistung der SSD, und das möglichst unabhänig vom Rest des Systems.

Und ein Benchmark, der das zeigt was im Datenblatt steht, find ich viel sinnvoller als einen der irgendwelche Fantasiewerte anzeigt. :p

Wenn im Datenblatt 2000iops stehen würde, und mein Benchmark nur 120 zeigt würd ich mir sorgen machen dass was nicht stimmt. Aber so... Sie werden wohl wissen was sie reinschreien.
 
Zuletzt bearbeitet:
Es ist kein Unsinn. Das ist der Wert der die SSD eben erreicht. Keine andere SSD hat mit 1GB testsize probleme (nicht mal die indilinx MLC).

Das ist ja auch kein Wunder, weil die Mtrons einen proprietären Controller haben.

und 60iops SIND technisch begründet. Der Controller ist so alt dass es kein Write-Combining kann. Bei den ersten 32MB erreicht der vielleicht 40-100MB/s wenns dann aber an das eigentliche schreiben ins Flash geht brichts auf die 60/120 iops ein(je nach Modell).

Das kann ich mit einer weiteren Falsifikation widerlegen: Dann müsste die Übertragungsrate bei 50 MB Test Size ungefähr doppelt so groß sein wie von 100 MB - ist es aber nicht, die Datenrate ist unabhängig von der Test Size konstant, bis sie ab einem Wert X einmalig einbricht. Deine Aussage ist falsch, weil die Datenrate sonst zu kleineren Test Sizes (bis 32 MB) kontinuierlich steigen müsste. Das ist nicht der Fall.

Hast du das verstanden? Ich habe gerade mir purer Logik deine Aussage widerlegt. DAMIT IST DEINE AUSSAGE FALSCH! Es stimmt einfach nicht, was du erzählst.

Hey, ich habe ZWEI voneinander unabhängige Benchmark Programme, die meine Aussagen bestätigen - und du glaubst WIRKLICH die sind BEIDE falsch? Wach mal auf, Junge.

Meine Aussagen erklären sowohl die Ergebnisse die Bootvis, CDM und auch dein AS SSD liefert. Deine Aussagen geben nur eine (sic!) Erklärung für das AS SSD Ergebnis IGNORIEREN aber die Ergebnisse der anderen Programme, weil si halt nicht dazu passen. Deine Aussagen sind schlicht und ergreifend in sich nicht schlüssig - und das alles nur weil du nicht zugeben willst, dass du einen Parameter in deinem Programm nicht optimal gewählt hast? Oh Mann.

Weisst du, es geht mir gar nicht darum, für meine Mtron etwas zu beweisen - aber deine Ignoranz geht mir mittlerweile tierisch auf den Senkel. Diese Ignoranz steht für alles, was ich in dieser Welt nicht mag.

Und da es schon SSDs mit mehr als 128MB Cache gibt macht eine Messung mit 100MB testsize keinen Sinn. Ich will ja den Flash-Speicher messen nicht den Cache.... Sogar manche festplatten haben 64MB Cache.

Ja, aber der Cache ist ein fester Bestandteil der SSD. Stell die vor, eine neue SSD hätte in Zukunft eine Mini-Ramdisk integriert - also einen riesigen Cache von 1 GB. Die SSD arbeitet im Alltagsbetrieb (beim Schreiben) so schnell wie eine Ramdisk. Nun hast du eine zweite SSD, irgendein altes Modell identisch zum neuen Modell - bis auf den Cache, der hier nur 32 MB hat und die dadurch im Alltagsbetrieb (beim Schreiben) deutlich langsamer ist. DU willst den Cache jetzt NICHT mit messen, würdest die Test Size also so irrational groß wählen, dass die neue schnelle SSD einbricht, worauf beide gleiche Ergebnisse liefern. Jemand der vor einer Kaufentscheidung steht, würde anhand deines Benchmarks denken, dass beide in Bezug auf das Schreiben gleichwertig sind. Und das wäre falsch. Dein Benchmark würde ein falsches Bild widerspiegeln.

Ich will dir hier nur den Fehler deiner Logik zeigen und damit nicht sagen, dass meine Mtron im 4k random write schneller wäre als irgendeine andere. Ist sie definitiv nicht. Mit 5,6 MB/s zweifach gemessen (halt nur nicht mit deinem unrealistischen Benchmark) markiert sie das untere Ende der Fahnenstange. Aber ich kann auch nicht tatenlos zusehen, wie hier mit deinem völlig unrealistischen Benchmark (eine Viertelmillion 4k writes am Stück...) Unsinn verbreitet wird.

Und dein Benchmark ist nun mal sub-optimal und liefert ein falsches Bild.

Kauf dir eine neue SSD, und diesmal nicht sowas uraltes wie Mtron, wenn du bessere Werte willst.

Das zeigt mir nur wie VÖLLIG ahnungslos du bist, sobald es um den realen Anwendungsbetrieb gibt.

Wie ich oben geschrieben habe, nutze ich meine SSD als System- und Programmplatte und mein Mainboard limitiert die maximale Datenübertragung zur SSD auf ca. 82 MB/s - jetzt zeige mir bitte eine einzige aktuelle MLC SSD, die schneller wäre als meine. EINE EINZIGE. Geht nicht. Warum? Weil meine "uralte Mtron" (Pro) schneller ist!

Anhand meiner Bootvis Bilder kannst du auch das Verhältnis von Read zu Write abschätzen. Das dürfte bei mir so 90% read zu 10% write sein. Den Firefox Cache könnte man da sogar noch vom write abziehen, denn mein Internetzugang hat nur 400 kb/s - da reichen die 5,6 MB/s random 4k write locker. Und die Pagefile.sys ist ein sequentieller write - wobei bei 2 GB Ram nicht viel gepaged werden muss.



Und wenn du dir jetzt die Daten meiner SSD anschauen würdest, würdest du erkennen, dass mir eine aktuelle MLC SSD im sequentiellen read NICHTS bringen würde, im wichtigen 4k random read wäre eine aktuelle MLC 20-30% LANGSAMER (sic!), im sequentiellen write wäre die aktuelle MLC 15% schneller und nur im 4k random write wäre eine aktuelle MLC deutlich schneller als meine 5,6 MB/s. Nur sind die Writes in meinem Anwendungsprofil TOTAL unwichtig gegenüber den Reads. 100 Stück 4k random writes dauern bei mir 71 ms - das ist weniger als ein Wimpernschlag. Hier würde ich in der Realität den Unterschied zur aktuellen MLC NICHT merken! - Aber alle meine Programme und mein System würde mit einer aktuellen MLC LANGSAMER starten!

Aber was mache ich hier überhaupt.

Ich merke schon, du bist kein Wissenschaftler und an einer ernstzunehmenden Diskussion nicht interessiert.

Du verdrehst die Tatsachen und behauptest die 60 IOPS (bei meiner übrigens 180, aber egal) wären ein festes technisches Datum, und suggerierst es würde für alle Test File Sizes gelten. Was falsch ist. Es steht weder in einer Rubrik technische Daten, noch ist gilt es für alle Test Sizes - es ist EIN Benchmark für EINE Test File Size. Deine UNZULÄSSIGE Verallgemeinerung dieses und deines Benchmarks sind NACHWEISLICH falsch - ich habe dir zwei voneinander unabhängige Beweise geliefert (Bootvis, CDM) und eine Erklärung, die die Ergebniss deines und Mtrons Benchmark einschliesst. Du versuchst dich hier nur mit absurden Konstrukten rauszureden und lässt dir vage Erklärungen.... Cache.... einfallen, die beim einfachsten kritischen Hinterfragen als FALSCH enttarnt werden.

Du ignorierst die Fakten. O.k. Deine Entscheidung. Eine weitere Diskussion ist sinnlos.

Ich denke ich muss hier nicht mehr schreiben, denn jeder halbwegs gebildete Leser kann sich nun seine eigene Meinung bilden.
 
Zuletzt bearbeitet:
Das ist ja auch kein Wunder, weil die Mtrons einen proprietären Controller haben.

?? properietär=von einer Firma. Jeder Controller ist propertitär.

Das kann ich mit einer weiteren Falsifikation widerlegen: Dann müsste die Übertragungsrate bei 50 MB Test Size ungefähr doppelt so groß sein wie von 100 MB - ist es aber nicht, die Datenrate ist unabhängig von der Test Size konstant, bis sie ab einem Wert X einmalig einbricht. Deine Aussage ist falsch, weil die Datenrate sonst zu kleineren Test Sizes (bis 32 MB) kontinuierlich steigen müsste. Das ist nicht der Fall.

Zu beachten: CDM führt keinen test vollständig aus. Rechne mal aus wie viel es dauern würde 1GB mit 0,5MB/s auf die SSD zu schreiben und messe mit stoppuhr nach wie lange CDM dafür braucht. Ich kann eben nicht sagen was CDM da misst wenn du 50MB einstellst. Ob er da 5MB schreibt oder 30MB? oder 100MB? Anscheined bezieht sich die Angabe nicht auf die tatsächlich geschriebene/gelesene Daten sondern auf den zu testenden Bereich. Also der legt eine 100MB Datei an und testet da drin. Wie viel in wirklichkeit geschrieben/gelesen wird weiss man nicht.

Hast du das verstanden? Ich habe gerade mir purer Logik deine Aussage widerlegt. DAMIT IST DEINE AUSSAGE FALSCH! Es stimmt einfach nicht, was du erzählst.

Hey, ich habe ZWEI voneinander unabhängige Benchmark Programme, die meine Aussagen bestätigen - und du glaubst WIRKLICH die sind BEIDE falsch? Wach mal auf, Junge.

Bisher nur CDM. Bei Bootvis sind alle möglichen Caches und optimierungen an. Was das zeigt ist ziemlich fraglich.

Meine Aussagen erklären sowohl die Ergebnisse die Bootvis, CDM und auch dein AS SSD liefert. Deine Aussagen geben nur eine (sic!) Erklärung für das AS SSD Ergebnis IGNORIEREN aber die Ergebnisse der anderen Programme, weil si halt nicht dazu passen. Deine Aussagen sind schlicht und ergreifend in sich nicht schlüssig - und das alles nur weil du nicht zugeben willst, dass du einen Parameter in deinem Programm nicht optimal gewählt hast? Oh Mann.

Die Parameter sind optimal gewählt. Bei allen anderen SSDs außer Mtron und JM602B gibt es keine Probleme und der Benchmark liefert sehr verlässliche Ergebnisse.

Ja, aber der Cache ist ein fester Bestandteil der SSD. Stell die vor, eine neue SSD hätte in Zukunft eine Mini-Ramdisk integriert - also einen riesigen Cache von 1 GB. Die SSD arbeitet im Alltagsbetrieb (beim Schreiben) so schnell wie eine Ramdisk. Nun hast du eine zweite SSD, irgendein altes Modell identisch zum neuen Modell - bis auf den Cache, der hier nur 32 MB hat und die dadurch im Alltagsbetrieb (beim Schreiben) deutlich langsamer ist. DU willst den Cache jetzt NICHT mit messen, würdest die Test Size also so irrational groß wählen, dass die neue schnelle SSD einbricht, worauf beide gleiche Ergebnisse liefern. Jemand der vor einer Kaufentscheidung steht, würde anhand deines Benchmarks denken, dass beide in Bezug auf das Schreiben gleichwertig sind. Und das wäre falsch. Dein Benchmark würde ein falsches Bild widerspiegeln.

Jemand macht ein Bandlaufwerk mit 1gb großen Cache.....:asthanos: Wie gesagt typische Softwareinstallation ist größer als 100MB.

Ich will dir hier nur den Fehler deiner Logik zeigen und damit nicht sagen, dass meine Mtron im 4k random write schneller wäre als irgendeine andere. Ist sie definitiv nicht. Mit 5,6 MB/s zweifach gemessen (halt nur nicht mit deinem unrealistischen Benchmark) markiert sie das untere Ende der Fahnenstange. Aber ich kann auch nicht tatenlos zusehen, wie hier mit deinem völlig unrealistischen Benchmark (eine Viertelmillion 4k writes am Stück...) Unsinn verbreitet wird.

Und dein Benchmark ist nun mal sub-optimal und liefert ein falsches Bild.

Ich weiss dass 1gb 4k-random write praktisch niemals in der praxis vorkommt. 100MB übrigens auch nie. Eine extreme Last zu erzeugen liegt aber in der Natur eines Benchmarks.

Wie ich oben geschrieben habe, nutze ich meine SSD als System- und Programmplatte und mein Mainboard limitiert die maximale Datenübertragung zur SSD auf ca. 82 MB/s - jetzt zeige mir bitte eine einzige aktuelle MLC SSD, die schneller wäre als meine. EINE EINZIGE. Geht nicht. Warum? Weil meine "uralte Mtron" (Pro) schneller ist!

Eine X25-M ist im AHCI modus schneller(160MB/s 4k random read bei 64 threads,258MB/s seq).




Anhand meiner Bootvis Bilder kannst du auch das Verhältnis von Read zu Write abschätzen. Das dürfte bei mir so 90% read zu 10% write sein. Den Firefox Cache könnte man da sogar noch vom write abziehen, denn mein Internetzugang hat nur 400 kb/s - da reichen die 5,6 MB/s random 4k write locker. Und die Pagefile.sys ist ein sequentieller write - wobei bei 2 GB Ram nicht viel gepaged werden muss.

Ich weiss das read bei desktoprechnern viel öfter vorkommt als write... deswegen wird read höher bewertet bei dem score, wenn auch nicht 10:1.

Und wenn du dir jetzt die Daten meiner SSD anschauen würdest, würdest du erkennen, dass mir eine aktuelle MLC SSD im sequentiellen read NICHTS bringen würde, im wichtigen 4k random read wäre eine aktuelle MLC 20-30% LANGSAMER (sic!), im sequentiellen write wäre die aktuelle MLC 15% schneller und nur im 4k random write wäre eine aktuelle MLC deutlich schneller als meine 5,6 MB/s. Nur sind die Writes in meinem Anwendungsprofil TOTAL unwichtig gegenüber den Reads. 100 Stück 4k random writes dauern bei mir 71 ms - das ist ein Zehntel eines Wimpernschlags. Hier würde ich in der Realität den Unterschied zur aktuellen MLC NICHT merken! - Aber alle meine Programme und mein System würde mit einer aktuellen MLC LANGSAMER starten!

Das zauberwort heisst NCQ... 160MB/s der oben erwähnten mlc intel sind schneller als deine 30-40MB/s 4k read.


Aber was mache ich hier überhaupt.

Das ist eine gute Frage... :fresse:

Ich merke schon, du bist kein Wissenschaftler und an einer ernstzunehmenden Diskussion nicht interessiert.

Du glaubst nicht wie viele Mtron-Besitzer (und Verkäufer) sich hier schon beschwert haben. Bisher konnte mich keiner überzeugen.

Du verdrehst die Tatsachen und behauptest die 60 IOPS (bei meiner übrigens 180, aber egal) wären ein festes technisches Datum, und suggerierst es würde für alle Test File Sizes gelten. Was falsch ist. Es steht weder in einer Rubrik technische Daten, noch ist gilt es für alle Test Sizes - es ist EIN Benchmark für EINE Test File Size. Deine UNZULÄSSIGE Verallgemeinerung dieses und deines Benchmarks sind NACHWEISLICH falsch - ich habe dir zwei voneinander unabhängige Beweise geliefert (Bootvis, CDM) und eine Erklärung, die die Ergebniss deines und Mtrons Benchmark einschliesst. Du versuchst dich hier nur mit absurden Konstrukten rauszureden und lässt dir vage Erklärungen.... Cache.... einfallen, die beim einfachsten kritischen Hinterfragen als FALSCH enttarnt werden.

Wieso für alle? 180iops stehen im Datenblatt für 1GB. Meine Teströße ist ziemlich exakt 1GB. Der im Datenblatt angegebene Wert entspricht exakt dem was ich messe. Also ich find das gut.
 
Zuletzt bearbeitet:
oh oh, da sollte wohl jemand mal das fenster öffnen und tief luft holen ^^

@ Grummel, dann nutze den ASS bench nicht und gut is, ich für meinen fall nehm keinen einzigen Benchmark zu 100% ernst, egal welcher.
Mir dienen die ganzen Disk Benchmarks nur als mittel mir mögliche einbrüche zu zeigen die meist gar nicht wahrnehmbar sind (weils immernoch pfeilschnell) is und das auch nur um evtl. probleme zu erkennen bzw um diese einbrüche hinterfragen zu können....
Das ganze Leben ist ein Beta test ^^

PS:

Wie realitäts nahe ein bench ist der den cache mit mist sieht man recht gut an ATTO (ich vermute mal der mist hauptsächlich den chache) die ergebnisse die ATTO zb ausspuckt sind so weit weg von der realität wie ich vom kinder kriegen ;)
 
Zuletzt bearbeitet:
Eigentlich wollte ich mich in diesem Thread nicht mehr blicken lassen. Aber da ich noch einen Fehler in meinem letzten Beitrag korrigiert habe, kann ich auch gleich noch einen letzten Beitrag schreiben. Dann verspreche ich, mich hier nicht mehr blicken zu lassen oder zu äußern.

?? properietär=von einer Firma. Jeder Controller ist propertitär.

Ein Indillinx Controller gehört Indilinx und ist damit nicht proprietär von OCZ, STT, Soliddata etc. Der Mtron Controller wird nur von Mtron benutzt. Und (leider) weiß niemand so richtig genau, was das Ding kann und was nicht.

Vielleicht ist sogar ein Vorform des Write Combining implementiert? Wer weiss? Mich wundert z.B. dass ein Benchmark für sequentielle 4k writes in der Anleitung meiner Mtron angegeben wird. Vielleicht sammelt der Controller ja 4k writes und schreibt sie am Stück? Dumm wäre das ja nicht. Und letztendlich haben schon meine alten HDDs die Dateien von installierten Programmen möglichst an einem Stück auf die HDD plaziert. Für den sequentiellen 4k write (nicht zu verwechseln mit dem sequentiellen write) sind bei meiner SSD (6025, nicht 3XXX) übrigens 17.000 IOPS angegeben.

Zu beachten: CDM führt keinen test vollständig aus. Rechne mal aus wie viel es dauern würde 1GB mit 0,5MB/s auf die SSD zu schreiben und messe mit stoppuhr nach wie lange CDM dafür braucht. Ich kann eben nicht sagen was CDM da misst wenn du 50MB einstellst. Ob er da 5MB schreibt oder 30MB? oder 100MB? Anscheined bezieht sich die Angabe nicht auf die tatsächlich geschriebene/gelesene Daten sondern auf den zu testenden Bereich. Also der legt eine 100MB Datei an und testet da drin. Wie viel in wirklichkeit geschrieben/gelesen wird weiss man nicht.

In der Tat, das ist mir auch aufgefellen, nachdem ich mir die Bootvis IOPS Säulen angeschaut habe. Nichtsdestotrotz werden von zwei verschiedenen Programmen auf zwei komplett unterschiedliche Arten und Weisen höhere Übertragungsraten / IOPS als dein Benchmark suggeriert gemessen. Und mit einer Summe von ca. 10.000 IOPS in ein paar Sekunden geht offensichtlich (und nachweislich) eine irrwitzige Anzahl an 4k writes durch die SSD.

Bisher nur CDM. Bei Bootvis sind alle möglichen Caches und optimierungen an. Was das zeigt ist ziemlich fraglich.

Bootvis protokolliert nur meinen Start. Es optimiert nichts ( - o.k., es hat auch eine Funktion um die Bootzeit zu optimieren, was leider nicht funktioniert - passiert nicht beim Protokollieren eines Starts).

Ich beobachte mit Bootvis ja nur, was während der Ausführung eines 4k random write CDM Tests passiert. Und Botvis zeigt mir explizit, dass dabei über 2.000 IOPS ausgeführt werden. Und unterstützt damit, dass die gemessenen Werte von 5,6 MB/s korrekt sind.

Sich dann hinzustellen und zu sagen, nein, da sind irgendwelche ominösen Caches und Optimierungen am Werk ist doch Unsinn. Ich meine ich habe es doch schwarz auf weiß. Genauso wie CDM schwarz auf weiß eine 5,6 MB/s Übertragungsrate liefert.

Und letztendlich hast du dich zwischendurch ja selbst verplappert:

Solange die 4k-writes im cache (32MB ist der glaube) landen könnens schon 2000iops und sogar viel mehr sein. ....

Mehr sag ich ja nicht.

Wie gesagt typische Softwareinstallation ist größer als 100MB.

Und wie gesagt, bestehen diese 100 MB nicht aus 4k random writes. Und die Dateien erscheinen auch nicht am Stück in der Warteschlange. Noch nicht einmal annähernd.

Ich weiss dass 1gb 4k-random write praktisch niemals in der praxis vorkommt. 100MB übrigens auch nie.

Na also, da sind wir uns doch einig.

Eine X25-M ist im AHCI modus schneller(160MB/s 4k random read bei 64 threads,258MB/s seq).

Das zauberwort heisst NCQ... 160MB/s der oben erwähnten mlc intel sind schneller als deine 30-40MB/s 4k read.

NEIN, nicht in meinem System - und ich habe explizit geschrieben, dass es für MEIN System (und ich habe nur von meinem System gesprochen) keine schnellere aktuelle MLC als meine "uralte" Mtron gibt. Ich habe lang und breit erklärt, dass ich eine Aussage über MEIN System getroffen habe und seine Besonderheiten erläutert.

1) Limitierung der Übertragungsrate auf 82 MB/s - also sind bei mir 160 MB/s gar nicht möglich, und selbst die würde ich im 4k-64 nicht erreichen, denn: 2) Ich habe gar kein AHCI Modus und damit kein NCQ. Und wenn ich ihn hätte würde ich ihn vermutlich so wie viele andere auch deaktivieren. Und selbst wenn ich den ACHI Modus hätte und ihn nicht deaktivieren würde: 3) Mein Anwendungsprofil ist: Desktop Rechner. Ich betreibe hier keinen Server, bei dem 64 Programm simultan auf die Platte zugreifen und ich benutze auch keine Quantum Fireball aus dem Jahr 2001.



Aber die Diskussion zu (3) hattest du ja schon mit 7oby. Egal. Das hast du damals ja auch als Gemecker abgetan und er ist aus dem Thread verschwunden. So wie ich gleich aus dem Thread verschwinden werde. Dann hast du wieder Ruhe. ;)

Und ich überlasse dir das Schlusswort, denn du erklärst letztendlich sehr gut, warum ich in Zukunft CDM als Benchmark einsetzen werde:

Bei allen anderen SSDs außer Mtron und JM602B gibt es keine Probleme und der Benchmark liefert sehr verlässliche Ergebnisse.
 
Zuletzt bearbeitet:
Oi... Grummel... du gibst mir Kopfweh. Soviel Text, nur um zu sagen, was alle bereits wussten: "Benchmarks =/= reale Anwendung".

Wenn du diesen Standpunkt wirklich so beinhart vertrittst, dann sei wenigstens so gründlich und wirf CDM genauso aus dem Fenster und benche überhaupt nicht mehr. CDM stellt die Realität nämlich genausowenig dar.

Ein Benchmarkprogramm verteufeln, welches bei deiner SSD schlechte Werte liefert, und ein anderes als Gegenbeispiel vorzeigen, weil es bei deiner SSD gute Werte liefert, ist nämlich ganz schöne Heuchelei.
 
kann mich da nur anschließen.

wenn ein benchmark genau dann gut wäre, wenn er nur den cache testet dann könnten wird das benchen gleich "cache1 vs cache2" nennen.
 
@ KeinNameFrei + Shagnar

nsa hast sich viel Mühe gegeben, um diesen Bench zu schreiben.
Aber leider gehöre ich auch zu denjenigen, bei denen der Bench nicht konstante Ergebnisse liefert. Bei mir sind die Abweichungen manchmal einfach zu gross, weshalb ich meistens zum aufwändigeren IOmeter und FC-Test greife.


@ nsa

Wäre es möglich, dass der Bench schneller auf "Stop" reagiert?
 
@ KeinNameFrei + Shagnar

@ nsa

Wäre es möglich, dass der Bench schneller auf "Stop" reagiert?

Es reagiert etwa alle 16MB auf stop. Öfter würde Ergebniss verfälschen. Auf Indilinx/Intel ists schnell genug. Mtron misst man eh nicht damit..
 

Also irgendwas is bei der im argen... Lesen schaut soweit OK aus glaub ich, nur die Schreiben Werte sind GUT unter DUrchschnitt.
Das spiegelt auch der CDiskmark ganz gut wieder:


Es ist ne Kingston SSDNOW (Intel G1) Füllgrad ist wie auf CDM zu erkennen 77%.
Noch hab ich die 14 Tage Frist nicht erreicht und ich würde gerne von euch wissen ob damit was im argen ist?
Außerdem bemerke ich manchmal so kleinere Freezes, zb wenn ich den PC starte nach dem logon läd er 1sek, dann hängt alles für 1~2Sek dann geht alles fix weiter und alles ist da.
Das hab ich mit der SuperTalent 128 im Laptop nicht.

MFG Jubeltrubel
 
Zuletzt bearbeitet:
Da ja immer wieder die fragen aufkommen ob man sich im IDE oder AHCI mode befindet (vorallem nach screens vom AS Bench) hab ich was für euch

User Urbmu2K hat ein kleines tool gebastelt das euch anzeigt ob eure laufwerke im IDE oder AHCI mode laufen.

Das ganze sieht dann so aus

puiner6xak3z.png


Hier habt ihr den Link zum Tool.

Somit erhält der Thread auch gleich nen Push, nicht das er noch in vergessenheit gerät ;)
 
Status
Für weitere Antworten geschlossen.
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