Neu: AS SSD und CrystalDiskMark Alternative

[Erklärbär]

..oder es ist halt ein Anzeigefehler. Weil das Ergebnis spricht im Durchschnitt ja eher dafür, dass 3x max. gebencht wird und nicht wie optisch angezeigt: 1 -> 1/2 -> 1/2.

edit @DJMCM : 4K Q32T16 im write solltest du dir auch noch einmal anschauen. Liefern bei mir nur knapp 20% dessen, was CDM anzeigt. Read stimmen die Werte exakt sogar bis auf's letzte MB/s!

 

[DJMCM]

oder es ist halt ein Anzeigefehler

Nein, war ein Bug. Ich der neuen Version 1.8.0 habe ich den Fehler schonmal behoben.

Es werden nun auch die Durchschnittswerte und die Maximalwerte nebeneinander angezeigt, so dass es hier weniger Verwirrung gibt.

4K Q32T16 im write solltest du dir auch noch einmal anschauen. Liefern bei mir nur knapp 20% dessen, was CDM anzeigt

Bei mir stimmen die 32T16 eigentlich ganz gut mit CMD überein.
Bei den Q1T1 scheint es aber eine größere Differenz zu geben. Das muss ich mir genauer anschauen.

Und IOPS stimmen auch:

 

[Erklärbär]

Ja, jetzt passt es!

 

[DJMCM]

Bei den Q1T1 scheint es aber eine größere Differenz zu geben. Das muss ich mir genauer anschauen.

In der neuen Version 1.8.1 passen die Werte nun.

 

[massaker]

In der neuen Version 1.8.1 passen die Werte nun.

Danke, gute Arbeit! Die gleiche SSD nochmal getestet (T710@PCIe4x4) und verglichen mit #11 sind die Maximalwerte exakt die selben, aber Random höher und daher nochmals ein höherer Score:

Lade dir mal die neueste Version von meiner App herunter. 😊

Einwandfrei ... endlich pSLC-Test - habe mit der default 40%-Einstellung angefangen -> hat mir 2+ TB vollgeschrieben und wollte gar nicht aufhören, daher manuell abgebrochen, hier mal mit 30%-Einstellung (sollte mMn default sein):

Stimmt ziemlich genau mit meinem Aida64-Test (in #13) überein, jedoch "in schöner" mit besserer Darstellung, vor allem beim Temps-Verlauf, Kudos Markus, 1a Arbeit!
Für genau den gleichen Test wie in Aida64 könnte ich (bei dieser SSD, die so wenig nach pSLC einbricht) also 40 oder 50%-Einstellung auswählen (mit dem Nachteil, dass die SDD komplett vollgeschrieben wird).

P.S.: trotzdem wäre es wünschenswert, dass der Test mehr als "nur 14GB" nach dem Einbruch schreibt, wenigstens 1-2% der Gesamtkapazität (in meinem Fall 40-80GB), so dass man den Temps-Sprung (oder auch Abfall, je nach SSD) besser dargestellt bekommt. Absoluter Traum wäre: Temps für "im Cache" und extra Anzeige für Temps "Nach Einbruch". 😊👍

P.P.S.: oder evlt. einen vollen Dauertest integrieren. Z.B. im Prozentauswahl-Menü einen Punkt "Vollschreiben" integrieren für Leute, die ein "Gesamtbild", wie in Aida64, haben möchten. LG

 

[DJMCM]

hier mal mit 30%-Einstellung

Ich bin mit der Prozent-Einstellung auch nicht ganz glücklich und werde es wahrscheinlich entfernen und standardmäßig auf 30% einstellen.

Kudos Markus, 1a Arbeit

Danke. Hab noch einige Ideen, um das Programm weiter zu verbessern.

trotzdem wäre es wünschenswert, dass der Test mehr als "nur 14GB" nach dem Einbruch schreibt, wenigstens 1-2% der Gesamtkapazität

Ich bin noch am Überlegen, was sinnvoller ist. Eine Zeit also, er misst noch 20 Sekunden nach dem Drop oder er schreibt noch 2% der Gesamtgröße weiter. Ich würde eher die Zeit präferieren.

Absoluter Traum wäre: Temps für "im Cache" und extra Anzeige für Temps "Nach Einbruch"

Siehst du das nicht bereits im Diagramm?

oder evlt. einen vollen Dauertest integrieren. Z.B. im Prozentauswahl-Menü einen Punkt "Vollschreiben"

Ja, gute Idee, werde ich umsetzen. Ich würde aber eher keine Prozentauswahl anbieten, um das Programm einfach zu halten. Einfach einen Button "SSD voll schreiben" und dann schreibt er, bis sie 99% voll ist.

Noch weitere Ideen?

 

[massaker]

Ich würde aber eher keine Prozentauswahl anbieten, um das Programm einfach zu halten. Einfach einen Button "SSD voll schreiben"

Ja, vielleicht einfach 2 Optionen: 1) nur pSLC-Cache Test bis zum ersten Einbruch und 2) Vollschreiben (oder eben 99%).

