![]() |
Hallo zusammen,
ich habe mir unter dem Aspekt des Gesagten den Taskmanager noch einmal angesehen. So falsch liegt der nicht! Unter "Zugesicherter Speicher --> Grenzwert" wird der tatsächlich zur Verfügung stehende virtuelle Adressraum angezeigt. Ich habe verschiedene Einstelleungen ausprobiert und es stimmte stets. Allerdings zeigt der Grenzwert nicht den RAM plus Pagefile in MB, sondern den tatsäöchlich verfügbaren Speicherraum an. Wenn man sich das Bild von Jens ansieht, dann ist klar erkennbar, dass der virtuelle Speicher unter 1 GB ist und das ist bei 20 MB Pagefile und 1024 MB RAM okay, denn es wird ja Speicher für die Verwaltung und Weiteres gebraucht. Der "zugesicherte Speicher" ist die Summe aus einem Teil des RAM und Teile des Pagefiles und nicht nur das Pagefile. Der Taskmanager ist insoweit irrefeührend als der zugesicherte Speicher als Auslastung der Auslagerungsdatei bezeichnet wird. Hier Heinz gebe ich dir Recht, dass womöglich Übersetzungsfehler zu finden sind. Übrigens habe ich das Löschen des Pagefiles wieder deaktiviert, weil es mir denn doch bei dem stabilen System zu lange dauert, ehe es ausschaltet. |
Danke Dieter,
dann kann ich mir die zweite Festplatte endgültig sparen :) Zitat:
Gruß Heinz |
Das Löschen des Pagefiles ist auf jeden Fall anzuraten. Zwar dauert es länger beim Runterfahren. Dafür nimmt aber die Größe und Defragmentierung des Pagefiles zu. Und das kann u.U. die Performance des Flusi stark beeinträchtigen.
Auch die zweite Festplatte ist keinesfalls überflüssig. Wenn Ihr mir recht gebt, das es ohne swaping nicht geht, dann sollte man den Schreib-Lese-Konflikt vermeiden, auch der kostet Performance |
Moin Moin !
Zitat:
Genauso halte ich es für ein Irrglauben, dass es mehr Performance bringen würde, wenn man XP die Verwaltung des Swap-Files entzieht. Was macht man dann anders, als die Größe und den Ort festzulegen ? Nix. Sinnvoll ist es da eher, wie Heritage schon sagte, dass man Swap-File auf eine (schnelle) zweite Festplatte legt, um Lese- und Scheib-Vorgänge zu trennen. Am Besten noch an den zweiten IDE-Kanal. CU Stephan |
Hallo Wolfgang,
Zitat:
Gruß Heinz |
Hallo Stephan,
bei MS steht es aber etwas anders: http://support.microsoft.com/default...d=kb;de;314482 Gruß Heinz |
Morgen Wolfgang,
deinen Tipps kann ich nicht folgen. Das Löschen des Pagefiles macht nur Sinn, wenn einmal ein übersteigertes Sicherheitsbedürfnis besteht oder, wie Heinz schon sagte, Datenreste von nicht ordnungsgemäß beendeten Programmen im Pagefile hinterlegt sind. Das kann man auch mal händisch erledigen. Ansonsten werden Daten, die im File sind, bei der nächsten Sitzung überschrieben. Weiterhin werden bestimmte Daten im Pagefile hinterlegt, die beim nächsten Start sofort zur Verfügung stehn. Löscht man die Datei, muss alles neu initialisiert werden. Die Defragmentierung des Pagefiles spielt erst dann eine Rolle, wenn der Rechner tagelang läuft, aber auch das sollte mann nicht überbewerten, weil eine NTFS-formatierte Platte nicht die Probleme hat wie eine FAT oder FAT32. Die Performance des Flusi´s hängt mit Sicherheit nicht davon ab, es sei denn jemand arbeitet mit 128 oder 256 MB RAM und die Daten werden laufend von der Festplatte geholt, was bei 512 MB schon nicht mehr der Fall ist. Die Performance des Flusi steigert man mit einer starken CPU, viel RAM und einer sehr guten Grafikkarte. Eine zweite Festplatte braucht auch ganz sicher nicht für den Flusi uns schon gar nicht bei einem RAM von 1024 MB. Da sind die HD-Zugriffe nach dem Flusistart sehr selten. |
Moin, moin,
also: das mit der zweiten Festplatte ist logischerweise so wie von mir gesagt, siehe auch der Hinweis von Heinz auf die Knowledgebase. Das Löschen des Pagefiles macht Sinn, Defragmentierung spielt bei den großen texture-Files eine Rolle. Und die passiert, wenn man, wie Wolf-Dieter richtig sagt, überschreibt. Im übrigen hatten wir hier einen Thread von mir, in dem ich (und viele andere) die ständige sinkende Performance des FS durch immer weiter voll laufendes Pagefile diskutierten. Für mich war die Konsequenz, das mit dem häufigen Löschen auszuprobieren, und siehe da, es funzt. Und da waren nicht minimale Unterschiede in Rede, sondern fps-Differenzen von 10 und mehr. Davei spielt aber auch das Rücksetzen der Prefetching-flags eine Rolle. |
Hi Wolfgang,
Zitat:
Welche Abhängigkeit gibt es denn tasächlich? Während die CPU mit dem Flusi beschäftigt ist, soll eine Texture geladen werden. Okay, das macht nicht die CPU, sondern der I/O-Chip auf dem Board, der dafür Ressourcen zugeteilt bekommt. Ist nun dieser Chip extrem lahm, dann kann der Plattenzugriff zum Stop der CPU führen, weil nicht genug Daten bereitstehen. Dann bleibt der Flusi für einen Augenblicl stehen. Das ist der Extremfall, aber genau dann sind die Frames Null und nicht 5 oder 20 oder sonstwas. Die Regel ist, dass die FS9-EXE rechtzeitig Daten anfordert und der Plattenzugriff zu keiner (sichtbaren) Beeinträchtigung des Rechenvorgangs führt. Wer das dennoch festzustellen meint, der sollte sich sein System mal genauer ansehen, denn nur die Einheit von CPU, Chipsatz, Mainboard, Grafikkarte, Betriebssystem und neueste Treiber/Updates für alle genannten Komponenten garantieren eine gute Performance. Das damit aktuelle Hardware/Software gemeint ist, versteht sich von selbst. Die Festplatte ist das aller letzte, was die Frames/sec sinken lässt. Und nicht jeder Plattenzugriff den man hört ist durch den Flusi verursacht. |
Hallo!
Ich muss jetzt doch nochmal fragen. Ich habe nur eine Festplatte, die ist aufgeteilt in: C: Windows und andere Progs D: Flusi Wo muss/sollte ich nun die Auslagerungsdatei hinsetzen, bzw. wie groß sollte sie sein, wenn ich 512 MB RAM hab, 768 MB, oder? Grüße Johannes |
Alle Zeitangaben in WEZ +2. Es ist jetzt 05:18 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag