Liebe Leute!

Ich habe alle hier genannten Tools (und ein paar mehr) bez. der RAM-Optimierung bei mir noch mal getestet: keine Verbesserung. Hat mich nicht überrascht, solche Tools gibt es schon seit den Zeiten von Windows 1.0 und ich habe noch nicht einmal selber erlebt, dass es was bringt. Mal ganz zu schweigen von den vielen Postings in diversen Hardware-Foren der letzten 20 Jahre, die immer wieder auf die mehr oder weniger ausgeprägte Funktionslosigkeit hinwiesen. Ich kann mich an einen Fall echten Betrugs erinnern, wo ein solches Programm einfach eine völlig sinnlose Programmschleife drehte, ohne erkennbaren Zusammenhang mit dem RAM. Was immer allerdings möglich ist, dass so ein Tool Konfigurations-Probleme des Rechners beseitigt, im laufenden Betrieb sinnvoll zu funktionieren halte ich aber für ausgeschlossen, im Gegenteil hat man wieder ein Resssourcen verbrauchendes Hintergrundprogramm laufen.

Fortsetzung unten:

Letztlich ist Ruckeln meiner Meinung nach immer ein Ausdruck für einen Flaschenhals im System.

Man muss sich bitte immer vor Augen führen: Es ist nun einmal so, dass der Flusi eines der Programme sein muss, dass mit den größten und schnellstmöglich zu verarbeiteten Datein umzugehen hat, und das wird immer schwierig und anspruchsvoll sein. Und da die Systeme alle sehr unterschiedlich gestrickt sind, gibt es für die Programmierer keinen sicheren Weg, Probleme zu vermeiden. MS hat da mehrere durchaus sinnvolle Vorschläge für einen einheitlich ausgerüsteten und konfigurierten PC gemacht (gerade wieder) die aber am Markt nicht durchzusetzen waren.

Welche prinzipiellen Möglichkeiten für Flaschenhälse gibt es?

Gehen wir zum ersten mal davon aus, dass für eine derartig aufwendige Simulation immer die neueste Hardware benötigt wird. Das liegt am Prinzip des hohen Rechenaufwandes für die 3D-Berechnungen und die enormen Textur-Größen. Also muss für den FS9 davon ausgegangen werden, dass ohne 3GHZ CPU, mindestens 1GB schnellen und guten RAM, eine Direct9-fähige Graka mit 256 RAM sowie einem möglichst aktuellen Board Ruckeln immer wieder auftreten wird.

Das liegt keineswegs an MS, sondern an unseren immer steigenden Ansprüchen an eine fotorealistische Darstellung auch des kleinsten Details. Die Schere zwischen einem möglichst preiswerten System von Hard- und Software und diesem Anspruch ist prinzipiell nicht zu schließen, das schaffen selbst profesionelle Simulatoren zum tausendfachen Preis nicht!

Was kann man gegen einige wichtige Flaschenhälse nun tun, wenn man mal von Geld ausgeben absieht?

Da wäre die Art der Speicherung auf der Festplatte:

Dass die (getrennten) System- und Flusipartitionen immer nach eine Uminstallation defragmentiert werden müssen, sollte klar sein.

Für den Betrieb des Flusis werden aber auch Daten/Texturen in der Auslagerungsdatei gespeichert. Das ist wegen ihrer Größe unvermeidbar, es sei denn man hätte wirklich ausreichend RAM um sie im RAM zu halten, und da kann man erst ab 2 GB anfangen optimistisch zu sein (Ich habe 4 GB und es ist Ruhe). Während des Fluges wird die Datei wachsen, da wahrscheinlich ausgelagert werden muss und auch die Prefetching-Funktion des OS Dateien bereit halten will, da es erwartet, dass sie gleich wieder benötigt werden. Das ist im Office-Bereich sinnvoll, für den Flusi aber weniger, da man ja nur selten die gleichen Bereiche wieder überfliegt. Daher ist es eigentlich notwendig, nach oder vor jedem Flug den Prefetching-Status wieder auf 0 zu setzen. Das reicht aber noch nicht: Man muss nach jedem Flug die Auslagerungsdatei löschen, da sie sonst u.U. immer weiter wächst und dies führt zu Performance-Einbrüchen, je nach Defragmentierungsstand der Platte weniger oder mehr. Beides kann man aber nur erreichen, wenn a) im Flusi der Haken vor Texture-Speicher löschen gesetzt wird und b) das System nach jedem Flug wieder neu gestartet wird.