Siehst du das nicht bereits im Diagramm?

HIER NOCH NICHT. In dem ersten Test (wo ich leider mit 40% getestet habe) sah ich einen rasanten Anstieg innerhalb 15-20 Sekunden bis ca. 65°C und dann ist sehr langsam (solange das Tool ca. 2TB geschrieben hat) bis 70°C gestiegen -> das sieht man hier in dem 30%-Run NOCH nicht, weil diese 14 extra-GB in ca. 4 Sekunden geschrieben wurden -> nur eine Andeutung, dass die Temperatur nach oben schießt.

Danke. Hab noch einige Ideen, um das Programm weiter zu verbessern.

Immer gerne... da mir die Entwicklung der letzten Tage SEHR gefällt, stehe ich gerne zur Verfügung (auch wenn Du die Sprachauswahl erweitern willst, könnte ich helfen - einfach PM).

 

[DJMCM]

@massaker
In der neuen Version 1.10.2 kannst du die SSD nun auch vollschreiben.

Es wird dir auch die Min. und Max. Temperatur angezeigt und außerdem solltest du die Temperatur im Diagramm verfolgen können.

NEU in der Version ist jetzt auch, dass man sein Testergebnis veröffentlichen kann. 😊
Sollte sich das Programm verbreiten und von vielen Leuten genutzt werden, kann man so irgendwann die schnellste SSD ermitteln, da es auch einen Highscore gibt: https://ssd-tester.com/app_highscore.php

 

[DJMCM]

Ich habe jetzt die Version 2 veröffentlicht. Dort finden sich einige neue Features, welche man über den Menüpunkt "Tools" erreicht.

S.M.A.R.T.-Daten und Laufwerkszustand

Error-Scan: fehlerhafte Blöcke erkennen​

Volume mit Zufallsdaten überschreiben​

Latenz und Reaktionszeit​

Details dazu findet man auch auf der Download-Seite: https://ssd-tester.de/app_download.php

Gebt mir gerne Feedback!

 

[Erklärbär]

Mit den Error Scan ist schon einmal ein sinnvolles Feature! 👍
Du hast das alles quasi in "einer Instanz" laufen, also wenn man z.b. den Error Scan im getrennten Fenster ausführt, kann man auf das Hauptfenster nicht mehr zugreifen.
Wäre toll, wenn man das entkoppelt um im Hauptfenster noch Einstellungen vornehmen zu können (zb. Sprache ändern oder Storage switchen usw.), weil sonst muss man immer warten.

Hier mal was das Zhitai Derivat (FN955) ausspuckt:



Latenzen FN955 vs. SN850-X (dreimaliger Durchlauf, von beiden dann das beste Ergebnis):



ps: Kann es sein, dass das Tool immer noch Probleme mit HMB_Mode SSDs hat? 🤔
Egal was ich mache, meine FN955 und S880 haben immer 4K_write Q32T16 absolut andere Werte als bei CDM! Bei den dram_cached SSDs (SN850X und T450) passt es aber konstant:



..vieleicht noch einmal drüber schauen?

 

[DJMCM]

Wäre toll, wenn man das entkoppelt um im Hauptfenster noch Einstellungen vornehmen zu können

Gute Idee, hab ich umgesetzt. So kann man nun auch parallel Scans laufen lassen oder Daten anzeigen.

Kann es sein, dass das Tool immer noch Probleme mit HMB_Mode SSDs hat?

Ja, sorry, da hat sich wieder ein Bug eingeschlichen. In der neuesten Version sollte es nun behoben sein.

 

[DJMCM]

Version 2.2.6 bietet nun einen HTML-Export Der S.M.A.R.T.-Daten und das Speichern als .jpg ist nun möglich:

 

[DJMCM]

Ich habe heute Version 2.3.0 veröffentlicht. Es gibt nun eine neue Funktion zur Diagnose der Schnittstelle.

 

[b99]

schickes kleines Tool... Da merkt man erst, wie langsam mechanische Platten trotz Raid sind:

 

[massaker]

wie langsam mechanische Platten trotz Raid sind

