SSD Preisentwicklung



  • Was meint ihr, wann wird man 1 TB große Marken SSDs, z.B. die EVO Serie von Samsung für unter 150 € kaufen können?



  • Würde schätzen > 3 Jahre.
    Why?



  • Ich müsste mal wieder meinen SSD Speicherplatz vergrößern.
    Für Spiele habe ich eine 379 GB große Partition auf meiner 1 TB SSD eingerichtet, aber die Spiele werden leider auch immer größer, so dass ich ständig wieder irgendein Spiel löschen muss, nur damit das ein oder andere Spiel upgedated werden kann.

    Um nur mal ein Beispiel zu nennen, ARK.
    117 GB nur für ARK + Scorched Earth + Primitive+ ist nicht mehr normal.
    Und leider kann man die DLCs nicht mehr deinstallieren, sondern nur deaktivieren. Es wird jedenfalls kein Speicherplatz frei, wenn man die DLCs deaktiviert und das Update hängt, weil der Speicherplatz nicht ausreicht.

    Das hat jetzt zur Folge, dass ich ein anderes Spiel mit Priorität zu Ende spielen muss, damit wieder Platz frei wird, ich hoffe das reicht dann.
    Ansonsten könnte ich noch probieren ARK zu löschen und dann frisch, aber ohne DLCs zu installieren.


  • Administrator

    Eine Möglichkeit wäre NTFS Compression zu verwenden. Es gibt Berichte davon, dass man bei ARK gut 50% Speicherplatz sparen kann. Wenn du eine gute CPU hast, sollte es auch kaum bemerkbar sein.



  • Warum verwendest du für derzeit nicht verwendete Spiele nicht einfach eine HDD? Die meisten Spiele lassen sich sehr einfach kopieren (also die speicherlastigen Spieldaten wie Texturen, etc.)?
    Ansonsten laufen eigentlich alle Spiele auch komplett auf einer HDD flüssig. Da limitiert üblicherweise eher die GPU, wenn es um FPS geht.



  • Ne, Echtzeitkompression wollte ich jetzt nicht verwenden.

    Hdsd schrieb:

    Warum verwendest du für derzeit nicht verwendete Spiele nicht einfach eine HDD? Die meisten Spiele lassen sich sehr einfach kopieren (also die speicherlastigen Spieldaten wie Texturen, etc.)?
    Ansonsten laufen eigentlich alle Spiele auch komplett auf einer HDD flüssig. Da limitiert üblicherweise eher die GPU, wenn es um FPS geht.

    Ich habe noch eine HD zum reinen Daten auslagern im Rechner, aber das ist eine reine ext4 Partition die ich für Linux verwende. Langfristig will ich die HD aber auch aus dem Rechner entfernen, weil ein Rechner ohne HD einfach viel leiser und somit angenehmer ist.

    Spiele die ich nicht spiele, deinstalliere ich. Bei dem Rest sind es halt Spiele, da kann es spontan dazu kommen, dass ich sie mal spielen will. Deswegen lass ich die alle auf der Spielepartition.


  • Mod

    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.



  • 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.



  • 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.



  • 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.



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


  • Administrator

    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.



  • 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
    

Log in to reply