Man mag das für übertrieben halten, aber bez. der Ruckelei bringt es wirklich viel. (Mal abgesehen davon, dass in der realen Fliegerei noch viel mehr Zeit bei der Vor- und Nachbereitung eines Fluges vergeht...) Man mag auch wieder MS für soviel Umstand verantwortlich machen. Das wäre aber falsch, da nur ein universelles OS preiswert angeboten werden kann. Und dann muss man eben mit Kompromissen leben.

Damit aber noch nicht genug: Ich möchte nochmal darauf hinweisen, dass es sehr wichtig ist das OS, die Auslagerungsdatei und den Flusi sich nicht ins Gehege kommen zu lassen. Es muss nun mal im Betrieb von der Festplatte gleichzeitig geschrieben und gelesen werden. Wenn es nur eine Platte gibt, führt es zu Schreib-Lesekonflikten die auf jeden Fall ein Ruckeln provozieren. Optimal sind daher drei Platten, ein Kompromiss ist eine für OS und Auslagerungsdatei (in getrennten Partitionen) und eine für den Flusi. Nur eine Platte ist auf jeden Fall ein Problem, und zwar ein gewichtiges.

Noch einmal zur Auslagerungsdatei: Entgegen gelegentlich gehörten anderen Meinungen ist es richtig und Performance steigernd, sie nicht von XP verwalten zu lassen. Optimal ist eine Gesamtgröße des Speichers von 4 GB, also 4 GB minus RAM = X(Auslagerungsdatei). Diese Größe sollte man im Verhältnis 1:9 verteilen: Den kleinen Anteil auf der Systempartition (wird für den Kernel benötigt und ist zwingend, wenn die Wiederherstellungsfunktion von XP benutzt wird), den größeren Teil auf einer anderen Platte als der Flusi, nach dem oben beschriebenen Kompromiss bei nur zwei Platten auf einer anderen Partition des Systemlaufwerks.

Alle diese Einstellungen sind in der Registry machbar, schneller und einfacher geht es mit Tools (keines kann alles) wie TweakXp, WinExpert.net und CustomizerXP.

Es gibt noch jede Menge anderer Gründe für Ruckeln. Ein gewichtiger scheint die Verwendung von nicht FS9 kompatiblen Texturen zu sein. Da gibt es offensichtlich (bisher) undokumentierte Änderungen, die bis zu den hier umfangreich diskutierten CTD führen können. Das ist nun wirklich eine ärgerliche Geschichte, die man MS anlasten muss. Man sollte natürlich noch daran denken, keine leeren Texture-Ordner zu verwenden, die wir im FS8 noch eingefügt haben...

Alle potenziellen Perfomance-Verluste eines Systems können damit insgesamt natürlich nicht abgedeckt werden. Die liegen meiner Meinung nach in der Regel im System und nicht im Flusi begründet. Da es aber so viele Kombinationsmöglichkeiten gibt, ist keine Verbindlichkeit herzustellen.

Denken sollte man aber auch an Dinge, die nicht immer auf der Hand liegen, wie:

- Immer neue Treiber für das Board, vor allem für die AGP-Unterstützung wichtig.
- Shadowing von BIOS und Graka-Bios bei genügend RAM
- Updates des BIOS von MoBo und GraKa
- Latency des RAMs
- Regelmässig die Registry säubern
- optimalen L2-Cache
- Säuberung der Startdateien mit msconfig
- ?

Dieser Beitrag ist als Zusammenfassung meiner Sichtweisen gedacht.

Hallo Wolfgang.
ich glaube dein (wirklich unfassender) Beitrag fasst alles zusammen was zu diesem Thema zu sagen ist.
Zu deinen Erläuterungen habe ich aber noch ein paar Fragen:

