Mit praktisch jedem Betriebssystem kann man eine RAM Disk erstellen, die dann einen Teil vom Arbeitsspeicher entweder als fest definierten oder variablen veränderlichen Teil abzweigt und sich dann als RAM Disk wie jeden anderen Datenträger benutzen lässt solange der Strom nicht ausfällt. Und die meisten heutigen Rechner dürften üppig genug RAM haben um so eine RAM Disk ohne nennenswerte Einschränkungen nutzen zu können. Die Frage ist aber, wofür nutzt ihr diese dann? In der Amiga Workbench war die RAM Disk Standard. Der Amiga ist bei dieser Frage jetzt allerdings ausdrücklich nicht gemeint. Ebenso sind mit dieser Frage keine besonderen Formen von Cachingmechanismen für besondere Dateisysteme gemeint. Mich würde eher interessieren, warum ihr heute auf eurem PC, Apple Rechner, ARM usw. eine RAM Disk regelmäßig verwendet und wofür, falls ihr das macht? Was mich betrifft, ich habe eine RAM Disk nur früher unter DOS benutzt, weil man damit Dateien schnell zwischenspeichern konnte. Seitdem aber nicht mehr. Denn die meisten modernen Desktopsysteme sind durch die Zwischenablage auch für Dateien objektorientiert und auch ansonsten schnell genug, so dass ich selbst keinen Anwendungszweck mehr habe. Aber vielleicht sieht das bei euch anders aus.
Nano schrieb: > Was mich betrifft, ich habe eine RAM Disk nur früher unter DOS benutzt, > weil man damit Dateien schnell zwischenspeichern konnte. Das war schon in den letzten DOS-Versionen obsolet, da smartdrv das wesentlich komfortabler konnte. Eine echte RAM-Disk konnte allenfalls dann nützlichxsein, wenn es lediglich um temporäre Dateien ging, die keinesfalls rekonstruierbar sein sollten. In diesem Zusamnenhang entfiel dann die Problematik des sicheren Löschens. Die Auslagerungsdatei von Windows machte auch dieses Konzept zunichte.
:
Bearbeitet durch User
Ich nutze RAM disks auf Systemen in denen ssds verbaut sind, aber zu bestimmten Zwecken temporäre Dateien immer wieder geschrieben werden, die nur während der Laufzeit für ein paar Minuten von Hilfsprozessen benötigt werden. Ziel ist, die SSD zu schonen.
Nano schrieb: > Mich würde eher interessieren, warum ihr heute auf eurem PC, Apple > Rechner, ARM usw. eine RAM Disk regelmäßig verwendet Weil mir die LFS Distro zu viel Arbeit ist. > und wofür, falls ihr das macht?
1 | tmpfs 4087572 2364 4085208 1% /run |
2 | tmpfs 20437860 2452 20435408 1% /dev/shm |
3 | tmpfs 5120 4 5116 1% /run/lock |
4 | tmpfs 20437860 0 20437860 0% /sys/fs/cgroup |
5 | tmpfs 4087572 808 4086764 1% /run/user/1000 |
Nano schrieb: > Die Frage ist aber, wofür nutzt ihr diese dann? Für temoräre Zwischenergebnisse, wenn große Mengen (Bild-)Daten halb-automatisiert verarbeitet werden. Ich habe keine SSD für /home; die RAM-Disk macht sich in der Geschwindigkeit durchaus bemerkbar.
Klar: tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=6144000k) Wie Percy schon schrieb: > Eine echte RAM-Disk konnte allenfalls dann nützlichxsein, wenn es > lediglich um temporäre Dateien ging, die keinesfalls rekonstruierbar > sein sollten. In diesem Zusamnenhang entfiel dann die Problematik des > sicheren Löschens. PC aus -> Daten weg. Und swap unter Linux beim ›Booten‹ einfach mit zufällig konstruiertem Bitmuster verschlüsseln, dann gilt auch da: PC aus -> Daten weg.
Nano schrieb: > Die Frage ist aber, wofür nutzt ihr diese dann? Regelmäßig als temporäres Dateisystem (tmpfs). Heißt nicht RAM-Disk, ist effektiv aber eine (Dateisystem in virtuellem Speicher).
…und wächst bzw. schrumpft bei Nutzung.
1 | # cd /tmp/ |
2 | # free -g |
3 | total used free shared buff/cache available |
4 | Mem: 23 1 21 0 1 21 |
5 | Swap: 8 0 8 |
6 | dd if=/dev/zero of=DUMMY bs=1M count=5000 |
7 | 5000+0 Datensätze ein |
8 | 5000+0 Datensätze aus |
9 | 5242880000 bytes (5,2 GB, 4,9 GiB) copied, 1,26295 s, 4,2 GB/s |
10 | # free -g |
11 | total used free shared buff/cache available |
12 | Mem: 23 1 16 4 5 16 |
13 | Swap: 8 0 8 |
14 | # rm DUMMY |
15 | # free -g |
16 | total used free shared buff/cache available |
17 | Mem: 23 1 21 0 1 21 |
18 | Swap: 8 0 8 |
Beitrag #7010831 wurde von einem Moderator gelöscht.
Man muss die Tatsache das eine Ram-Disk ihre Daten verliert wenn der Strom weg ist, bzw. der Rechner neu startet, als VORTEIL sehen nicht als Nachteil, dann macht heutzutage eine Ram-Disk durchaus Sinn. Ansonsten ist ne schnelle SSD o. M2 besser. Wenn man Firefox z.b. so konfiguriert das das Profil z.b. in der RAM-Disk liegt, dann hat man immer ein sauberes System. Dazu muss man FF nur über eine Batch-Datei starten die vorher das Profil in die Ram-Disk kopiert. Wäre nur eine Anwendung die ich mir da vorstelle. Ansonsten halte ich eine Ram-Disk für nicht mehr Zeitgemäß. Ich habe auf meinen Windows-Rechner (32 GB RAM) auch lange eine gehabt. Dann kam die erste 128 GB SSD und die Ram-Disk war nicht wirklich schneller. Also habe ich sie abgestellt. Kann aber auch am Treiber liegen, den die Ram-Disk ja braucht. Inzwischen habe ich ne 1 TB SSD als C-Laufwerk und die 128 GB hockt in meinen Nebensteckplatz als "Temporäre Schmutzplatte". Da 128 GB nur 17 Euro im Schnitt kosten, würde ich mir die notfalls als "Ram-Disk" extra kaufen + einbauen wenn ich nicht einige übrig hätte.
Dunno.. schrieb: > Ziel ist, die SSD zu schonen. Bei aktuellen SSDs muss man sich darum keine Gedanken mehr machen
Dunno.. schrieb: > Ziel ist, die SSD zu schonen. Dann hast Du bestimmt auch Plastikbezüge über allen Sitzmöbeln.
funky schrieb: > Bei aktuellen SSDs muss man sich darum keine Gedanken mehr machen Bei älteren auch nicht unbedingt. Auf 2 Systemen habe ich jeweils eine Crucial m4 als Systemdisk. Die sind mittlerweile 10 Jahre alt und gemäß SMART nur wenig abgenutzt.
:
Bearbeitet durch User
Man sollte immer daran denken, dass RAM recht vergesslich ist, sobald der Strom weg war.
oszi40 schrieb: > Man sollte immer daran denken, dass RAM recht vergesslich ist Das RAM gut kühlen erspart die USV bei kurzen Stromausfällen. ;-) Für jene, denen auch SSDs zu langsam sind, oder die zu viel Schiss vor Abnutzung haben, gibt es Intels Optane-Speicher. Schnell wie eine RAM-Disk, aber persistent. https://en.wikipedia.org/wiki/3D_XPoint
:
Bearbeitet durch User
Swap wie oben genannt hab ich im RAM als zRAM aber nur aus dem grund das es einige wenige Programme gibt die swap noch brauchen oder wenn beim Kompilieren der RAM voll läuft, dann hab ich noch den Komprimierten zRAM ansonsten fällt mir auch keine sinnige verwendung dafür ein.
funky schrieb: > Bei aktuellen SSDs muss man sich darum keine Gedanken mehr machen Stimmt. Andererseits wird da oft geschrieben, und das System soll über viele Jahre möglichst wartungsarm sein. Vermutlich ist es überflüssig, aber es kostet auch nix.
(prx) A. K. schrieb: > Nano schrieb: >> Mich würde eher interessieren, warum ihr heute auf eurem PC, Apple >> Rechner, ARM usw. eine RAM Disk regelmäßig verwendet > > Weil mir die LFS Distro zu viel Arbeit ist. ? Ich kann dir gerade nicht folgen. In welchem Zusammenhang siehst du eine RAM Disk zu einer Linux from Scratch Distro? Meinst du jetzt das compilen der Pakete damit das schneller geht? >> und wofür, falls ihr das macht? > >
1 | > tmpfs 4087572 2364 4085208 1% /run |
2 | > tmpfs 20437860 2452 20435408 1% /dev/shm |
3 | > tmpfs 5120 4 5116 1% /run/lock |
4 | > tmpfs 20437860 0 20437860 0% /sys/fs/cgroup |
5 | > tmpfs 4087572 808 4086764 1% /run/user/1000 |
6 | > |
Ja gut, das sind die standardmäßig gesetzten RAM Disks die dann von irgendwelchen Programmen benutzt werden. Ich wollte jetzt aber wissen, welche RAM Disk du selber manuell nutzt.
Nano schrieb: > Ich kann dir gerade nicht folgen. In welchem Zusammenhang siehst du eine > RAM Disk zu einer Linux from Scratch Distro? Das war ein indirekter Verweis auf den Umstand, dass man in normalen Distros unweigerlich einen Satz an tmpfs Filesystemen bekommt. Um das unbedingt zu vermeiden, müsste man schon ziemlich Hand anlegen. ;-) > Ich wollte jetzt aber wissen, welche RAM Disk du selber manuell nutzt. Keine. Wozu sollte ich? Das ist IMHO in Thema von gestern, reserviert für spezielle Fälle. Spätestens seit SSDs.
:
Bearbeitet durch User
Bei meinen Raspberry's nutze ich die Ramdisk für die ganzen Protokolle & Temporären Dateien damit mir das Zeug nicht die SD-Karte zerschreibt
;o) schrieb: > Bei meinen Raspberry's nutze ich die Ramdisk für die ganzen Protokolle & > Temporären Dateien damit mir das Zeug nicht die SD-Karte zerschreibt Ja, da ergibt das Sinn.
(prx) A. K. schrieb: > Nano schrieb: >> Ich kann dir gerade nicht folgen. In welchem Zusammenhang siehst du eine >> RAM Disk zu einer Linux from Scratch Distro? > > Das war ein indirekter Verweis auf den Umstand, dass man in normalen > Distros unweigerlich einen Satz an tmpfs Filesystemen bekommt. Um das > unbedingt zu vermeiden, müsste man schon ziemlich Hand anlegen. ;-) Ah so, okay, verstehe. >> Ich wollte jetzt aber wissen, welche RAM Disk du selber manuell nutzt. > > Keine. Wozu sollte ich? Das ist IMHO in Thema von gestern, reserviert > für spezielle Fälle. Spätestens seit SSDs. Danke, das wollte ich wissen.
(prx) A. K. schrieb: > ;o) schrieb: >> Bei meinen Raspberry's nutze ich die Ramdisk für die ganzen Protokolle & >> Temporären Dateien damit mir das Zeug nicht die SD-Karte zerschreibt > > Ja, da ergibt das Sinn. Man könnte aber auch eine SSD per USB anschließen.
Nano schrieb: > (prx) A. K. schrieb: >> ;o) schrieb: >>> Bei meinen Raspberry's nutze ich die Ramdisk für die ganzen Protokolle & >>> Temporären Dateien damit mir das Zeug nicht die SD-Karte zerschreibt >> >> Ja, da ergibt das Sinn. > > Man könnte aber auch eine SSD per USB anschließen. Man könnte auch ein Bus and Tag Interface anschließen und daran ein altes Tape-Archiv. ;-)
Norbert schrieb: > Man könnte auch ein Bus and Tag Interface anschließen Wär aber wohl ein ziemlich dicker Kübel neben dem armen RasPi. Da ist ja schon einer der beiden Stecker allein grösser, von den an Besenstiele erinnernden Kabeln ganz abgesehen. ;-) https://en.wikipedia.org/wiki/Bus_and_Tag
:
Bearbeitet durch User
Es könnte Leute geben, die extra Logs auf vergessliche Ramdisk auslagern?
oszi40 schrieb: > Es könnte Leute geben, die extra Logs auf vergessliche Ramdisk > auslagern? Selbstverständlich! Wenn man bei Entwicklung und Tests Hunderte vom Megabytes (kein Schreibfehler) generiert, so müssen diese zwar ausgewertet aber nicht zwangsläufig für die Ewigkeit aufbewahrt werden. Nur wenn signifikante Dinge auftreten, komprimiert und sichert man die Daten und die Auswertungen. Für später, wenn die Kinder aus dem Haus sind.
Nano schrieb: > Denn die meisten modernen Desktopsysteme sind durch die Zwischenablage > auch für Dateien objektorientiert und auch ansonsten schnell genug, so > dass ich selbst keinen Anwendungszweck mehr habe. Der Zusammenhang dieses Absatzes mit dem Thema RAM-Disk erschliesst sich mir nicht. Die Zwischenablage ist ein Puffer zum Austausch von Daten, kein (logischer) Datenträger wie eine Ram-Disk. Objektorientierung ist ein Programmierparadigma. Verstehe ich hier etwas falsch?
In ganz speziellen Szenarien kann eine RAM-Disk auch heute noch Sinn machen. Wir haben z.B. noch alte 16 und 32 Bit Anwendungen, die unter XP laufen. Ein Programm erfordert zwingend (!) eine 64 MB "große" RAM-Disk. ;-)
Hä? schrieb: > Nano schrieb: >> Denn die meisten modernen Desktopsysteme sind durch die Zwischenablage >> auch für Dateien objektorientiert und auch ansonsten schnell genug, so >> dass ich selbst keinen Anwendungszweck mehr habe. > > Der Zusammenhang dieses Absatzes mit dem Thema RAM-Disk erschliesst sich > mir nicht. Die Zwischenablage ist ein Puffer zum Austausch von Daten, > kein (logischer) Datenträger wie eine Ram-Disk. Objektorientierung ist > ein Programmierparadigma. Verstehe ich hier etwas falsch? Nehmen wir mal an, deine Festplatte war voll und du wolltest 3 große Datei von einer Diskette auf eine andere Diskette kopieren. Hier hast du dann die 3 Dateien auf die RAM Disk kopiert und dann die andere Diskette ins Laufwerk gesteckt und dann die 3 Dateien von der RAM Disk auf die Diskette kopiert. Unter einem objektorientierten OS mit Desktop wählst du die 3 Dateien auf der ersten Diskette aus, drückst auf kopieren und wechselst die Diskette und dann fügst du die 3 Dateien bei der neuen Diskette ein. Im Hintergrund hat das OS die Daten ins RAM kopiert, nämlich in die objektorientierte Zwischenablage, damit du die erste Diskette entfernen und die zweite ins Laufwerk legen kannst. Die objektorientierte Zwischenablage kann also mehr als nur einen Textstring im Speicher halten, sie kann man allen Arten von Objektdaten umgehen und der Speicherort ist transparent das RAM ohne dass der Nutzer etwas davon mitbekommt.
Ich habe bei mir Netzwerkbooten per PXE und readonly NFS eingerichtet (zwar eher als Spielerei). Funktioniert ganz ohne HDD. Praktisch um schnell mal ein aktuelles & sauberes System zu starten. Ich mounte dort ein paar tmpfs und overlayfs, damit man trotz readonly nfs root Dateien erstellen & ändern kann. Nach dem herunterfahren ist das zwar alles weg, aber das ist auch sinn der Sache in dem fall. So bleibt das Notfallsystem sauber.
Ich hab auch noch ein paar build scripts wo ein tmpfs & overlayfs erstellt wird: https://github.com/Daniel-Abrecht/dpa-image-builder Das ding baut diverse Pakete. Da wird eine art chroot umgebung genommen, die Build dependencies installiert, die Pakete gebaut, und weggespeichert. Die Änderungen dabei landen alle auf einem tmpfs, und werden danach weggeschmissen. Und dank etwas mount namespace Magie, bekommt jeder build prozess ein separates overlayfs & tmpfs, die kommen sich also nicht in die queere.
Nano schrieb: > Mich würde eher interessieren, warum ihr heute auf eurem PC, Apple > Rechner, ARM usw. eine RAM Disk regelmäßig verwendet und wofür Privat genutzte Rechner: jede Nacht als Scratchpad für StoreBackup. Da drin speichert es Timestamp, Größe und md5sum jedes schon gesehenen Files. Identische Files müssen so nicht kopiert werden sondern werden als Hardlinks auf die alte Version angelegt. Auf Arbeit: für Builds. Als Arbeitsdirectory für automatische Tests. Etc. pp. Im Prinzip immer dann, wenn der Platz reicht und die Daten nur existieren müssen, während der Job läuft. Ja, auch auf Systemen mit SSD. Nicht um die SSD zu schonen, sondern weil die RAM-Disk (meist /dev/shm) viel schneller ist.
DDR4-3200 RAM überträgt etwa 25 GByte/Sek und eine schnelle PCI-Express 4.0 SSD ca. 6 GByte/sek es ist also rechnerisch schon noch ein kleiner Unterschied, ob mans bemerkt ist ne andere Frage.
Thomas O. schrieb: > DDR4-3200 RAM überträgt etwa 25 GByte/Sek und eine schnelle PCI-Express > 4.0 SSD ca. 6 GByte/sek es ist also rechnerisch schon noch ein kleiner > Unterschied, ob mans bemerkt ist ne andere Frage. <Erbsenzähler> Und die Daten von der SSD müssen nicht erst ins RAM? Die Zeiten müssen nicht addiert werden? Ach ja und vom RAM in die Applikation. Muss die Zeit auch nicht addiert werden? </Erbsenzähler> SCNR.
Thomas O. schrieb: > DDR4-3200 RAM überträgt etwa 25 GByte/Sek Pro Modul, also single channel. Im high end hat man bis zu 8 channels parallel.
:
Bearbeitet durch User
Nahezu alle Linux Anwender benutzen eine RAM Disk zum booten. /boot/initrd.img-4.15.0-76-generic Die alte initrd unter Linux gibt es immer noch. Der Bootloader bindet eine RAM Disk ein, von der Linux die Tools und Module lädt, die es zum booten braucht.
selbstverständlich müssen die Daten von der SSD aufs RAM, oder habe ich was anderes behauptet und wenn hier durch 8 Module parallel der Effekt noch höher ist bestätigt das doch meine Aussage das die RAM-Disk schneller ist. Die Frage ist halt merk man es oder nicht, den die wenigsten Anwendungen benötigen gleich mal xx GB Daten auf einen Schlag und die Anwendung kann die Daten auch nicht so schnell verarbeiten wie der Bus die Daten liefert.
Thomas O. schrieb: > Die Frage ist halt merk man es oder nicht, den die wenigsten Anwendungen > benötigen gleich mal xx GB Daten auf einen Schlag und die Anwendung kann > die Daten auch nicht so schnell verarbeiten wie der Bus die Daten > liefert. Das ist der Punkt. Die Anforderung von Anwendungen differieren um mehrere Größenordnungen. Auf einem solchen 8-Kanäler können 100 gewöhnliche Büro-PC gleichzeitig laufen, ohne dass die sich spürbar ins Gehege kommen. Ohne RAM Disk und mit einer einzigen 1 GByte/s Anbindung zum Storage für alle zusammen. Andererseits hat Microsoft gerade erst einen Zugriffspfad von Anwendung zum Storage geschaffen, der deutlich schneller als bisher sein soll, weil bei Szeneriewechsel in Games der übliche Zugriff auf die 7 GByte/s von PCIe4 SSDs offenbar vom Betriebssystem ausgebremst wird.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Andererseits hat Microsoft gerade erst einen Zugriffspfad von Anwendung > zum Storage geschaffen, der deutlich schneller als bisher sein soll, > weil bei Szeneriewechsel in Games der übliche Zugriff auf die 7 GByte/s > von PCIe4 SSDs offenbar vom Betriebssystem ausgebremst wird. Die Technik heißt DirectStorage API Siehe dazu auch: https://devblogs.microsoft.com/directx/directstorage-is-coming-to-pc/ Schade ist nur, dass es eine Microsoft Only Lösung ist. Mir ist kein freier Standard bekannt, der das auch auf anderen Betriebssystemen möglich macht. Damit hätte Microsoft in Windows wieder etwas, das die anderen nicht bieten können und da vermutlich wieder Jahre dauern wird. So eine Situation hatten wir vor vielen Jahren schon einmal. Während man in Direct3d fleißig Pixel Shader nutzen konnte, muss man sich bei OpenGL <= 1.2 noch mit herstellerspezifischen Extensions rumplagen. Bis dann endlich OpenGL 2.0 fertig war, hat das viel zu lange gedauert. Das gleiche Problem dürfte es hier bei DirectStorage und einem entsprechenden freien Gegenstück auch geben. Oder hast du da etwas in dieser Richtung etwas bezüglich freier Standards irgendwo vernommen?
Das OS muss die Daten nicht jedes mal in den RAM laden, wenn darauf zugegriffen wird. Am Anfang ist es 1mal nötig, und auch nur für teile auf die effektiv zugegriffen wird, aber dann kann es gecached werden. Beim schreiben muss es auch nicht sofort wirklich auf die Platte geschrieben werden. Eigentlich ist das erst wirklich nötig, wenn eine Anwendung fsync aufruft, oder die Partition geunmountet wird. Der Geschwindigkeitsvorteil einer RAM Disk muss also nicht unbedingt so gross sein, wie man zunächst meinen würde.
Nano schrieb: > (prx) A. K. schrieb: >> Andererseits hat Microsoft gerade erst einen Zugriffspfad von Anwendung >> zum Storage geschaffen, der deutlich schneller als bisher sein soll, >> weil bei Szeneriewechsel in Games der übliche Zugriff auf die 7 GByte/s >> von PCIe4 SSDs offenbar vom Betriebssystem ausgebremst wird. > [...] > Schade ist nur, dass es eine Microsoft Only Lösung ist. > [...] Das ist eine Microsoft Only Lösung, weil es ein Microsoft Problem ist (bei den angesprochenen Spielen). Die Ladezeiten unter Windows sind häufig deutlich länger als unter Linux. In einem Fall auf meinem Rechner z.B. 10s vs. 125s bis man im Hauptmenü ist.
Nano schrieb: > Schade ist nur, dass es eine Microsoft Only Lösung ist. > Mir ist kein freier Standard bekannt, der das auch auf anderen > Betriebssystemen möglich macht. Linux arbeitet nicht identisch wie Windows und hat andere Filesysteme, integriert neue Konzepte und Filesysteme viel schneller. Somit wäre auch denkbar, dass Microsoft damit auf proprietäre Weise ein Problem löst, dass man ohne Microsoft nicht hätte.
Thomas O. schrieb: > selbstverständlich müssen die Daten von der SSD aufs RAM, oder habe ich > was anderes behauptet und wenn hier durch 8 Module parallel der Effekt > noch höher ist bestätigt das doch meine Aussage das die RAM-Disk > schneller ist. Wollt ihr im Jahr 2022 wirklich noch tagelang über RAM Disks und "das beste" DOS diskutieren? Wo sind die intelligenten jungen Leute mit Spitzen-Ausbildung hin, die am Puls der Zeit sind? Windows (und Linux/FreeBSD/Solaris/HP-UX/IBM-OS) verwendet den freien Speicher seit Ewigkeiten als gratis RAM Disk. Jede Datei, die einmal geöffnet wurde, bleibt solange wie möglich im RAM. Das sieht man schön bei Benchmarks, der zweite Aufruf liest aus dem RAM, und die Geschwindigkeit liegt nahe beim RAM Limit. Die Windows CreateFile Funktion hat auch seit Ewigkeiten das Flags FILE_ATTRIBUTE_TEMPORARY:
1 | The file is being used for temporary storage. File systems avoid writing data back to mass storage if sufficient cache memory is available, because an application deletes a temporary file after a handle is closed. In that case, the system can entirely avoid writing the data. Otherwise, the data is written after the handle is closed |
NB: Syntax-Highlighting sieht bei Klartext ulkig aus. Das "code" Tag ist da vmtl besser als das "c" Tag. :)
udok schrieb: > Wo sind die intelligenten jungen Leute mit Spitzen-Ausbildung hin, die > am Puls der Zeit sind? Du hast dir das schon selbst beantwortet: > hat auch seit Ewigkeiten Das ist nicht der heissteste Scheiss, sondern langweiliges Zeug aus Opas Zeiten. ;-)
Mombert H. schrieb: > Nano schrieb: >> (prx) A. K. schrieb: >>> Andererseits hat Microsoft gerade erst einen Zugriffspfad von Anwendung >>> zum Storage geschaffen, der deutlich schneller als bisher sein soll, >>> weil bei Szeneriewechsel in Games der übliche Zugriff auf die 7 GByte/s >>> von PCIe4 SSDs offenbar vom Betriebssystem ausgebremst wird. >> [...] >> Schade ist nur, dass es eine Microsoft Only Lösung ist. >> [...] > Das ist eine Microsoft Only Lösung, weil es ein Microsoft Problem ist > (bei den angesprochenen Spielen). Die Ladezeiten unter Windows sind > häufig deutlich länger als unter Linux. In einem Fall auf meinem Rechner > z.B. 10s vs. 125s bis man im Hauptmenü ist. Ist das wirklich so? Ich dachte es geht dabei um etwas wesentlich grundlegenderes.
Nano schrieb: > Ich dachte es geht dabei um etwas wesentlich grundlegenderes. Im Prinzip dürfte es darum gehen, Zugriffe massiv zu parallelisieren. Wenn man sich Benchmarks von SSDs ansieht, stellt man fest, dass wirklich hohe Raten nur erzielbar sind, wenn sehr viele Requests gleichzeitig anstehen. Bei traditionellen Einzelanwendungen ist das praktisch nie der Fall, das tritt eher bei von vielen Clients gleichzeitig genutzten Servern auf. Die Frage ist also, ob man das nur mit diesem speziellen API hinbekommt, ob das mit traditionellem Filesystem-Zugriff anderer Systeme nicht möglich ist, oder ob Microsoft sind dabei selbst auf den Füssen steht. Ich weiss es nicht.
Nano schrieb: > Die Technik heißt DirectStorage API Naja, ich frag mich ja, in welchen fällen das auf linux effektiv sinn macht. Für direkt daten übertragen kann man ja mmap nutzen, und dann die entsprechenden opengl/vulkan Methoden, um das alles auf einmal zur GPU zu senden. Mit Vulkan dürfte da vieles auch asynchron gehen, und mit dem read-ahead algorithmus hat man die daten eventuell sogar schon im RAM, bevor man die braucht. Asynchron viele read requests absetzen, was wohl der selling point hinter DirectStorage ist, ist aber auch kein Problem. Da gibt es unter anderem aio[1], eine POSIX geschichte. Das ist auch nicht nur für Games nützlich. Mittlerweile gibt es auf Linuxseite zwar sogar noch heisseren scheiss, nennt sich io_uring[2]. Damit kriegt man teils auch noch 0-copy. Ist aber halt recht komplex zu nutzen. Wobei, der Scheduler und die syscalls unter Linux sind nicht so scheiss langsam wie unter Windows. Wer weiss, ob das hier überhaupt schon ein Bottleneck ist, oder ob NVMe da für linux noch nicht schnell genug sind. 1) https://man7.org/linux/man-pages/man7/aio.7.html 2) https://man.archlinux.org/man/io_uring.7.en
🐧 DPA 🐧 schrieb: > Wobei, der Scheduler und die syscalls unter Linux sind nicht so scheiss > langsam wie unter Windows. Das ist es, was ich oben schrieb. Wer eine Idee hat, probiert sie in Linux aus - wo sonst? Überzeugt sie auch andere, landet sie im Kernel oder angrenzenden Bereichen. Die Praxis zeigt dann, ob sie was taugt. Ob CPU- oder I/O-Scheduler, wo alle Naselang neue Varianten aufkreuzen, als Filesystem, oder in etlichen anderen Bereichen. Kommerzielle Systeme wie Windows sind viel statischer, bürokratischer. In Windows ist das dann ein gross angekündigtes Event, in Linux merken es mangels Publicity-Abteilung nur jene, die ständig am Ball bleiben (=> Phoronix).
:
Bearbeitet durch User
Mombert H. schrieb: > Die Ladezeiten unter Windows sind > häufig deutlich länger als unter Linux. In einem Fall auf meinem Rechner > z.B. 10s vs. 125s bis man im Hauptmenü ist. Um welches Spiel handelt es sich? Das dies so extrem ist, hätte ich nicht gedacht. Gamer
(prx) A. K. schrieb: > NB: Syntax-Highlighting sieht bei Klartext ulkig aus. Das "code" Tag ist > da vmtl besser als das "c" Tag. :) Danke, wenigstens kann ich hier ab und zu mal was lernen. Wenn es auch nur die Forensoftware ist...
Hm, okay. Hat hier jemand vielleicht das Spiel "X4 Foundation" von Egosoft und kann etwas zu den Lade und Speicherzeiten eines fortgeschrittenen Spielstands bezüglich Windows vs. Linux sagen? Das Spiel gibt's ja für beide Betriebssysteme und die Ladezeiten scheinen enorm zu sein, wie ich erst kürzlich gelesen habe, weil halt der ganze Istzustand des Spieluniversums auf einmal als ca. 500 MB große XML Datei auf die Platte geschrieben werden muss. Ich selbst habe das Spiel nicht und kann daher dazu auch nichts sagen. Aber wenn das wirklich so lange Lade- und Savestände hat, dann sollten sich Unterschiede in den Betriebssystemen bei diesem Spiel doch schon bemerkbar machen. Dann hätte man einen Vergleich zwischen Windows und Linux aus der Praxis.
Nano schrieb: > der ganze Istzustand des Spieluniversums auf einmal als ca. 500 MB große > XML Datei auf die Platte geschrieben werden muss. Da wirst du nichts OS spezifisches messen. Eine SSD schreibt 0.5 GB in weniger als 0.2 Sekunden. Da ist die Konvertierung ist XML einfach grottenschlecht programmiert.
(prx) A. K. schrieb: >> Wo sind die intelligenten jungen Leute mit Spitzen-Ausbildung hin, die >> am Puls der Zeit sind? > > Du hast dir das schon selbst beantwortet: Das die nicht hier herumhängen weiss ich ja schon, aber die Frage war, wo sind die hin?
udok schrieb: > Das die nicht hier herumhängen weiss ich ja schon, aber die Frage war, > wo sind die hin? Die erfinden Cryptogeld, da ist mehr drin. ;-)
:
Bearbeitet durch User
udok schrieb: > Nano schrieb: >> der ganze Istzustand des Spieluniversums auf einmal als ca. 500 MB große >> XML Datei auf die Platte geschrieben werden muss. > > Da wirst du nichts OS spezifisches messen. Eine SSD schreibt 0.5 GB in > weniger als 0.2 Sekunden. Da ist die Konvertierung ist XML einfach > grottenschlecht programmiert. Das kann natürlich auch sein. Immerhin scheint dass Schreiben aber schneller zu gehen als das Laden. Insofern haben die da schon etwas mitgedacht. Denn ersteres wird man wesentlich öfters machen.
Nano schrieb: > Immerhin scheint dass Schreiben aber schneller zu gehen als das Laden. Geschrieben wird sowieso asynchron, denn wenn die Daten im Puffer des Betriebssystems sind, ist die Sache für die Anwendung meist durch. Nachklappern tuts im Betriebssystem. Lesend muss man aber leider warten, bis die Daten da sind, bevor man sie verarbeitet. Insofern sind Messungen mit Vorsicht zu geniessen. Wenn man genug RAM hat, sind auch grosse Schreiboperationen in Linux brandschnell fertig. Scheinbar. Was danach kommt, sieht man ohne die früher übliche Disk-LED nicht, und hört auch nicht mehr die HDD rappeln.
:
Bearbeitet durch User
udok schrieb: > (prx) A. K. schrieb: >> NB: Syntax-Highlighting sieht bei Klartext ulkig aus. Das "code" Tag ist >> da vmtl besser als das "c" Tag. :) > Danke, wenigstens kann ich hier ab und zu mal was lernen. Wenn es auch > nur die Forensoftware ist... Ist nicht der "pre" Tag besser geeignet? Den benutze ich zumindest immer, wenn ich z.B. aus dem C oder C++ Standard zitiere. Nano schrieb: > Ist das wirklich so? Ja, sonst hätte ich es nicht geschrieben? Gamer schrieb: > Mombert H. schrieb: >> Die Ladezeiten unter Windows sind >> häufig deutlich länger als unter Linux. In einem Fall auf meinem Rechner >> z.B. 10s vs. 125s bis man im Hauptmenü ist. > Um welches Spiel handelt es sich? Das dies so extrem ist, hätte ich > nicht gedacht. Z.B. Spiele von Paradox Interactive. Die Pathfinder: Kingmaker Ladezeiten waren auch deutlich schneller unter Linux.
Thomas O. schrieb: > DDR4-3200 RAM überträgt etwa 25 GByte/Sek und eine schnelle PCI-Express > 4.0 SSD ca. 6 GByte/sek es ist also rechnerisch schon noch ein kleiner > Unterschied, ob mans bemerkt ist ne andere Frage. Theorie und Praxis. Du machst einen Denkfehler. Es ist ein gewaltiger Unterschied ob ich einen angepassten Systemtreiber verwende oder einen fremd geschriebenen. Ich hatte eine 16 GB Ram-Disk und gegen eine Festplatte mit Motor hat das auch voll gerockt. Aber durch den Freeware-Treiber hatte das gegen eine normale billig SSD (480 MB/s billig-Modell) nicht mehr wirklich eine Chance. Jedenfalls hatte ich schon kein Unterschied gemerkt. Ist genau das selbe Problem wie mit der Auslagerungsdatei. Ich habe eine mit 1 GB Größe. Schalte ich die ab, wird das System stark spürbar langsamer. Mit 1 GB kann ich kein Beeindrucken, aber Windows will halt das sie da ist. Die 32 GB Ram-Speicher reichen aber völlig aus, so das ich unter Win-7 nur so 1 lausiges GB brauche. Alles was nicht "Windows-Norm-Like" ist, ist selten sehr effektiv. Vor vielen vielen Jahren hatte ich in der Firma eine Karte im 486er PC als Ram-Disk (mit Batterie). Das Teil hat echt gerockt. Von der Speed her gefühlt nicht viel langsamer als heutige m2. Aber schweineteuer. Ca. 2300 DM. Hat mich viel Nerven gekostet bis ich die bewilligt bekam. ;)
Nano schrieb: > Die Technik heißt DirectStorage API > Siehe dazu auch: > https://devblogs.microsoft.com/directx/directstorage-is-coming-to-pc/ > Schade ist nur, dass es eine Microsoft Only Lösung ist. Ich bin grad in der Mittagspause über folgenden Link gestolpert: https://arstechnica.com/gadgets/2022/03/directstorage-speeds-up-load-times-in-pc-game-demo-but-hardware-matters-most/ Das scheint sich ja so richtig zu lohnen ...
Beitrag #7014108 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.