Logisch kann es glatter werden. Nehmen wir mal an Du hast nur 512MB. Im Regelfall haben wir ja alle ein virtuelles Laufwerk also unsere Auslagerungsdatei bei Windows aktiv.

Liegt der Speicherverbrauch System und FS irgendwann aufgrund Addons über 512MB, dann muss Windows aufgrund Speichermangels mit dem virtuellen Speicher also einen reservierten Speicherbereich auf Festplatte arbeiten.

Die Festplatte ist natürlich langsamer als der RAM.

Da dauert es etwas länger mit dem Datentransport. Denn wenn jetzt auf ausgelagerte Teile zugegriffen werden muss, dann dauert das ein wenig.

So wir haben hier also Festplattenarbeit. Jetzt fliegt man so durch die Gegend. Nun müssen natürlich neue Daten von Festplatte nachgeladen werden. Upps wieder zusätzliche Festplattenzugriffe.

Das bedeutet die Festplatte die eh schon langsam ist wird doppelt belastet.

Der FS wird durch diese Festplattenzugriffe unrhytmisch.

Ist diese Festplatte dann noch fragmentiert wird es noch schlimmer.

So haben wir dann noch einen Virenscanner der die Datei / Festplattenzugriffe ständig überwacht, dann bremst dieser durch seine Aktivität den Ablauf des FS, weiterhin aufgrund Festplattenzugriffen.


Da der FS inkl. System oft mehr als 512Mb verbraucht machen sich 1GB Ram bemerkbar. Über 1GB hat man seltener, von daher profitiert man hier nicht sehr oft. Denn oftmals ist das was über 1GB liegt nicht der FS selbst sondern andere Programme usw. die sinnvoller Weise in der Auslagerungsdatei liegen.

Von daher hat man hier selten Vorteile beim FS.

Man kann das schlecht für jedes System sagen, aber bei mir (habe 2GB Ram wirkt sich die RAM Erweiterung von 1GB auf 2GB beim FS erst aus, wenn der Task Manager ca. 1,3GB Speicherverbrauch meldet.

Nur das habe ich sehr selten. Ich habe das damals aber ganz gut mittels eines bewusst eingesetzten Speicherlecks testen können.

Ich habe so eine Testscenery auch in meiner Doku. Dort kann man das Speicherleck laufen lassen, man kann es aber auch während des Fluges pausieren lassen.

Ich habe erst auf 1024 hochgerüstet, kaum merkbar. Dann auf 1536, auch nicht besser.
Auf 2000 schenk ich mir. Glaube nicht, dass das noch was bringt.

Hängt eben auch viel vom gesamten System ab.

Hat man z.B eine schnelle Festplatte e.v sogar die Auslagerungsdatei auf einer anderen Festplatte als den Flusi, dann macht sich das auch nicht unbedingt so stark bemerkbar.

Hallo,

ich hatte bis vor kurzem auch 1024MB. Da ich bei der Verwendung des Fs2004 ein eigenes Windows habe, welches möglichst wenig Hintergrundtasks/-dienste fährt, hatte ich damit nie Probleme. Der Speicher lief immer bis ca. 850MB voll (Germain Airports, ActiveSky, PMDG, etc.), mehr war nicht...

Dann habe ich Megaairport Frankfurt installiert, und da war es dann, das swappen fing an. Dann habe ich 2GB eingebaut und es lief wieder flüssig.

Das ist für mich ein eindeutiges Ergebnis.

MfG,
Carsten

So, nun habe ich ein eindeutiges Ergebnis: nach Einbau von weiteren 1024 MB auf nun 2048 MB RAM lädt der Flusi die Landschaft rasend schnell nach. Die Framerate gewinnt nicht (wie nicht anders zu erwarten), aber das Nachladen von Mesh und Texturen ist unglaublich schnell!

Subjektiv würde ich sagen, daß das Nachladen von kompliziertem Terrain (also in den Alpen oder vergleichbaren Gebirgen) etwa um den Faktor 5 schneller von statten geht. Ich musste zu Zeiten von 1 GB teilweise noch mehr als 1 Minute auf das Nachladen von Gelände im Slewmodus warten, jetzt allenfalls 15 Sekunden.

Meine Empfehlung also: wer Probleme mit unscharfen Bodentexturen oder ähnliches hat, sollte sich mehr RAM gönnen.

Was hast Du denn für Frames vorher und jetzt. Sprich auf welchem Niveau liegen die?

Ich vermute mal die lagen nämlich schon sehr gut.


Denn was Bodentexturen betrifft, hängt das Nachladeverhalten im wesentlichen nur von der Framerate und nicht vom RAM ab.


Es sei denn, der RAM ist durch andere Geschichten schon sehr voll. Erst dann dürfte sich mehr RAM positiv auf Bodentexturnachladen während eines längeren Fluges auswirken.

Ich habe eine Messreihe bei 2GB RAM gemacht die eindeutig nachweisbar ist und auch den damaligen Tipp untermauert die Framerate auf unendlich zu stellen.

Der Tipp als solches funktioniert aber nur bei denen wo die Framerate aufgrund guter Performance des Systems auch hoch ist. Unendlich ist auch nicht wichtig, wichtig ist das sie hoch ist.


Begrenze bei Dir einfach mal die Framerate per Regler auf 10 Frames. Fliege einen längeren Flug über eine Fotoscenery mit hoher Geschwindigkeit und z.B dem Learjet. Du wirst sehen, dass der PC wieder unscharfe Bodentexturen trotz 2GB Ram zeigt.



Ich erwähne das deshalb, weil ev. einige jetzt auf die Idee kommen dann will ich mir mal 2GB Ram kaufen, dann sind alle meine Probleme behoben. So ist es aber nicht.

Es wirkt sich nur dann positiv aus, wenn der FS aufgrund von Scenerien usw. auch mehr als 1GB Ram benötigt.

Immer dann wenn er auf eine langsame ev. fragmentierte Auslagerungsdatei zurückgreifen muss, erst dann wird es problematisch.

Und wie gesagt man benötigt hohe Frameraten.

Bei einem guten Gesamtsystem wo noch RAM frei ist, welches auch ansonsten gut dimensioniert ist kommt man ab ca. 30 bis 40 Frames in einen guten Bereich für schnellere Flüge und scharfe Bodentexturen.


Dieses Verhalten abhängig von der Framerate hatte ich hier in einem anderen Thread auch schon mal gezeigt.

Ein Dokubild.

Man sieht dort auch, dass wir quasi identische Ladezeiten haben sei es durch reale Belastung oder eben durch Framevorgaberegler. Ein Beweis für die Framekopplung.

Das habe ich auf mehreren PCs durchgeführt. Immer das selbe Verhalten.

Was sich ändert ist, dass sich die Kurve je nach Grundperformance des PC bzw. weiterer belastender Scenerien in dem Diagramm verschiebt.

Der Verlauf der Kurve bleibt bleibt aber immer gleich.

Der Doku ist auch eine Testscenery beigelegt mit denen man dieses MIP Level Verhalten beweisbar simulieren kann.

Kurve ist im Anhang

Dieses Verhalten ist ein prinzipieller Mangel im Nachladealgorithmus des FS.
Von der Sache her ist es im Interesse eines moeglichst ruckelfreien Betriebes schon sinnvoll die Nachladeaktivitaeten zu begrenzen und in Relation zur Leistungsfaehigkeit des Systems zu setzen. Was fehlt ist die Konfigurierbarkeit dieses Verhaeltnisses, da moderne Systeme durchaus wesentlich hoehere Transferraten liefern koennten als es der FS durch dieses Verhaeltnis abfordert. Dann koennte man ein Optimum zwischen moeglichst schnellem Nachladen und unterbrechungsfreier fluessiger Darstellung fuer das jeweilige System finden.
Interresant waere vielleicht ob sich in dieser Beziehung was beim FSX getan hat.
Das duerfte bestimmt den ein oder anderen Fotoscenery Fan doch noch zum Wechsel motivieren ;)