Wiese muss ich in die registry un die Auslagerungsdateien festzulegen? Geht doch unter windows (xp) auch.

Soll man min und max auf gleiche Werte setzen?

Was ist prefetching status und wie setze ich ihn auf 0?

Im FS kann ich den Eintrag "Texturen speichern" nicht finden. Oder meinst du den Eintrag "Zwischenspeicher bei Beenden löschen" in der Sceneriebibliothek.

Soll man die Option "Auslagerungsdatei beim beenden von XP löschen" aktivieren (kann man mit xp antispy einstellen). Problem ist, dass windows viel länger beim Herunterfahren/ Neustart benötigt

Vielen Dank schon mal für deine Antworten

Also schaun mer mal:

1. Wieso muss ich in die registry um die Auslagerungsdateien festzulegen? Geht doch unter windows (xp) auch.

Das stimmt natürlich, ich habe das oben so zusammen gefasst, dass ein falsches Ergebnis für diesen Punkt heraus kam. Sorry.

2. Soll man min und max auf gleiche Werte setzen?

Ja!

3. Was ist prefetching status und wie setze ich ihn auf 0?

Jede Datei bekommt eine Ziffer von Windows zugewiesen, die sozusagen ihre Priorität beim Laden kennzeichnet. Damit wird das Laden häufig benötigter Dateien beschleunigt, z.B. wenn ich immer wieder am selben Word-Dokument arbeite. 0 ist die niedrigste Priorität. Bekommt eine Datei - z.B. im Flusi eine Texture - eine höhere Priorität, z.B. weil ich immer wieder vom gleichen AP starte, dann bleibt sie ewig in der Auslagerungsdatei, und die wächst und wächst. Setzen kann man den Status z.B. mit WinExpert.Net.

4. Im FS kann ich den Eintrag "Texturen speichern" nicht finden. Oder meinst du den Eintrag "Zwischenspeicher bei Beenden löschen" in der Sceneriebibliothek?

Ja, habe ich nicht so genau hingeschaut.

5. Soll man die Option "Auslagerungsdatei beim beenden von XP löschen" aktivieren (kann man mit xp antispy einstellen)? Problem ist, dass Windows viel länger beim Herunterfahren/Neustart benötigt.

Ja, unbedingt, sonst wächst die Datei zu schnell und defragmentiert sich dabei auch noch. Und man muss danm eben das System auch neu starten, da das im laufenden Betrieb nicht geht. Nachteil ist in der Tat der längere Shut Down, dafür geht aber der Start von XP und Flusi schneller. Gleicht sich aus.

Hallo Paul,

nachdem Wofgang in seinem Beitrag einen Teil seiner grundlegenden Feststellungen relativiert hat, will ich dir meine Meinung zum Sachverhalt kund tun:

Punkt 5 und 2 wiedersprechen sich, denn wenn die Auslagerungsdatei auf einen festen Wert festgelegt ist kann sie sich nicht vergrößern oder verkleinern. Selbst wenn sie von XP verwaltet wird, wird der maximale Wert als Speicherraum reserviert.

Zum Punkt 3:
Ich rate dringend davon ab in den komplexen Vorgang einzugreifen.

Zum Punkt 4:
Dies ist nur relevant, wenn der Simmer seine Szenerien von CD lädt und nicht alles auf der HD hat. Sollte wohl die Ausnahme sein.

Zum Punkt 5:
Das fragmentieren der Auslagerungsdatei wird vielfach deutlich überschätzt, denn nach dem Ausschalten und Neustart des Rechners existiert die Datei im Prinzip im jungfräulichen Zustand. Vorhandene (alte) Daten werden überschrieben, da die Datei nur temporär zur Auslagerung der Daten verwendet wird. Ausnahmen sind nur in der Größenordnung von etwa 20 MB. Wer seinen Rechner über Wochen nicht ausschaltet könnte an die Grenzen der Datei kommen. Aber auch nur dann, wenn das entsprechende Programm unsauber programmierrt wurde. Ansonsten sind die Programme so eingerichtet, dass sie die Datei wenig oder gar nicht verwenden. Wer denkt, dass z.B. ein Videobearbeitungsprogramm eine riesige Auslagerungsdatei voraussetzt irrt, denn die wird überhaupt nicht benutzt. Ebenso verhält es sich mit z.B. Paint Shop.

