SSD Preisentwicklung

SeppJ

computertrolls schrieb:

Ne, Echtzeitkompression wollte ich jetzt nicht verwenden.

Warum so pauschal ausschließen? Kompression von Daten war schon immer ein gutes Mittel zur Performancesteigerung, auch wenn es zunächst widersinnig klingt. Denn meist ist (mit großem Abstand!) der Transport großer Datenmengen der Flaschenhals eines Systems, nicht die Rechenzeit. Du könntest CPU-Wartezeit gegen echte Zeitvorteile tauschen.

PS: Das hilft auch erstaunlich gut bei Numbercrunchingproblemen. Wenn hier im Forum mal wieder die Performance von Primzahlsieben verglichen wird, gewinnen stets Lösungen mit vector<bool>, egal wie hirnrissig das klingen mag.

Der Grund ist schlechte Erfahrung mit der Kompression von Daten.
Die Kompression erhöht die Komplexität und die kann im Worst Case Fall, insbesondere wenn die HW selbst z.b. keinerlei Schutzmechanismen wie z.B. ECC Ram etc bietet, zu Fehlern und somit zu Datenverlust führen.

Früher habe ich z.B. die Kompression für 3,5" Disketten verwendet, da Disketten selbst kein besonders zuverlässiges Medium waren führte ein Fehler an der Diskette zu einem Datenverlust.
Der wäre aber noch nicht so schlimm gewesen, wenn die Daten unkomprimiert vorgelegen hätten, dann hätte man noch einen großen Teil retten können, aber in dem Fall gab die Kompression den Daten den Rest und zwar allen Daten.

Aus dem Grund verwende ich eine Kompression auf dem Datenträger ungern und wenn dann nur mit eingebauter Fehlerkorrektur bei Daten die ich überschauen kann, also einzelne ZIP Archive. Aber ganze Partitionen möchte ich damit nicht komprimieren.

Ich stimme dir aber zu, dass man so die Daten wesentlich schneller in die CPU schaufeln kann und die CPU das auch problemlos packen würde, das in Echtzeit und im Bedarfsfall zu entpacken.

hustbaer

computertrolls schrieb:

Der wäre aber noch nicht so schlimm gewesen, wenn die Daten unkomprimiert vorgelegen hätten, dann hätte man noch einen großen Teil retten können, aber in dem Fall gab die Kompression den Daten den Rest und zwar allen Daten.

Das Problem hast du mit SSDs potentiell sowieso. Wenn in den Mapping-Tables irgendwas draufgeht ist die ganze SSD im Eimer. (Weswegen SSDs aber auch ordentlich Fehlerkorrekturdaten für die Daten haben.)
Ebenso mit HDDs die NVRAM für das Bad-Sector Mapping verwenden. (Oder für generelle Mapping-Tables, wie z.B. bei Shingled Magnetic Recording Laufwerken *schauder*.)

computertrolls schrieb:

Aus dem Grund verwende ich eine Kompression auf dem Datenträger ungern und wenn dann nur mit eingebauter Fehlerkorrektur bei Daten die ich überschauen kann, also einzelne ZIP Archive. Aber ganze Partitionen möchte ich damit nicht komprimieren.

NTFS komprimiert nicht die gesamte Partition, sondern die Daten in den Files, und das noch dazu in relativ kleinen Blöcken. Bei 4K Cluster Size (und darüber) sind die komprimierten Blöcke 64 KB gross. Die Blöcke werden einzeln und unabhängig voneinander komprimiert. Anders wäre es auch gar nicht möglich auch nur halbwegs akzeptable Performance hinzubekommen. Verzeichnisstrukturen werden soweit ich weiss gar nicht komprimiert. Und du kannst pro Verzeichnis (bzw. wenn du willst sogar pro File) die Komprimierung aktivieren/deaktivieren.

Aber lies einfach selbst, gibt ja einige Seiten mit Informationen zu dem Thema, z.B.:
https://superuser.com/questions/1136329/ntfs-compression-on-ssd-ups-and-downs
Bzw. den dort verlinkten MS Blog Artikel
https://blogs.msdn.microsoft.com/ntdebugging/2008/05/20/understanding-ntfs-compression/

computertrolls schrieb:

Ich stimme dir aber zu, dass man so die Daten wesentlich schneller in die CPU schaufeln kann und die CPU das auch problemlos packen würde, das in Echtzeit und im Bedarfsfall zu entpacken.

Hätte ich anders eingeschätzt, aber anscheinend habt ihr Recht: http://www.tomshardware.com/reviews/ssd-ntfs-compression,3073.html
Es ist zwar mit Komprimierung fast alles langsamer, aber nur etwas langsamer.
Bei sehr schnellen SSDs würde ich mir aber echt Einbrüche erwarten. Ich mag mich täuschen, aber ich kann mir einfach schwer vorstellen dass auch mit Komprimierung 2-3 GB/s drinnen sind - was ja einige SSDs durchaus schaffen.