Das ist wohl war. Ich habe nur bei komplexen Flughäfen wie EDDF und LFPG mit Framerates von unter 15 zu kämpfen. In der Darstellung "normaler" Landschaft bringt mein System durchweg über 50 fps, mit PMDG Cockpit je nach Gegend um die 30 bis 40 fps. Eine flüssige Darstellung ist also eher die Regel als die Ausnahme. Insofern kann es natürlich sein, daß ich von den von Dir beschriebenen Zusammenhängen zwischen fps und Nachladegeschwindigkeiten profitiere.

Dagegen spricht aber, daß ich aus einem anderen Thread Deinen Tip mit der Aufhebung der Frameratebegrenzung beherzigt habe und dadurch das Nachladeproblem verringern konnte. Erst seitdem ich aber 2 GB habe, kann ich selbst über den Alpen bei einem kompletten Überflug eine normal aufgelöste Landschaft sehen. Vorher hatte ich schon auf dem Weg von Bozen nach Innsbruck unscharfe Texturen.

Dein Diagramm erscheint plausibel und scheint sich mit meinen Beobachtungen zu decken. Aber trotzdem glaube ich nach wie vor, daß erst die Aufstockung auf 2 GB eine spürbare Verbesserung der Nachladegeschwindigkeit gebracht hat.

Für alle, die sich jetzt fragen, mit welchem System ich eigentlich fliege: ich setze einen Athlon XP Mobile ein, den ich auf 2400 MHz bei 200 MHz FSB getaktet habe und eine 256-Bit Radeon 9800 Pro mit 128 MB GDDR. Die 2 GB RAM sind asynchron auf 166 MHz getaktet wg. der Stabilität. Nach heutigen Maßstäben wäre mein System also eher in der Mittelklasse angesiedelt, auf keinen Fall aber in der derzeitigen Oberklasse.

Nein darf man so nicht unbedingt sehen. Es ist ein Verhalten welches meiner Meinung nach eindeutig daher rührt das Microsoft nach einer Möglichkeit gesucht hat Fotoscenerien auf System mit weniger Speicher also z.B nur 512MB überhaupt zum laufen zu bringen.





Ich weis nicht ob das sinnvoll wäre, denn das würde bei dem momentanen Verfahren des FS2002 und FS2004 eigentlich immer dazu führen, dass ein schwächeres System immer unscharfe Foto Texturen haben wird.

Ich denke dann ist es generell sinnvoller den erweiterten Texturbereich im Displaymenü zu deaktivieren. So schrumpft die Zahl der zu verarbeitenden Texturen von ca. 21000 Fototexturen auf nur noch so um die 5000.

Diese Deaktivierung ist ja auch ein gängiger Tipp für Fototexturen in Verbindung mir der Sichtweitenreduzierung auf ca 30 Milen.

Den letzten Satz verstehe ich nicht richtig. Was spricht dagegen?

Eine Aufhebung der Frameratenbegrenzung von vorher z.B 20 auf jetzt z.B 50 oder unendlich erlaubt doch erst hohe Frameraten, dass wiederrum dann höhere Aktualisierungszyklen von den MIP Leveln der Bodentexturen was wiederrum scharfe Texturen bedeutet.

Von daher ist es doch nicht das Gegenteil sondern genau exakt meine Aussage die unscharfe Texturen mindern kann.