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.
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
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)
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?
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.
(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...
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
(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!
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
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.
(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...
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
(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.
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
(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.
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.