Forum: PC Hard- und Software Win10 auf RAMDisk in VMWare nicht viel schneller als SSD?


von Markus (Gast)


Lesenswert?

Ich installiere zum Testen von verschiedenen Szenarieren Windows 10 
mehrmals auf eine RAMDisk in VMWare.
ISO Installations File liegt auch auf einer RamDisk.

Nun ist der Installationsvorgang nicht wirklich viel schneller, als von 
einer SSD.
Dateien kopieren geht zwar ziemlich fix, aber viele andere Prozesse 
dauern fast gleich lang (Geräte installieren zBsp.)

Nun ist es auf einer sehr schnellen RamDisk Festplatte, die CPU ist auch 
nur 20% ausgelastet.

Was gibt es den noch, was gebraucht wird?
Muss ich VMWare selbst auch in einer RamDisk installieren?

Host OS kann ich klarerweise nicht darin installieren, dafür hab ich 
dann doch zuwenig RAM.

Oder sind SSDs schon so schnell, dass es zu RAM keinen merklichen 
Unterschied macht?

Danke, LG.

von (prx) A. K. (prx)


Lesenswert?

Trivia: Wenn ein Installationsvorgang nicht an Zugriffszeit und 
Transferrate der Disk hängt, dann geht die Disk eben kaum in die 
Wartezeit ein.

Eine CPU-Last von 25% kann bei 4 Cores bedeuten, dass effektiv ein Core 
zu 100% belegt ist und die anderen gelangweilt zusehen. Das kann 
freilich durch die Cores durchrotieren, so dass es nicht direkt 
auffällt. Aber nicht alle Vorgänge werden auf mehrere Threads 
aufgeteilt.

Kein Bashing, sondern Alltagserfahrung: Microsoft ist seit Ewigkeiten 
bei Installation und besonders Update grässlich langsam. Das war zwar 
schon schlimmer so, gehört aber zu Windows einfach dazu.

: Bearbeitet durch User
von Torres (Gast)


Lesenswert?

Die Zeit wird für das entpacken von Archiven draufgehen, und jedes Byte 
wird sicherlich beliebig oft kopiert bevor es in seiner endgültigen 
Zielposition landet. Und wahrscheinlich fehlen auch Windows diese ganzen 
netten Mikrooptimierungen die es in Linux gibt. (Alle CPUs gleichzeitig 
booten und solcher Kram)

von Jens G. (jensig)


Lesenswert?

Torres schrieb:
> Zielposition landet. Und wahrscheinlich fehlen auch Windows diese ganzen
> netten Mikrooptimierungen die es in Linux gibt. (Alle CPUs gleichzeitig
> booten und solcher Kram)

Ja ja, wahrscheinlich ... Was nützen einem "alle CPUs" und solcher Kram, 
wenn der Installer nur einen Core (Thread) nutzt?

von Cartman (Gast)


Lesenswert?

Windows besteht eben im wesentlichen aus ineinander
verschachtelten Warteschleifen des Sanduhranzeigeprogramms.

VMWare(ESX) brauchst du nicht in eine Ramdisk installieren,
das tut es (leider nur fast) von allein.

> Host OS kann ich klarerweise nicht darin installieren, dafür hab ich
> dann doch zuwenig RAM.

Windows 3.1 und Windows 95 haben davon tatsaechlich profitiert.
Das lag zum grossen Teil aber am grottigen IDE-Interface.
Wenn man dem bereits im Realmode einen DMA-Treiber angedreht
hat, die Platte nach Zugriffen defragmentiert war, hielt
sich der Geschwindigkeitsvorteil in Grenzen.

> Oder sind SSDs schon so schnell, dass es zu RAM keinen merklichen
> Unterschied macht?

Ein RAID0-Stripeset aus 8 x 8 TB NVMe ist beim Lesen nicht
wirklich langsamer.
Beim Schreiben bricht die Schreibrate auf die SSDs, auch erst
nach der achtfachen Datenmenge ein.
Ist aber nicht ganz billig der Spass.

von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Kein Bashing, sondern Alltagserfahrung: Microsoft ist seit Ewigkeiten
> bei Installation und besonders Update grässlich langsam.

Das ist leider wahr. Multi-Threading wird hier nur in homöopathischen 
Dosen genutzt. Und wo es genutzt wird, kommen teilweise sogar unsägliche 
"blocking"-Warteschleifen zur Synchronisation zum Einsatz.

Als wenn das System nicht alles bereitstellen würde, was für ein 
sauberes Multitasking nötig wäre. Das tut es aber. Sprich: da sind 
völlige Blindflansche am Werk gewesen.

Der Update-Kram wurde und wird offensichtlich nicht von den hellsten 
Lichtern in der Microsoft-Bude bearbeitet.

Aber naja, wenn ich mir so anschaue, wie das Update auf meinem HTPC so 
im Detail abläuft, sieht das an der Linux-Front (konkret: apt) kaum 
besser aus...

Der HTPC ist schon etwas betagt (AtomN310, also immerhin 4 
Hardware-Threads möglich), da fällt das schon ziemlich krass auf und 
lädt förmlich ein zur kritischen Analyse...

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> Aber naja, wenn ich mir so anschaue, wie das Update auf meinem HTPC so
> im Detail abläuft, sieht das an der Linux-Front (konkret: apt) kaum
> besser aus...

