Test Intel SSD 670p 1 TB im Test: Lesend die bis dato schnellste QLC-SSD im Parcours

Wow, gar nicht mal so gut...

Wenigstens stimmen die Temperaturen...
 
Kann man drehen und wenden wie man will - QLC erhält nicht den Zuspruch wie erhofft. Aus nachvollziehbaren Gründen
 
  • Gefällt mir
Reaktionen: Carrera124
GrumpyCat schrieb:
Welches Spiel dekomprimiert denn nennenswerte Teile der heruntergeladenen Daten? Ich hatte bisher immer den Eindruck, dass z.B. bei Steam "Plattenplatzbedarf"~="Download-Größe".
GTA V ist ziemlich komprimiert… Aber der Algorithmus von GTA ist auch ein nicht Multitasking entpacker. Wenn du nen Steam Cache Server oder eine echte FTTH Leitung hast pinnt GTAV einen CPU Core auf 100%
 
GrumpyCat schrieb:
Nur so am Rande, Crypto und Compression sind zwei völlig unterschiedliche Paar Schuhe. Crypto hat z.B. gar keine nennenswerten Datenfenster, auf die der Algorithmus zugreifen muss, während Kompression teilweise mehrere MB Working Set hat. Und CPUs mögen AES-spezifische Befehle haben, aber z.B. bzip2-spezifische Befehle haben sie nicht.
Richtig, daran hatte ich nicht gedacht und der Vollständigkeit liefere ich dann noch, für den antiken 2700X, den entsprechenden Benchmark nach.

Für die Standardwörterbuchgröße von 32MB schafft die Mühle immerhin noch 800 Megabyte in der Sekunde zu entpacken. Nicht extrem schnell, aber schnell genug. Jede halbwegs aktuelle CPU "kommt beim Entpacken" natürlich hinterher. Das war mein Punkt^^
 

Anhänge

  • Screenshot 2021-06-12 095559.png
    Screenshot 2021-06-12 095559.png
    27,3 KB · Aufrufe: 294
GrumpyCat schrieb:
Es ist wirklich anscheinend unglaublich schwierig heutzutage, "stimmt" zu schreiben.

Drei Sekunden googeln bringt z.B. das hier: https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/ - älterer Quad Core, um die 25MB/Sek beim bunzip2. Ist auch müßig, denn klar kommt's immer auf den Algorithmus an, auch wenn Dekomprimieren im allgemeinen deutlich simpler als Komprimieren ist. Auf jeden Fall ist das alles nicht so einfach wie "CPU limitiert nie".
Ein ziemlicher nischen Use-Case, aber falls es jemanden interessieren sollte:
Mit einem 3800x komm ich bei der gleichen Aufgabe auf 54.623 MB/s 😁
 
  • Gefällt mir
Reaktionen: 8087
Also ich habe die 1 TB - Variante der 665P im Notebook als Game-Laufwerk verbaut und bin damit sehr zufrieden. Games starten sehr schnell/zügig, Installationen gehen auch flott. In der Praxis dürfte der SLC-Cache relativ selten voll sein. Als System-SSD würde ich sie aber nicht unbedingt verbauen (habe da eine 970 pro verbaut).

Mein Fazit zum Thema QLC-SSDs mit SLC-Cache:
Meistens ausreichend und brauchbar, aber bitte mehr Modelle mit höheren Kapazitäten (4 - 8 TB) mit einem "vernünftigen" P/L- Verhältnis.
 
Marcel55 schrieb:
Also von daher vielleicht eine günstige Alternative, wenn sie denn günstig wäre.
Das ist der Teil, den ich nicht verstehe - meiner Kenntnis nach war nur die 660p für einige Zeit preislich interessant, ansonsten sind QLC SSDs von jedem Hersteller einfach zu teuer im Vergleich zur Konkurrenz.

Technisch bin ich überzeugt von QLCs, die Schreibschwäche ist für 98% aller Nutzer unwesentlich.
 
  • Gefällt mir
