Hi,
ich bin warscheinlich der absolut suboptimalste Tread- Ersteller für dieses Thema, deshalb seht es als kleine Info einer wichtigen und wichtiger werdenden Thematik. Ich verlinke eich ganz unten zu einem informativen Tread, dort zieht euch bitte die Informationen heraus die ihr braucht oder googled weiter unter diesem Thema
. Um dennoch eine kleine Übersicht zu geben um was es mir hier geht, hier ein wenig Text zum Thema. Aber erst mein bekanntes Warum- und Wieso- Geschwafel..um das auch Anfänger mitkommen
-> Warum dieses Thema genau von mir (diesbezüglich völlig talentfrei bestückt), der kein technisches Hintergrundwissen hat?
Ich beschäftige mich nicht und auch nicht aus Langeweile mit Computerthemen, die ausserhalb des FSX liegen. Wenn, dann nur notgedrungen und wenn ich auf Fragen oder Probleme stosse - und selbst dann nur so umfassend wie absolut notwendig. Da ich im FSX Zubehörsoftware- Umfang ein breites Spektrum an für mich scheinbar sinnvollen Produkten nutze, kommen logischerweise Fragen auf. Ein Grund warum bei mir Fragen auftauchen ist der Produktumfang, und den Qualitätsanspruch des "Gesamtpackets". Diverse Software/Hardware- Änderungen landen hin und wieder auf einen "Optimierungsversuch" ein. Ganz ärgerlich, aber in der Tendenz leider steigend ist die Ursachenforschung bei Problemen von ungünstigen Produktüberschneidungen oder Entwicklerfehlern und derer Halbherzigkeit. Eine Ursache können unerfahrene Betatester sein, eine schlechte repräsentative Auswahl an Testern oder die Scheuklappen des Entwicklers, der sein Betateam ins Leere laufen lässt und trotzdem ein Produkt released.
Ich weiss, dass der FSX eine schnelle CPU braucht, also muss die Grundlage "meines" Systems eine schnelle CPU sein. Will ich hochaufgelöste Produkte nutzen und will ich in der Grafikqualität (hohe AA Einstellungen etc.) nutzen, muss die Grafikkarte ausreichend Leistung und Grafikspeicher haben sonst geht das nachweislich in die Hose
. Will ich das nicht muss ich die Schrauben runterdrehen und tweaks nutzen, die FPS generieren (immer) auf Kosten der Anzeigequalität.
Fehler, OOM´s, CTD´s oder unzufriedene Ergebnisse können das Leiden von uns allen sein. Da haben wir uns mit dem FSX die grösste Bastelbude ausgesucht. Die Ursachenforschung ist für "eigentlich nur fliegen woller" wich mich eine Geduldsprobe. User mit mehr Fachkompetenz können viele Fehler durch Basiswissen in den Kinderschuhen verhindern, erfahrene Flusianer wissen meist ebenso in anderen Angelegenheiten worauf man schauen muss. Unterhalte ich mich mit befreundeten Fachkompetenzen + erfahrenen Flusianern in einer Person ist es teils erschreckend wie gutgläubig man Installer ausführt und irgendwann Monate Später Fehler feststellt die hätten verhindert werden können - hätte man besser aufgepasst. Das ist aber nur eine Hürde von vielen Fehlermöglichkeiten.
-> So jetzt geht es endlich zum Thema 
:
Folgende Tools sind für einige PC+Flusi- Profis und "AVSIM"- Leser hier im Forum ein alter Schuh. Für weniger erfahrene Flusianer die diese Themen noch nicht kennen, will euch diverse Verlinkungen reinstellen, die eine enorme - um nicht gleich zu sagen "die" Tools sind zur optimalen Unterstützung. Sei es:
- Um Addons genauer unter die Lupe zu nehmen
- Um aktuelle Speichernutzungen in Echtzeit zu verfolgen und/oder aufzuzeichnen
- Mögliche Störquellen Ausfindig zu machen
- Eine "wahre" Orientierung, was das eigene System beim Ausloten der FSX+Grafik- Einstellungsmöglichkeiten verträgt
- Um einen OOM kommen zu sehen
..
Eine wichtige Grösse ist im Treadtitel angesprochene VAS, die "Virtual Size" der FSX.exe.
VAS: Ich zitiere von
Microsoft.com
..The virtual address space for a process is the set of virtual memory addresses that it can use. The address space for each process is private and cannot be accessed by other processes unless it is shared.
A virtual address does not represent the actual physical location of an object in memory; instead, the system maintains a page table for each process, which is an internal data structure used to translate virtual addresses into their corresponding physical addresses. Each time a thread references an address, the system translates the virtual address to a physical address.
The virtual address space for 32-bit Windows is 4 gigabytes (GB) in size and divided into two partitions: one for use by the process and the other reserved for use by the system. For more information about the virtual address space in 64-bit Windows, see Virtual Address Space in 64-bit Windows..
Microsoft Process Explorer:
Diese Tool von MS ist eine erweiterung des Taskmanagers und nur dort kann man die "Virtual Size" der FSX.exe live anzeigen lassen.
Nach der Installation des Tools müsst ihr die "Virtual Size" für alle laufende Prozesse im Process Explorer selbst einblenden lassen, das geht folgendermassen:
Process Explorer öffnen -> View -> Set Columns... -> Process Memory -> "Virtal Size" <--dort ein Häkchen setzen.
Aufgrund der 32Bit Anwendung wie unser FSX,
ist bei einer "Virtual Size" der FSX.exe von 4GB Ende. Und genau das kann man in diesem Tool einsehen. Das Üble an dieser VAS der FSX.exe ist folgende Feststellung: Werden grosse Texturen in der FSX.exe geladen wächst der Speicherbedarf an. Ändert man die Sichtfenster im FSX steigt der Speicherbedarf ebenfalls an, und geht nie mehr in die Theoretische Ursprungsgrösse zurück. Das soll nicht heissen nach dem Überfliegen eines gewaltigen Zubehörflughafens keinen abfallenden Speicherbedarf nach vorherigem Anstieg festzustellen - die Theoretische Ursprungsgrösse wird nie mehr erreicht. Überfliegt man mehrfach einen Flugplatz stellt man das Phänomen besser fest
--> Das bedeutet, die VAS der FSX.exe steigt im Endeffekt immer an, und zwas so lange, bis die 4GB VAS erreicht sind und der FSX den OOM bestätigt <--
Was können wir dagegen tun?
- Auf zu hoch aufgelöste Texturen verzichten
- Die Anzahl an Addons mit hohem VAS Bedarf in den jeweiligen Config- Menues runterregeln
- In der Szeneriebibliothek nur die aktuell genutzten Addons aktivieren bzw. Szeneriegebiete ausserhalb temporär deaktivieren
- Szenerie (bgl) Fehler oder doppelte bgl´s vermeiden, die lassen den Speicher ebenso vollaufen
UND
-DX10 verwenden. Die Speichertechnik ist eine andere und schafft Luft entgegen dem DX9- Modus. Ich muss hier aber sagen, das ich bis Dato noch kein DX10 nutze. Da müssen die Addonhersteller erst mitspielen um nicht neue Probleme zu generieren.
Das ist ein ernüchterndes Thema, dass wir aber durch dieses Tool in Echtzeit überwachen und somit auch steuern können. Ein Beispiel am Rande. Bei mir benötigt die PMDG 737NGX eine VAS von ca. 700-750MB gegenüber der default Cessna. Befinde ich mich also bei Nacht, Sauwetter, McPhat- Texturen (4096) auf einem "Mega Airport" in einer Flächenszenerie habe ich beispielsweise eine VAS der FSX.exe von 3,3 GB. Weiss ich nun, dass der Ziel- "Mega Airport" etwa 300MB belegt und der Flug 5 Stunden dauern wird - ist der OOM vorprogrammiert.
Ich kann also erahnen aufgrund der Daten, wann was passieren wird, das ist sehr hilfreich, eine Balance des FSX mit seinen Einstellungen zu finden um von Mega Airport zu Mega Airport fliegen zu können. Man hat die Möglichkeit schön ausprobieren, was den Bedarf minimiert und die Regler dementsprechend setzen um einen OOM zu verhindern.
-> Grafikspeicher:
Einige Einstellungen wirken sich nicht nur auf den VAS aus, sondern auch auf den Grafikspeicher. Habe ich eine Grafikkarte mit 1200MB Videospeicher und habe ungünstige Voreinstellungen, kann dieser ebenso ausgeschöpft sein. Das geht mit der NGX wunderbar. Hier ein bekanntes Tool um in Echtzeit die aktuelle GPU- Speichernutzung von NVIDIA Grafikkarten zu beobachten, Quelle: GPU-Z.de
GPU-Z + download
Auch dies dient zum gleichen Zweck wie der Process Monitor von Microsoft. Für mich ist das die einzige Chance meinen FSX auszuloten und Addons zu durchleuchten. Ich hoffe Addonhersteller nehmen trotz steigender Qualitätsansprücke Rücksicht auf unsere hier beschriebenen faktisch begrentzen Ressourcen.
Einer der das meines Erachtens vorzüglich mit äusserster Professionalität zeigt wie das geht, ist Umberto, der Cheffe von FSDreamteam.
Hier ein interessanter Link um sich mein ganzes Geschwafel in fachmännisch zu erlesen, allerdings in diesem Forum in englischer Sprache. Scrollt mal durch und liest die Beiträge von Umerto Colapicchioni alias "virtuali". Quelle: AVSIM Forum.
FSDreamteam CYVR Vancouver is out!
Hier ein Zitat von Umberto von Seite 10:
Obviously not. I'm saying that if you want to use many add-ons at the same time, you'll have to switch to DX10. What you guys don't seem to understand, is that this situation, sooner a later, would have happened in ANY CASE.
It doesn't have anything to do with FSDT products. It just happened here, because there are many available add-ons in this area, but it might happen again with any other scenery in a different area, or it WILL happen when the next great weather/texture/airplane product will come out, and everybody will want to use it together with ALL the other add-ons, forgetting that those 4GB are a FINITE resource, and it WILL be filled up someday.
Note that, switching to DX10 will not be the end of the troubles, this will save about 300MB, that with some stuffed systems and/or too high settings that are OOM-ing now, might just be what saves from a crash, but that won't last long. There will be add-ons coming out that will keep filling memory, and we'll surely discuss about this situation even with DX10, maybe the next year, maybe about the next scenery from someone else.
This is not a matter of FSDT, we just made one additional scenery, which runs perfectly well, that's just happened to be (and of course only for some users, because you see plenty of comments that don't have any problems with it) the last straw that broke the camel's back, but it happened to be in an area with many add-ons available, in a post-PMDG NGX world, in a place when it's *almost* always raining to begin with, so users with hi-res cloud textures and 3rd party weather engines, might noticed it even more.
As I've said, if we released CYVR a couple of years ago, before PNW and the NGX, this discussion would be about other products, OOM-ing an "airport that worked up to the day before". And it would have been wrong nonetheless.
It's a matter of understanding there are limits to what you can do with FSX and 4GB. And understanding that, you WILL have this problem with something else entirely (as if OOM didn't existed before CYVR...really ? ), sooner or later, because the more add-on will be released, especially those that could be possibly used together, the more the issue will hit you, because those 4GB limit will always be there, you have to learn how to MANAGE your stuff and make choices, either in the number of add-ons to use together OR in your settings.
»
Flugsimulator »
Flugsimulator »
Zitat
..The virtual address space for a process is the set of virtual memory addresses that it can use. The address space for each process is private and cannot be accessed by other processes unless it is shared.