Das erlebe ich völlig anders, und ich mache das mit vielen Servern. Für 
den Update von Windows Servern muss ich insgesamt sehr viel mehr Zeit 
einplanen, als für Linux Server. Egal ob apt oder dnf.

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Das erlebe ich völlig anders, und ich mache das mit vielen Servern.

Tja, dann mach' das eben einfach mal auf einer langsameren Maschine. Da 
kannst du mit top live zuschauen, wie Scheisse das ebenfalls bezüglich 
der Nutzung von Multithreading ist.

Das sind Fakten, kein ideologisch motiviertes sinnloses Gesülze!

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> Tja, dann mach' das eben einfach mal auf einer langsameren Maschine.

Ist ein privates Netbook mit Intels N3350 oder ein Serverlein mit AMDs 
N36L langsam genug? Vergiss bitte nicht, das mit einem Windows Update 
auf der gleichen Machine zu vergleichen. Das war davor auf dem Netbook 
drauf, ich kann das also vergleichen.

Ich beziehe mich auf die Gesamtzeit, nicht das Threading.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Zu den Unterschieden, die beim Update eine wesentliche Rolle spielen 
können, gehört es, dass Windows Updates mittlerweile innerhalb einer 
Version teilweise kumulativ und in grossen Einheiten zusammengefasst 
sind, nicht paketweise inkrementell. Egal ob schon drauf oder nicht, es 
ist alles dabei und wird geprüft. Das bedeutet weit mehr Arbeit als bei 
den paketweise inkrementellen Updates der Debian oder Red Hat Schiene.

Ironischerweise ist es in Windows aber genau dadurch besser geworden als 
früher, wo der Update einer lange Jahre ungefixten Maschine aus zig 
Paketen und 3-4 Updatezyklen mit jeweiligem Reboot bestand und sich über 
Stunden hinzog. Wenn es überhaupt noch möglich war, ohne irgendwann mit 
Hexcode zu grüßen.

von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Ist ein privates Netbook mit Intels N3350

Der kann nur 2 Hardware-Threads, die aber deutlich fixer als ein N310.

Da sieht man die strukturellen Mankos der Software weit weniger 
deutlich. Aber, wenn man nicht gerade die Ideologiebrille mit den 
Gläsern aus Teerpappe auf hat, kann man es auch hier noch deutlich genug 
sehen...

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> Aber, wenn man nicht gerade
> die Ideologiebrille mit den Gläsern aus Teerpappe auf hat

Wer Hass im Namen trägt und oft entsprechend auftritt, möge da 
vorsichtig sein. Ich habe ausreichend mit beiden Servertypen zu tun, auf 
gleicher Hardwareumgebung, um mir ein Urteil zu erlauben.

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Ich habe ausreichend mit beiden Servertypen zu tun, auf
> gleicher Hardwareumgebung, um mir ein Urteil zu erlauben.

Scheinbar nicht. Es reicht nichtmal zu vorurteilsfreier Bewertung 
offensichtlicher und leicht gewinnbarer Fakten.

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> die aber deutlich fixer als ein N310.

Das ist wahr.

Wann hast du auf dem N310 den letzten Windows Update gemacht, um einen 
Vergleich zum aktuellen Linux zu haben?

RasPis auf µSD habe ich zwar auch im Angebot, und da dauert es auch 
recht lange, aber da fehlt der Vergleich mit Windows. Die anzuführen 
wäre also unfair.

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Das ist wahr. Wann hast du auf dem N310 den letzten Windows Update
> gemacht, um einen Vergleich zum aktuellen Linux zu haben?

Nunja, auf dem HTPC ist schon seit einer Ewigkeit (ca. 10 Jahre) kein 
Windows mehr. Das letzte war ein WindowsXP. Das lief ziemlich 
schnuckelig (incl. Updates), hat mir aber nicht die Freiheiten gegeben, 
die ich brauchte, um den HTPC in jeder Hinsicht nach meinen Wünschen und 
Bedürfnissen zu konfigurieren. Seitdem nur noch Linux.

von (prx) A. K. (prx)


Lesenswert?

Cartman schrieb:
> VMWare(ESX) brauchst du nicht in eine Ramdisk installieren,
> das tut es (leider nur fast) von allein.

Ob er wohl ESXi meinte, und nicht Player/Workstation?

: Bearbeitet durch User
von S. R. (svenska)


Lesenswert?

Markus schrieb:
> Oder sind SSDs schon so schnell, dass es zu RAM keinen merklichen
> Unterschied macht?

Aktuelle NVMe-Speicher auf passenden Systemen kommen durchaus an die 
Busgeschwindigkeit ran - und damit (je nach Mainboard) an die 
Geschwindigkeit des RAMs auf gleicher Maschine.

Eine aktuelle Windows-Installation hat nur wenig mit der 
Plattengeschwindigkeit zu tun. Wenn da noch Netzwerkverkehr und 
langsame, überlastete Update-Server, Cloudgedöns und Telemetrie 
dazukommen, dann noch nichtmal mit dem System selbst.

Im Gegensatz dazu stehen langsame, rotierende Notebook-Platten gepaart 
mit 4 GB RAM, die dann tatsächlich als Systembremse dienen.

Bitte 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
Noch kein Account? Hier anmelden.