Wobei die Werte trotzdem noch sehr ordentlich ausfallen - und 4K random Lesen ist sogar SEHR GUT. 🤓👍
Dabei wird natürlich lediglich aus dem Cache gelesen - davon hat Dein Raid-Adapter von Broadcom glaub 4GB, sprich: Du hast hier größtenteils nur den Cache Deines Adapters getestet!
Ich frage mich daher eher, was wäre, wenn der Workload >4GB ausfällt... Am besten wäre es also, wenn Du mal mit 8 oder 16GB, im Idealfall sogar gleich mit 32 oder 64GB Testfile-Größe einen Testdurchlauf machen würdest - wäre interessant die Ergebnisse zu vergleichen, LG.

 

[b99]

hör bloß auf. Der Controller ist an den PCIe vom Chipsatz angebunden. Der ist für große Last wie ein Raid absolut unbrauchbar. Ich habe da 4x SEAGATE ST20000NM002D dran. Als Archiv System im System reicht das mir vollkommen. SATA Platten wollte ich nicht einsetzen. Aber von den Werten hier macht der Cache doch eine ganze Menge aus

 

[addey]

Scheint ganz brauchbar zu sein.

 

[DJMCM]

Neu in Version 2.4.0 ist ein Kapazitäts- bzw. Echtheitstest zur Erkennung von Fake-Produkten:

Der Kapazitätstest prüft, ob eine SSD, eine Speicherkarte oder ein USB-Stick tatsächlich den vom Hersteller angegebenen Speicherplatz bereitstellt. Die App beschreibt und kontrolliert die ausgewählten Speicherbereiche. So lassen sich manipulierte oder gefälschte Datenträger entdecken, deren angezeigte Kapazität deutlich größer ist als der real nutzbare Speicher.

 

[Erklärbär]

@DJMCM : Irgend etwas läuft da mit der pSLC Messung bei deinen Tool noch nicht ganz sauber. Ich habe jetzt über den Tag mein 4TB FN955 (Zhitai Derivat) 4x damit eingemessen.
Komplett leere SSD, keinerlei Schreibzugriff darauf. Dennoch 4x unterschiedliche pSLC Limits ermittelt, von absolut unglaubwürdigen 164GB bis annähernd realistischen 963GB pSLC.
Kopiere ich hingegen 2x1TB vC-Container (im Ordner), habe ich konstant den für CE:2_stacked erwartbaren Dropdown bei um die 1100~1150GB.
Mit was für Rohdaten wird da bei deinen Tool eingemessen? 🤔

ps: Gerade, nach 20min. Ruhepause wieder eingemessen, nun sind es 749GB pSLC.

..ich meine, eine Firmware lügt nicht was den NAND betrifft. Erst recht nicht, wenn das die orig. YMTC Enterprise Firmware ist:



Nachtrag: Sehr merkwürdig. Jetzt scheint es wieder zu passen. Schon fast zu gut:

 

[DJMCM]

@Erklärbär Ich habe mittlerweile einige SSDs damit getestet und die pSLC-Erkennung hat immer gepasst (hab es mit HD Tune Pro verglichen).
Wenn du mehrmals hohe Datenmengen auf die SSD schreibst, dann braucht es ja einige Zeit, bis der Controller die Daten aus dem Cache auf die Speicherzellen geschrieben hat. Wie lang das dauert, kann man schwer sagen, aber vermutlich sogar bis zu Stunden. Wenn du also zu früh einen weiteren Test startest, dann hat der Controller noch nicht alle Daten verteilt und der pSLC ist noch nicht leer.
Was ich auch mache, ist, dass ich die SSD vor dem Test formatiere.

Beitrag automatisch zusammengeführt: 01.08.2026

Schon fast zu gut:

Deine Temperaturen schauen auch sehr gut aus 👍

 

[Erklärbär]

Ich habe jetzt noch einmal die S880 den pSLC Cache nachgemessen, nur mal zum "optischen" Vergleich CE:2 Stacked Denser (DualChannel) vs. CE:1 (SingleChannel):



..das ist dann der NAND normaler B-Brand Modelle (Lexar NM790, Fanxiang S880, Ediloca E880 usw.) auch hoher Güte aber halt kein sog. "GoldenWaver" NAND mit besonders hoher Signalqualität (Reinheitsgrad +99,9x) aus der goldenen Mitte, den YMTC normalerweise nur only für deren Zhitai Enterprise Modelle aus der Server Sparte einsetzt. Denn nur mit dem ist dieses CE:2 Stacking möglich.

 

[massaker]

eine Firmware lügt nicht