Hm, dann frage ich mal so:
Verwendet jemand von euch die NTFS Compression und wie sind eure Erfahrungen, auch Langzeiterfahrungen damit?

Dann wäre mir persönlich noch ein Punkt sehr wichtig. Kann man von Linux aus auf NTFS Partitionen schreibend zugreifen, wenn diese NTFS Compression verwenden und ist das ausgreift und zuverlässig?
Falls das nicht geht, dann wäre die NTFS Compression gar keine Option für mich.

Um nochmal auf folgenden Punkt zurückzukommen:

Dravere schrieb:

Es gibt Berichte davon, dass man bei ARK gut 50% Speicherplatz sparen kann.

Das würde bedeuten, dass für Ark so gut wie keinerlei Kompression bei den Dateiformaten verwendet wird.
Den Großteil an Daten dürften heutzutage Texturen und Sounddateien ausmachen, die könnte man aber alle problemlos komprimieren. Schade dass das bei Ark scheinbar nicht gemacht wird.

hustbaer

computertrolls schrieb:

Den Großteil an Daten dürften heutzutage Texturen und Sounddateien ausmachen, die könnte man aber alle problemlos komprimieren. Schade dass das bei Ark scheinbar nicht gemacht wird.

Auch unkomprimierte Texturen und Sounddateien sind mit verlustfreien, generischen Algorithmen quasi nicht komprimierbar. Von 50% over-all compression auf "Texturen und Sounddateien werden scheinbar nicht komprimiert" zu schliessen ist also unsinnig.

hustbaer schrieb:

computertrolls schrieb:

Den Großteil an Daten dürften heutzutage Texturen und Sounddateien ausmachen, die könnte man aber alle problemlos komprimieren. Schade dass das bei Ark scheinbar nicht gemacht wird.

Auch unkomprimierte Texturen und Sounddateien sind mit verlustfreien, generischen Algorithmen quasi nicht komprimierbar.

Das halte ich für ein Gerücht.

Nimm mal ein beliebiges unkomprimiertes Foto und speichere es als PNG Datei ab.
Anschließend vergleiche die beiden Dateigrößen, die PNG Datei wird zwar nicht die Ergebnisse einer verlustbehafteten Kompression, wie das klassische JPG erreichen, aber trotzdem mehr als genug die Datei komprimieren.

Außerdem habe ich in meinem Posting darüber hinaus nicht einmal die verlustlose Komprimierung gemeint, sondern die verlustbehaftete, die noch stärker komprimiert. S3TC und die dafür üblichen Dateiformate dürften dir sicher bekannt sein.

hustbaer

computertrolls schrieb:

hustbaer schrieb:

computertrolls schrieb:

Den Großteil an Daten dürften heutzutage Texturen und Sounddateien ausmachen, die könnte man aber alle problemlos komprimieren. Schade dass das bei Ark scheinbar nicht gemacht wird.

Auch unkomprimierte Texturen und Sounddateien sind mit verlustfreien, generischen Algorithmen quasi nicht komprimierbar.

Das halte ich für ein Gerücht.

Nimm mal ein beliebiges unkomprimiertes Foto und speichere es als PNG Datei ab.
Anschließend vergleiche die beiden Dateigrößen, die PNG Datei wird zwar nicht die Ergebnisse einer verlustbehafteten Kompression, wie das klassische JPG erreichen, aber trotzdem mehr als genug die Datei komprimieren.

Was meinst du warum ich generische Algorithmen geschrieben habe? Weil File-System Compression eben generische Algorithmen verwenden. Und es ging schliesslich um File-System Compression.
PNG dagegen ist spezifisch für Bilddaten.

computertrolls schrieb:

Außerdem habe ich in meinem Posting darüber hinaus nicht einmal die verlustlose Komprimierung gemeint, sondern die verlustbehaftete, die noch stärker komprimiert. S3TC und die dafür üblichen Dateiformate dürften dir sicher bekannt sein.

Ist schon lustig wenn man jemandem erklären muss wovon er eigentlich gesprochen hat...

* Dravere hat geschrieben dass man mit NTFS Compression bei ARK gut 50% rausholen kann.
* Du wolltest daraus den Schluss ziehen dass ARK "so gut wie keinerlei Kompression bei den Dateiformaten" verwendet, und hast dann weiter angemerkt dass der Grossteil der Daten Texturen und Soundfiles sind und man die "problemlos komprimieren" könnte.