Reaktionen: GrumpyCat und Mummi74
8087 schrieb:
Für die Standardwörterbuchgröße von 32MB schafft die Mühle immerhin noch 800 Megabyte in der Sekunde zu entpacken. Nicht extrem schnell, aber schnell genug. Jede halbwegs aktuelle CPU "kommt beim Entpacken" natürlich hinterher. Das war mein Punkt^^
Was ist das für ein komischer Benchmark?

Z.B. time pixz -d < linux-5.4.52.tar.xz > /dev/null schafft hier auf einem 6-Kern-Ryzen rund 75MBytes/Sek. Mit 100% Last auf allen Kernen. Das ist sogar weniger, als ich getippt hätte...

Davon ab ist es wohl etwas naiv, davon auszugehen, dass Spieleanbieter an der Stelle krass optimieren würden. Siehe nur z.B. die Sache mit GTA letztens. Da kann man schon froh sein, wenn das Download-Tool des Spiels nicht in brainfuck geschrieben ist und per WebAssembly cross-compiled und single threaded in einem internen WebView im Updater läuft...
 
GrumpyCat schrieb:
Was ist das für ein komischer Benchmark?

Z.B. time pixz -d < linux-5.4.52.tar.xz > /dev/null schafft hier auf einem 6-Kern-Ryzen rund 75MBytes/Sek. Mit 100% Last auf allen Kernen. Das ist sogar weniger, als ich getippt hätte...

Davon ab ist es wohl etwas naiv, davon auszugehen, dass Spieleanbieter an der Stelle krass optimieren würden. Siehe nur z.B. die Sache mit GTA letztens. Da kann man schon froh sein, wenn das Download-Tool des Spiels nicht in brainfuck geschrieben ist und per WebAssembly cross-compiled und single threaded in einem internen WebView im Updater läuft...
7zip. Würde nicht sagen, dass das ein komisches Programm ist.
 
GrumpyCat schrieb:
Z.B. time pixz -d < linux-5.4.52.tar.xz > /dev/null schafft hier auf einem 6-Kern-Ryzen rund 75MBytes/Sek. Mit 100% Last auf allen Kernen. Das ist sogar weniger, als ich getippt hätte...
time xzcat linux-5.12.10.tar.xz > /dev/null

real 0m7,414s
user 0m7,338s
sys 0m0,072s

ls -lh linux-5.12.10.tar
-rw-r--r-- 1 user group 1022M 12. Jun 17:54 linux-5.12.10.tar

=> 137,85 MB/s

Die Werte oben kommen von einen i5-8265U. ;)
xz verwendet beim Dekomprimieren nur einen Thread, beim Komprimieren können hingegen mehrere Kerne verwendet werden.

In der Regel ist nicht die Bandbreite der Netzwerkanbindung oder die gewählte Kompression die Ursache für eine ausgelastete SSD, sondern die Art und Weise der Zugriffe.

Wenn Valve Steam nicht angepasst hat, dann schaut euch einmal die Zugriffsmuster von Steam unter Windows an.
 
Hallo32 schrieb:
Die Werte oben kommen von einen i5-8265U.
Ah. Die 75MBytes/Sek bei mir bezogen sich auf die verarbeiteten komprimierten Daten, also macht das rund 550MBytes/Sek unkomprimierte Ausgabe in dem Fall.

Das wird aber bei Spiele-Downloads so nie passieren, weil wie bereits festgestellt die Daten nicht komplett unkomprimiert auf Platte landen. Auch Texturdaten etc. gehen direkt komprimiert an die Grafikkarte.

Bei Updates (via Steam etc.) wird das nochmal komplizierter, weil dann ein froher Mix aus Suche+Entpacken+Patchen+Packen+Kopieren+Schreiben stattfindet.
 
GrumpyCat schrieb:
Ah. Die 75MBytes/Sek bei mir bezogen sich auf die verarbeiteten komprimierten Daten, also macht das rund 550MBytes/Sek unkomprimierte Ausgabe in dem Fall.
Okay, dann ist es natürlich etwas anderes.
 
Zurück
Oben