Ein Beispiel zum Punkt 5.
Ich starte den Flusi und stehe in EDDB und die Auslagerungsdatei lt. Taskmanager ist so um die 470 MB groß. Das ändert sich im Prinzip auch nicht nach einem längeren Flug. Nun wechsle ich nach EDDH auf die aktive RWy und sehe ein Anwachsen der Datei auf 1,2 GB(!). Ich beginne zu rollen und kurz danach kommt die Meldung, dass zuwenig Arbeitsspeicher vorhanden sei (eingestellt habe ich bei 1 GB RAM 1,5 MB Auslagerungsdatei). Ende vom Lied: Flusi beenden.
Nach langem hin und her, z.B. blieb die Datei 1,2 GB groß auch nach dem Wechsel nach EDDB, habe ich den "Übeltäter" gefunden. Eine Helgoland-Scenery ist schuld. Deaktiviere ich diese, ist die Datei ca. 600 MB groß und wenn ich mich nach EDDB "beame" sind wieder 480 MB zu sehen. An all dem ist nicht der Flusi sondern sind andere Programme schuld.

Zum Thema:
Ruckeln und 22 Frames müssen sich dann nicht ausschließen, wenn nicht genug RAM, aus welchen Gründen auch immer, zur Verfügung steht. Das Laden von Daten aus dem swap-file dauert zu lange und führt zum ruckeln. Im Normalfall und sauberer Programmierung reichen 512 MB für den Flusi aus. Wer 768 MB oder 1 GB sein eigen nennt ist auf der sicheren Seite.
Die Erkenntnis mit der Helgoland-Szenerie sagt mir, dass ich auf keinen Fall mehr als 1 GB verwenden werde, damit ich einen Hinweis auf solche Programme erhalte.

Hallo,

ich nöchte Euch die Illusion nicht nehmen, aber ich habe noch 2 wesentliche bisher nicht berücksichtigte Anmerkungen zu machen.

1. Den FS auf eine andere Platte zu legen ist nur dann sinnvoll, wenn die andere Platte auch an einen anderen IDE Kabel am Board hängt. Der IDE Bus ist so aufgebaut, das immer nur ein Platte gleichzeitig angesprochen werden kann.

2. Ihr beieindruckt mit 4GB RAM, jedoch bringt Euch das nicht viel. Windows XP kann einer Session (bzw. einen Programm oder Task) maximal 2GB zuordnen. Das heißt, der FS bekommt als Task maximal 2GB und kein Byte mehr. Es gibt eine Ausnahme, der AMD Opteron kann 3GB zuordnen.

Gruß
Juergen

Da muss ich wohl auf Wolf-Dieter antworten:

1. Punkt 5 und 2 wiedersprechen sich, denn wenn die Auslagerungsdatei auf einen festen Wert festgelegt ist kann sie sich nicht vergrößern oder verkleinern. Selbst wenn sie von XP verwaltet wird, wird der maximale Wert als Speicherraum reserviert.

Das stimmt nicht, denn der genutzte Teil kann sich vergrößern oder verkleinern!

2. Zum Punkt 3:
Ich rate dringend davon ab in den komplexen Vorgang einzugreifen.

Nein, das ist total unproblematisch.

3. Zum Punkt 4:
Dies ist nur relevant, wenn der Simmer seine Szenerien von CD lädt und nicht alles auf der HD hat. Sollte wohl die Ausnahme sein.

Stimmt nicht, es werden die zuletzt genutzen Teile zwischengespeichert.

4. Zum Punkt 5:
Das fragmentieren der Auslagerungsdatei wird vielfach deutlich überschätzt, denn nach dem Ausschalten und Neustart des Rechners existiert die Datei im Prinzip im jungfräulichen Zustand. Vorhandene (alte) Daten werden überschrieben, da die Datei nur temporär zur Auslagerung der Daten verwendet wird.