Das heisst du unterstellst ARK dass es "so gut wie keine" Kompression für Texturen und Soundfiles verwendet, und begründest diese Understellung mit dem Umstand dass NTFS Compression die Daten von ARK auf etwa 50% komprimieren kann. Was bedeuten würde dass NTFS Compression Texturen und Soundfiles gut komprimieren kann. (Natürlich verlustfrei, da File-System Kompression ja wohl völlig transparent, d.h. auch bitgenau=verlustfrei arbeiten muss.)

Das ist allerdings völliger Unsinn, und ich habe versucht dir zu erklären warum.

hustbaer schrieb:

Das heisst du unterstellst ARK dass es "so gut wie keine" Kompression für Texturen und Soundfiles verwendet, und begründest diese Understellung mit dem Umstand dass NTFS Compression die Daten von ARK auf etwa 50% komprimieren kann.

Dann erkläre doch du mal, wo die 50 % herkommen sollen.
Die EXE ist es bestimmt nicht und ich glaube nicht, dass 3d Geometriedaten oder XML Dateien bei Ark so viele GB benötigen, dass damit am Ende eine Einsparung von 50 % rauskommt.
Es können nur Texturen und Sounddateien sein, weil das bei einem Spiel für gewöhnlich der dickste Platzfresser ist.
Von Videos mal abgesehen, aber die hat heute eh kaum noch ein modernes 3d Spiel.

Wenn du jetzt die 50 % an sich ankreidest, ich habe das nicht geprüft, ich vertraue hier den Daten von Dravere und das seine Aussage hier stimmt.

hustbaer

Ist mir doch Schnuppe wo die 50% herkommen. Ich wollte dir nur zeigen dass die "Logik" die du hier angewendet hast vollkommen krumm ist.

Dravere

computertrolls schrieb:

Dann erkläre doch du mal, wo die 50 % herkommen sollen.

Prüf es doch mal kurz nach, statt wilde Vermutungen und Behauptungen aufzustellen. Entweder durch Rechtsklick der Ordner und dem finden der grössten Ordner im Spiel oder zum Beispiel mit einem Tool wie WinDirStat.

Was ich so las, sind es anscheinend vor allem die Kartendaten, welche unglaublich gross und unkomprimiert rumliegen. Was somit auf Geometriedaten oder ähnliches zurückschliessen lassen würde. Aber statt dem nachzugehen, schliesst du es einfach aus? Ich habe ARK derzeit nicht installiert und kann es daher nicht selber prüfen.

Also gut:

/ARK $ du -sm *
144     _CommonRedist
247     Engine
4       PackageInfo.bin
115652  ShooterGame
2       Tools
1       version.txt

$ cd ShooterGame/
$ du -sm *
1       AssetRegistry.bin
687     Binaries
2       Config
48015   Content
760     Saved
66191   SeekFreeContent
1       ShooterGame.uproject

$ cd SeekFreeContent
$ du -sm *
28724   Maps
33482   Mods
3986    PrimalEarth

$ cd ..
$ cd content
$ du -sm *
1       Cookinfo.bin
47      Effects
1356    EndGame
8       ExampleContent
15      FirePack
109     GunImpacts
696     Localization
3708    Maps
12288   Mods
26      Mountains
351     Movies
5       Ocean
53      Ogg
96      OldAssets
23176   PrimalEarth
514     ReflectionCaptures
1       Repros
5495    ScorchedEarth
2       Splash
6       SplatterDecals
32      steampunk_pack
36      Ultimate_Rocks
7       WoodenPropPack

Die Maps sind in der Tat groß, allerdings kann da alles mögliche drin verpackt sein, auch Texturen.

UnrealEdit habe ich nicht installiert und werde ich auch nicht installieren um jetzt nachzuschauen. Mal abgesehen davon, dass ich nicht weiß, ob man den noch einfach so downloaden kann. Das letzte mal als ich mit UnrealEd gearbeitet habe ist schon > 19 Jahre her.

Hier hat mal jemand eine eigene Map für die Unreal Engine erstellt:
https://answers.unrealengine.com/questions/140118/map-file-size-very-large.html

Folgende Grafik lässt darauf schließen, dass die lightmap für die Map bei der UT Engine einen großen Batzen ausmacht.
https://answers.unrealengine.com/storage/attachments/22547-lightmap.jpg

Eine lightmap ist in der Regel auch eine Textur.

Gruum

hustbaer schrieb:

computertrolls schrieb:

hustbaer schrieb:

computertrolls schrieb:

Den Großteil an Daten dürften heutzutage Texturen und Sounddateien ausmachen, die könnte man aber alle problemlos komprimieren. Schade dass das bei Ark scheinbar nicht gemacht wird.

Auch unkomprimierte Texturen und Sounddateien sind mit verlustfreien, generischen Algorithmen quasi nicht komprimierbar.