Bin mir grad nicht sicher, ob die von Dir markierten Stellen was miteinander zu tun haben... 🤔
Außerdem beachte, dass pSLC dynamisch ist - bei solch hochkapazitativen SSD müssen die 20 min. nicht unbedingt GARANTIERT ausreichen um die max. pSLC-Cache-Kapazität frei zu schaufeln. Normalerweise reichen so 10-15 min. - das stimmt, diese Erfahrungen stammen aber von viel kleineren SSDs und die internen Prioritäten können sich von FW zu FW unterscheiden. Evtl. würde das viel schneller gehen, wenn Du gleich SE oder "diskpart->clean" mit einer Partition-Neuerstellung machen würdest, kP.

 

[Erklärbär]

Was meinst du?
Was ich da markiert habe, ist die aktive CE:2 DualChannel Topologie der FN955 (Stacked_Denser). Im Grunde bewirkt auch dies eine quasi Verdoppelung des pSLC Cache.
Eine Lexar NM790, Fanxiang S880, Ediloca E880 usw. sind SSDs mit u.a. OEM Firmware, die können schon rein hardwareseitig gar nicht CE:2 nutzen. Ich habe dir das mal hier aufgedröselt:

Außerdem beachte, dass pSLC dynamisch ist - bei solch hochkapazitativen SSD müssen die 20 min. nicht unbedingt GARANTIERT ausreichen um die max. pSLC-Cache-Kapazität frei zu schaufeln. Normalerweise reichen so 10-15 min. - das stimmt

..ja, dem bin ich mir bewußt, daher hatte ich ja auch geschrieben: "4x über den Tag verteilt".

 

[DJMCM]

Neu in Version 2.5.0: Man kann jetzt alte Dateien auf Geschwindigkeit prüfen:

Hintergrund ist die Problematik, dass es Controller gibt, welche alte Dateien nur sehr langsam lesen können, da sie kein "Refresh" machen:

WD Blue 3D NAND: Vereinzelt Leistungsverlust beim Lesen alter Dateien

Einige Nutzer einer WD Blue 3D SATA-SSD melden Leistungseinbrüche beim Lesen alter Dateien mit Transferraten im einstelligen MB/s-Bereich.

www.computerbase.de

Und es gibt jetzt auch eine Linux-Version davon. Man kann sie hier herunterladen:

SSD-Tester Benchmark App Download

SSD-Tester Benchmark App herunterladen: SSDs, USB-Sticks und externe Laufwerke einfach testen, Ergebnisse vergleichen und Tests dokumentieren.

ssd-tester.de

Da ich mich selber kaum mit Linux auskenne und die App nur portiert habe, würde ich mich über Feedback freuen.

 

[DJMCM]

@Holt Was sagt du eigentlich du dem Programm? Hast du es schon getestet?

 

[Holt]

Nein, ich sehe keine Notwendigkeit für eine Alternative zu den bekannten Benchmark oder S.M.A.R.T. Tools wie AS-SSD, CDM und CDI.

 

[DJMCM]

Nein, ich sehe keine Notwendigkeit für eine Alternative

Interessante Aussage, denn meine Software bringt ja eine Menge mehr Vorteile mit sich und vereint alles in einem Programm.
Du müsstest nicht mehr jedem erklären wie er bei CDI die Rohwerte von HEX auf DEC umstellt oder bei CDM welche Hardware verwendet wird. Außerdem besitzt es Tools, die so in keinem anderen Programm zu finden sind.

Die Interface Diagnose zeigt auf einem Blick ob eine SSD in einem falschen Slot steckt, oder ein USB 3.0 Stick in einem USB 2.0 Slot. So sieht man auf einem Blick, warum eine SSD eventuell langsam ist.

 

[Holt]

bei CDI die Rohwerte von HEX auf DEC umstellt

Hexadezimal machen die Rohwerte aber meist mehr Sinn, wenn nämlich dort mehr als ein Wert drin steht. Dezimal angezeigt machen sie dann nämlich keinen Sinn, denn man erkennt die unterschiedlichen Werte nicht.

7,88GB/s sind übrigens nicht das Payload Ceiling von PCIe 4.0 x4, weil da nur der Protokoll Overhead der 128b/130b Bitkodierung abgezogen ist, aber jeder Layer des Protokolls erzeugt weiteren Overhead und Payload ist, was nach dem ganzen Overhead übrig bleibt und damit keine 7,88GB/s. So sieht das aus:

 

[DJMCM]

was nach dem ganzen Overhead übrig bleibt und damit keine 7,88GB/

Da steht aber eh "before protocol overhead.".

 

[Holt]

Dann ist es aber eben keine Payload, sondern eine Brutto Transferrate. Übrigens kommt zu dem Diagramm in Post #58 noch das SW Protokoll dazu, also NVMe, welches ebenfalls Overhead erzeugt, es muss ja auch Befehle und Adressen an die SSD übertragen.