SLC Cache bestimmen (pSLC) - womit?

[Unipac]

Hallo zusammen,

ich habe bisher HD Tune Pro genutzt, um den (pseudo) SLC Cache zu bestimmen - via File Benchmark Tab. Allerdings hat HD Tune Pro wohl einen Bug: wenn ich größere MB Werte einstelle (z.B. 500000), die geschrieben werden sollen, erhalte ich die FM "I/O Error - Test aborted". Verringere ich die Werte klappt es irgendwann - vielleicht läuft da eine Variable über?
Das Tool ist auch lange nicht mehr gepflegt und daher muss man wohl damit leben. An sich fand ich es aber super, wie es eine schöne Kurve dastellt - so konnte man genau sehen, "wann ein Einbruch" kommt welcher meistens für den pSLC Anteil steht.

Jetzt suche ich eine Alternative, die ebenfalls so eine Schreibkurve darstellt (und eben keine Balken). Oder sonst klar sichtbar auf einen Blick ermittelt, wie groß der pSLC ist.

SSDSlowMark scheint das zu können, sieht aber irgendwie konfus aus und ist Java... würde ich gerne vermeiden, da mein System sonst Java frei ist. Ja, Java ist eine tolle Sprache aber die JRE strotzt nur so vor Sicherheitslücken, die teilweise länger nicht gefixt werden. Aber das ist OT.

Bin gespannt ob es da was gibt. Danke schonmal und einen Guten Rutsch!

UP

PS: falls jemand weiß, wie man das in HD Tune fixt - sehr gerne! Bei meiner Suche bin ich aber nur auf "Bug HD Tune" oder defekte Medien gestoßen...

 

[madmax2010]

je voller die SSD, desto weniger cache.
Normalerweise 10-20%
Sonst kann Fio was du suchst.
Mit fioplot bekommst du auch einen graphen raus
https://github.com/louwrentius/fio-plot

 

[JumpingCat]

Hast du eine Quelle für die ganzen Sicherheitsprobleme bei Java? Meinst du Java allgemein oder virtuelle Maschinen?

Technische Daten von SSD kannst du in Datenbanken wie https://www.techpowerup.com/ssd-specs/kingston-fury-renegade-1-tb.d609 nachschauen.

 

[Mickey Mouse]

ich verstehe dieses ganze Benchmark Gewesel nicht...

was / wen interessiert es, wie viel Cache eine SSD sich gerade dynamisch selbst zugewiesen hat?!?

wenn ich zwei SSDs habe (und viel zu viel Zeit), dann lasse ich die in Real-Life Vergleichen, die dem tatsächlichen späteren Einsatzzweck entsprechen, gegeneinander antreten.

soll das die System-SSD werden, wird nach Bootzeit und z.B. entpacken eines ZIPs geguckt. Ist sie für den Videoschnitt vorgesehen, dann z.B. wie lange es dauert einenClip zu exportieren usw. usf.

was habe ich von der Zahl oder einer Grafik, die mir ein Tool ausspuckt?

 

[massaker]

HD Tune Pro genutzt, um den (pseudo) SLC Cache zu bestimmen - via File Benchmark Tab. Allerdings hat HD Tune Pro wohl einen Bug: wenn ich größere MB Werte einstelle (z.B. 500000), die geschrieben werden sollen, erhalte ich die FM "I/O Error - Test aborted".