Das halte ich für ein Gerücht.

Nimm mal ein beliebiges unkomprimiertes Foto und speichere es als PNG Datei ab.
Anschließend vergleiche die beiden Dateigrößen, die PNG Datei wird zwar nicht die Ergebnisse einer verlustbehafteten Kompression, wie das klassische JPG erreichen, aber trotzdem mehr als genug die Datei komprimieren.

Was meinst du warum ich generische Algorithmen geschrieben habe? Weil File-System Compression eben generische Algorithmen verwenden. Und es ging schliesslich um File-System Compression.
PNG dagegen ist spezifisch für Bilddaten.

Also ich das jetzt mal getestet.
Ich habe zwei Fotos als bmp gespeichert, das eine ist scharf, das andere nicht. Beide Fotos waren vorher mit jpeg komprimiert.
Dann habe ich beide Fotos jeweils in einen komprimierten ntfs-Ordner, in ein zip-Archiev (deflate), in ein 7zip-Archiev (LZMA2:24) und in eine png-Datei gestopft.
Folgende Dateigrößen in (MB) sind raus gekommen:

bmp    ntfs   zip    7zip   png
scharf     34,8   30,7   18,6   14,0   13,8
unscharf   34,8   26,5   12,1   9,60   10,7

hustbaer

Hm, interessant. Noch interessanter wäre natürlich wie es mit Bildern aussieht die nicht vorher verlustbehaftet komprimiert waren.
Hätte ich aber trotzdem ganz anders eingeschätzt. Mein Statement, zumindest so wie es formuliert war, ist damit wohl widerlegt.

z.T. prüfen: würde ich, weil es mich interessiert, aber ich besitze ARK überhaupt nicht, und habe auch nicht vor es mir nur zu diesem Zweck zu kaufen.

computertrolls schrieb:

Eine lightmap ist in der Regel auch eine Textur.

Ich muss zugeben an Lightmaps habe ich nicht gedacht. Und dass man Lightmaps u.U. sehr gut komprimieren kann, evtl. auch mit so etwas einfachem wie dem Algorithmus den NTFS verwendet, kann ich mir noch eher vorstellen. Also eher als "normale" Texturen die typischerweise aus Fotos erstellt werden.

hustbaer schrieb:

computertrolls schrieb:

Eine lightmap ist in der Regel auch eine Textur.

Ich muss zugeben an Lightmaps habe ich nicht gedacht. Und dass man Lightmaps u.U. sehr gut komprimieren kann, evtl. auch mit so etwas einfachem wie dem Algorithmus den NTFS verwendet, kann ich mir noch eher vorstellen. Also eher als "normale" Texturen die typischerweise aus Fotos erstellt werden.

Gut, ich denke dann sind wir uns einig.

Bei normalen Texturen möchte ich aber noch anmerken, dass die im Normalfall im Gegensatz zu Fotos mit einer vollständigen Bildszene, oftmals repetitiv sind und einen bestimmten Farbton aufweisen.
Eine Textur, die bspw. eine rote Mauer aus Backsteinen darstellen soll, dürfte aus vielen Rottönen und wegen den einzelnen Backsteinen aus sich wiederholenden Elementen bestehen.
Ich kann mir gut vorstellen, dass man auch so etwas mit generellen Kompressionsalgorithmen deutlich besser komprimieren kann, als ganze Bildszenen die bspw. aus völlig unterschiedlichen Elementen (z.B. ein grüner Baum, ein rotes Haus, ein silbernes Auto, ein blauer See, ein Sonnenschirm etc.) bestehen.

Häufig hört man daher auch von Contenterstellern, dass Fotos für Texturen oftmals gar nicht so gut geeignet sind und solche Texturen daher bevorzugt mit Algorithmen und Programmen die dafür spezialisiert sind erstellt werden.
Vor allem gibt es bei solchen Mauertexturen die zwingende Anforderung, dass man sie nebeneinander legen kann, ohne das dabei ein bestimmtes Muster bezüglich der Texturkanten erkennbar wird.

computertrolls schrieb:

Ich kann mir gut vorstellen, dass man auch so etwas mit generellen Kompressionsalgorithmen deutlich besser komprimieren kann, als ganze Bildszenen die bspw. aus völlig unterschiedlichen Elementen (z.B. ein grüner Baum, ein rotes Haus, ein silbernes Auto, ein blauer See, ein Sonnenschirm etc.) bestehen.

Gehört zu den Grundlagen von Komprimierung. Ist mit das erste was man lernt wenn man sich damit befasst, gleiche Teile zusammenfassen und beschreiben was es darstellen soll. Vielleicht findest du was auf Wikipedia dazu.