Ne, das ist ja das Problem, denn genau dabei wird defragmentiert.

5. Ein Beispiel zum Punkt 5.

Nach langem hin und her, z.B. blieb die Datei 1,2 GB groß auch nach dem Wechsel nach EDDB, habe ich den "Übeltäter" gefunden. Eine Helgoland-Scenery ist schuld. Deaktiviere ich diese, ist die Datei ca. 600 MB groß und wenn ich mich nach EDDB "beame" sind wieder 480 MB zu sehen. An all dem ist nicht der Flusi sondern sind andere Programme schuld.

Helgoland ist keine "falsch programmierte Ausnahme, sondern das gilt für alle komplexen Scemerys. Insofern wird das Gesamtsystem Flusi sich wie beschrieben verhalten.

6. Zum Thema:
Ruckeln und 22 Frames müssen sich dann nicht ausschließen, wenn nicht genug RAM, aus welchen Gründen auch immer, zur Verfügung steht. Das Laden von Daten aus dem swap-file dauert zu lange und führt zum ruckeln. Im Normalfall und sauberer Programmierung reichen 512 MB für den Flusi aus. Wer 768 MB oder 1 GB sein eigen nennt ist auf der sicheren Seite.
Die Erkenntnis mit der Helgoland-Szenerie sagt mir, dass ich auf keinen Fall mehr als 1 GB verwenden werde, damit ich einen Hinweis auf solche Programme erhalte.

Wie oben gesagt, Helgoland ist keine Ausnahme. Jede komplexe Scenery wird beim längeren Überfliegen diesen Effekt auslösen. Es ist richtig, dass viel RAM die beste Lösung ist. Mit 512 MB ist man im FS9 aber auf keinen Fall ausreichend bestückt.

Dann noch zu Paul:

1. Den FS auf eine andere Platte zu legen ist nur dann sinnvoll, wenn die andere Platte auch an einen anderen IDE Kabel am Board hängt. Der IDE Bus ist so aufgebaut, das immer nur ein Platte gleichzeitig angesprochen werden kann.

Das ist absolut korrekt.

2. Ihr beieindruckt mit 4GB RAM, jedoch bringt Euch das nicht viel. Windows XP kann einer Session (bzw. einen Programm oder Task) maximal 2GB zuordnen. Das heißt, der FS bekommt als Task maximal 2GB und kein Byte mehr. Es gibt eine Ausnahme, der AMD Opteron kann 3GB zuordnen.

Stimmt soweit, aber ich habe dann eben auch wirklich 2 GB und nicht x-System. Hintergrundprogramme dürfen auch laufen. Im übrigen wird die 64er Generation (ich habe schon eine solche CPU) das neu darstellen.

Ich bin dankbar für diese Hinweise, da rundet sich viel!

@siggie

Wo kann man das einstellen????
Bitte um Hilfe.
Danke
Markus

Hallo,

ich möchte mich hier auch einmal in die Diskussion einmischen, wenn
auch eher laienhaft. Ich habe mich teilweise auch mit Thema herumgeschlagen und dann einige der vorangegangenen Ratschläge be-
folgt. Was mir, nach meinen subjektiven Beobachtungen, am meisten geholfen hat, war der Einbau einer zweiten Festplatte, die ich ganz normal als slave angeschlossen habe. Desweiteren habe ich dann auch
noch "Clever Cache" eingesetzt. Hierdurch aber keine wesentliche
Verbesserung erzielt. Ebenso mit dem Defragmentierungstool der selben
Firma, obwohl ich den Eindruck habe, dass beide Programme nicht übel sind. Ich habe nun einen weitgehend flüssigen Bildablauf. (Schnell
auf Holz klopfen.)

Grüsse
Bernd

"In der Registry habe ich festgelegt, das der Kernel nicht ausgelagert werden soll"

Kann man mit dem Tool XP Antispay einstellen oder schau doch mal hier rein http://www.windows-tweaks.info/

Gruß sieggi