Habe das auch festgestellt - "File Benchmark" ist das einzige dort, was ungefähr der realen Nutzung entspricht und zwar mit "random pattern" (sonst können die Controller, die gerne on-the-fly komprimieren, schön verarschen - aktuell Phison-xx und paar Chinesen, glaub Maxio-1602 war's, früher Sandforce-Controller). Leider bei großen Testkapazitäten kommt dieser Fehler, spätestens bei 500-600GB, oft aber schon bei 300-400GB, bis 200-250GB funktioniert es meistens recht gut - hat früher locker gereicht um 500GB-1TB-SSDs mit ihrem typischen statischen 20-70GB pSLC zu testen, heutzutage bei gerne 200-700GB pSLC-Größen (bei 2TB-SSDs, als Beispiel) ist das nicht mehr ausreichend! Andere Tests, wie z.B. "Benchmark" (ohne Partitionen) benutzen Null-Fill/Zero-Pattern und sind leider oft nicht aussagekräftig und eignen sich trotz korrekter Einstellungen höchstens für Lese-Tests (um z.B. schnell die Zellen-Dergadation zu checken), wie hier mit meiner FC530:

Ein Schreib-Test bei dieser FireCuda oder meiner anderen Phison-SSD von Gigabyte ist dagegen totaler Schrott:

Wie man sieht ~6200 MB/s über die ganze Kapazität, was natürlich totaler Unfug ist. Somit ist "File Benchmark" der einzig brauchbarer Test, jedoch leider verbuggt und nur bis 200GB nutzbar.
Aus diesem Grund bin ich jetzt komplett auf Aida64 umgestiegen -> "Werkzeuge" -> "Disk Benchmark" -> (beim ersten Mal Optionen -> "Write Tests" aktivieren) -> (optional Optionen -> "Block Size" auf 8MB stellen oder bei "Auto" belassen) -> "About" -> "Linear Write"-Test auswählen (Achtung! Alle Partitionen werden beim Testen gelöscht!). So bekomme ich die Ergebnisse, die am nächsten zur realen Nutzung sind, z.B. wieder die Seagate FC530:

Nun, nicht jede Version von Aida64 ist perfekt, es gab schon einige Anomalien, aber in 99% der Fälle ist die Kurve korrekt und so kann man die pSLC-Strategie perfekt ablesen.
Habe das bereits hier beschrieben und mit HDTunePro verglichen:
https://www.computerbase.de/forum/t...ps5-tieferlegung.2068731/page-4#post-28056157
Gleich danach im Thread findest Du meinen Vergleich mit dem real-world-Kopieren samt Screenshots:
https://www.computerbase.de/forum/t...ps5-tieferlegung.2068731/page-4#post-28056352

 

[Michael-Menten]

Boot ein live linux und nutz ein FIO-script.
Das Programm spukt dir sowohl ein (hässlichen) Graphen als auch die CSV aus die dann hübsch geplottet werden kann.

 

[jaegerschnitzel]

Aus diesem Grund bin ich jetzt komplett auf Aida64 umgestiegen

Wollte ich auch gerade versuchen, aber AIDA64 bringt bei mir immer einen Fehler.

Process Explorer sagt "Sharing Violation", aber zeigt ansonsten keine Prozesse an, welche auf die Datei zugreifen. Virenscanner etc. auch deaktiviert, aber bringt leider auch nichts.

Hat jemand noch eine Idee?

 

[Unipac]

je voller die SSD, desto weniger cache.
Normalerweise 10-20%
Sonst kann Fio was du suchst.
Mit fioplot bekommst du auch einen graphen raus
https://github.com/louwrentius/fio-plot

Darüber bin ich auch gestolpert, sieht aber bisschen frickelig aus und im Graph sehe ich in den Beispielen nur Time und nicht GBs...

Hast du eine Quelle für die ganzen Sicherheitsprobleme bei Java? Meinst du Java allgemein oder virtuelle Maschinen?

Technische Daten von SSD kannst du in Datenbanken wie https://www.techpowerup.com/ssd-specs/kingston-fury-renegade-1-tb.d609 nachschauen.

Quelle: bei uns in der Firma, die wegen einer Anwendung die JRE brauchen und man mit dem Patchen gar nicht hinterherkommt.... und nur wegen einer App eine JRE installieren die wieder zu patchen ist find' ich overkill.

was habe ich von der Zahl oder einer Grafik, die mir ein Tool ausspuckt?

z.B. wenn Hersteller mit xxxx MB/sec werben - grade auch bei externen SSDs oder USB Sticks - ist so ein Test klasse um zu schauen, was wirklich dran ist. Gibt auch USB Sticks, die schreiben ein paar GB flott und brechen dann auf unter USB 2.0 Speed ein.

Habe das auch festgestellt - "File Benchmark" ist das einzige dort, was ungefähr der realen Nutzung entspricht und zwar mit "random pattern" (sonst können die Controller, die gerne on-the-fly komprimieren, schön verarschen - aktuell Phison-xx und paar Chinesen, glaub Maxio-1602 war's, früher Sandforce-Controller). Leider bei großen Testkapazitäten kommt dieser Fehler, spätestens bei 500-600GB, oft aber schon bei 300-400GB, bis 200-250GB funktioniert es meistens recht gut - hat früher locker gereicht um 500GB-1TB-SSDs mit ihrem typischen statischen 20-70GB pSLC zu testen, heutzutage bei gerne 200-700GB pSLC-Größen (bei 2TB-SSDs, als Beispiel) ist das nicht mehr ausreichend!

Du sprichst mir aus der Seele - genau das beschreibt das Verhalten von HDTune. Ich Schaue mir AIDA64 mal an, danke für den Weg dorthin!

Boot ein live linux und nutz ein FIO-script.
Das Programm spukt dir sowohl ein (hässlichen) Graphen als auch die CSV aus die dann hübsch geplottet werden kann.

zu Fio s.o. - kann man auch für Windows builden, braucht kein Live Linux.

 

[madmax2010]

Graph sehe ich in den Beispielen nur Time und nicht GBs...

es geht dir doch um den Cache, das siehst du an transferrate, Latenzen und iops jeweils hervorragend.
ist auch nicht wirklich kompliziert, in eine config Datei 5 Zeilen einstellungen tippen und laufen lass.

bei uns in der Firma, die wegen einer Anwendung die JRE brauchen und man mit dem Patchen gar nicht hinterherkommt.... und nur wegen einer App eine JRE installieren die wieder zu patchen ist find' ich overkill.

Das hängt an dependencies, Laufzeitumgebung und applicationserver. ggf noch Webserver und Datenbank.
sind dann schonmal ein paar, mehr Komponenten als bei einer kleinen Anwendung die lokal auf dem heimischen PC läuft.
egal welche Programmiersprache und welcher stack, jede Komponente kann jederzeit Sicherheitslücken haben.

Wir lassen die update und deployment skripte alle paar Stunden automatisch laufen und nur selten erfordern in Abhängigkeiten geschlossene Sicherheitslücken, dass der Code angefasst wird.

Wenn euer Entwickler da über Java Flucht, liegt das vermutlich nicht an der Sprache sondern der Anwendung selbst oder an seiner Arbeitsweise.

 

[Mickey Mouse]

z.B. wenn Hersteller mit xxxx MB/sec werben - grade auch bei externen SSDs oder USB Sticks - ist so ein Test klasse um zu schauen, was wirklich dran ist.

das sehe ich eben komplett anders.
so ein Test gibt dir ein mehr oder weniger "hübsches aber sinnloses" Bild.
wenn ich wissen möchte "was wirklich dran ist", dann versuche ich eine möglichst reale Situation nachzustellen und messe wie lange es dauert. Das kann bei drei riesigen Video-Files völlig anders ausgehen als bei Millionen winziger Text-Files, die in Summe genauso groß sind.
Das sagt mir mehr als die tollsten Diagramme.

Gibt auch USB Sticks, die schreiben ein paar GB flott und brechen dann auf unter USB 2.0 Speed ein.

erstens reden wir hier nicht über USB-Sticks, sondern eine SSD, die einen Teil des TLC Speichers als SLC Cache nutzt. Das passiert dynamisch und abhängig vom "Füllstand". Man muss sich also genau überlegen, was und wie man misst. Am Ende gilt der alte Spruch: wer misst, misst Mist
zweitens habe ich bisher gerade bei USB-Sticks dieses Verhalten noch nicht gesehen sondern eher bei den SSDs. Wenn ein Gerät TLC/QLC zu SLC "umfunktioniert", dann muss es ja irgendwann "wenn Ruhe ist", die Daten aus dem temporären Cache in den normalen Speicher umkopieren. Das wäre bei USB Sticks, die man jederzeit abziehen kann, ziemlich gefährlich (kann sein, dass das einige trotzdem machen, hab eich aber wie gesagt bisher noch nicht erlebt)

 

[Unipac]

es geht dir doch um den Cache, das siehst du an transferrate, Latenzen und iops jeweils hervorragend.
ist auch nicht wirklich kompliziert, in eine config Datei 5 Zeilen einstellungen tippen und laufen lass.



Das hängt an dependencies, Laufzeitumgebung und applicationserver. ggf noch Webserver und Datenbank.
sind dann schonmal ein paar, mehr Komponenten als bei einer kleinen Anwendung die lokal auf dem heimischen PC läuft.
egal welche Programmiersprache und welcher stack, jede Komponente kann jederzeit Sicherheitslücken haben.

Wir lassen die update und deployment skripte alle paar Stunden automatisch laufen und nur selten erfordern in Abhängigkeiten geschlossene Sicherheitslücken, dass der Code angefasst wird.

Wenn euer Entwickler da über Java Flucht, liegt das vermutlich nicht an der Sprache sondern der Anwendung selbst oder an seiner Arbeitsweise.

Scheint echt eine Marktlücke zu sein so ein Filebenchmark mit einem sauberen Graphen wie bei HD Tune wenn ich zuerst eine config Datei verstehen muss und die 5 Zeilen braucht bis sie was Ähnliches tut :-)

Zum Java Thema nur ganz kurz da OT: da geht es um die Runtime auf Servern z.B. weil Anwendungen die brauchen, nicht um einen einzelnen Entwickler der flucht (der patcht die Runtime ja nicht). Ansonsten z.B.
https://heimdalsecurity.com/blog/java-biggest-security-hole-your-computer/
Aber wie gesagt, OT und ich habe ja erläutert, weshalb ICH nicht ein zusätzliches Framework wegen einer Anwendungen will, das dazu bekannt ist, regelmäßig neue CVEs zu haben.

das sehe ich eben komplett anders.
so ein Test gibt dir ein mehr oder weniger "hübsches aber sinnloses" Bild.
wenn ich wissen möchte "was wirklich dran ist", dann versuche ich eine möglichst reale Situation nachzustellen und messe wie lange es dauert. Das kann bei drei riesigen Video-Files völlig anders ausgehen als bei Millionen winziger Text-Files, die in Summe genauso groß sind.
Das sagt mir mehr als die tollsten Diagramme.


erstens reden wir hier nicht über USB-Sticks, sondern eine SSD, die einen Teil des TLC Speichers als SLC Cache nutzt. Das passiert dynamisch und abhängig vom "Füllstand". Man muss sich also genau überlegen, was und wie man misst. Am Ende gilt der alte Spruch: wer misst, misst Mist
zweitens habe ich bisher gerade bei USB-Sticks dieses Verhalten noch nicht gesehen sondern eher bei den SSDs. Wenn ein Gerät TLC/QLC zu SLC "umfunktioniert", dann muss es ja irgendwann "wenn Ruhe ist", die Daten aus dem temporären Cache in den normalen Speicher umkopieren. Das wäre bei USB Sticks, die man jederzeit abziehen kann, ziemlich gefährlich (kann sein, dass das einige trotzdem machen, hab eich aber wie gesagt bisher noch nicht erlebt)

Das Bild ist doch nicht sinnlos: wenn ich weiß, dass ich nur xx GB an Cache habe und der Speed danach grottig ist, dann weiß ich auch ob das Produkt für mich oder den Einsatzzweck überhaupt in Frage kommt. Natürlich macht es auch einen Unterschied, wie groß die Dateien sind. Aber wenn nur 1GB Cache vorhanden ist dann wird es danach langsamer. So ein Test ist das Optimalbild - und wenn das schon nix taugt muss ich mit detaillierteren Tests doch gar nicht anfangen.

Es ist ja nicht DER Test, der alles aussagt - das schreibe ich doch gar nirgends. Initial will ich einfach die Cache Size bestimmen können weil das für mich ein Spec ist wie DRAM, Größe, TBW etc. das mich interessiert.

Und externe SSDs haben ebenso pSLC und können einfach abgezogen werden - so wie dein PC auch einfach ausgeht wenn den Stecker ziehst. Das ist also kein auf USB Sticks beschränktes Problem.

Ob das bei USB Sticks dann SLC-cache ist oder sonstwas spielt auch keine Rolle - denn das ist für diese auch typisch, dass sie Anfangs schneller schreiben und dann langsamer. Das Windows-Cache Verhalten ist das auch nicht die Ursache, sonst wären ja alle USB Sticks Anfangs gleich schnell.

Wenn du das bisher nicht hattest ist es dir vlt nicht aufgefallen, bei mir haben das viele Sticks (grade die flotteren) und auch auf Amazon liest man das auch oft.

Beispiel hier ein 128GB Stick, der schreibt 10GB echt flott und dann wird er deutlich langsamer:

Oder hier ein anderer 128er der nur kurz halbwegs flott schreibt. Er scheint auf den 1GB CDM Test, den viele User bei Reviews posten, "optimiert" zu sein weil er den noch mit 50MB/sec schafft.

Hier ein positiv-Beispiel, der den Speed nahezu durchhält (etwas thermisch gedrosselt? Hab ich nicht getestet), der ist aber auch bald 10 Jahre alt:

Wie siehst, ist das bei USB Sticks überhaupt nicht ungewöhnlich und imho auch sinnvoll zu testen. Wenn der sequentiell schon direkt auf 17MB/sec einbricht dann wird er bei einzelnen Dateien wohl eher nicht schneller werden...

Und die Funktion USB Geräte "sicher" auszuwerfen gibt es schon seit Jahrzehnten - auch nicht nur wegen dem OS Cache...

 

[NAME=User]

je voller die SSD, desto weniger cache.

Aus der Angst, gebasht zu werden, für das Ausgraben des alten Threads

Davon habe ich auch schon mal gehört, konnte aber nie direkt einen Beleg dazu finden.

Wenn ich nur noch 10% meiner NVMe SSD an Speicherplatz freihabe, sinkt dadurch automatisch auch der Cache im vergleich zu einer fast leeren Festplatte, und der springt schneller auf die langsameren QLC Speicherzellen?

Ich dachte der Cache hat neben dem Speicherplatz eine feste Größe, und skaliert nicht mit dem freien Speicherplatz, oder ist das eine Neuheit unter NVMe?

Hat das was mit dem Overprovisioning zu tun?

Danke im voraus

 

[massaker]

Hat das was mit dem Overprovisioning zu tun?

Nur theoretisch : je mehr OP, desto größer die theoretische pSLC-Größe. Ist aber eher von SSD zu SSD unterschiedlich.

Ich dachte der Cache hat neben dem Speicherplatz eine feste Größe, und skaliert nicht mit dem freien Speicherplatz, oder ist das eine Neuheit unter NVMe?

Nein, hat nichts mit NVMe zu tun. Anfangs war pSLC tatsächlich nur statisch ausgeführt (und entsprechen sehr klein), aber seit grob geschätzt >5 Jahren gibt es pSLC auch als dynamisch und kombinierte Methoden ebenfalls.

Wenn ich nur noch 10% meiner NVMe SSD an Speicherplatz freihabe, sinkt dadurch automatisch auch der Cache im vergleich zu einer fast leeren Festplatte, und der springt schneller auf die langsameren QLC Speicherzellen?

Generell: Ja. Aber, wie gesagt, hängt überwiegend von der pSLC-Strategie des jeweiligen Herstellers bzw. Models, die er in der FW verankert hat, ab. Z.B. Phison-basierte SSDs neigen dazu bei >95% Belegung den pSLC-Modus vollständig auszuschalten und lediglich direkt in TLC zu schreiben. Bei Samsung-SSDs hast Du dagegen einen kombinierten (statisch+dynamisch) pSLC mit der Marketing-Bezeichnung "Turbo-Write", also sind so einige GBs garantiert schnell, auch bei 99% Belegung.

 

[Denniss]

Dynamischer SLC ist halt im Bereich der normalen Nutzdaten, wenn da kaum noch was frei ist geht der dynamische SLC gegen null.
Statischer SLC ist in einem reservierten Bereich und wird nur dafür genutzt.