VATSIM Germany Forum

Zurück   VATSIM Germany Forum > Flight Simulator > MS Flight Simulator X

MS Flight Simulator X Fragen zum Flugsimulator 10 von Microsoft

Antwort
 
LinkBack Themen-Optionen Ansicht
Alt 2015-03-22, 18:57   #1 (permalink)
 
Benutzerbild von Christian Wopp
 
Registriert seit: 2005-06-19
Ort: Erzhausen, neben EDFE
Alter: 41
Beiträge: 2.606
Danke erteilt: 827
1.676 Danksagungen in 839 Beiträgen erhalten
Standard OOM bei 2,7 GB des FSX

Jetzt bin ich überfordert. Ich habe 8 GB RAM, der FSX kann maximal 3,5 GB nutzen. Soweit so gut. Warum bekomme ich ein OOM bei 2,7 GB Speicherbedarf des FSX? MEMtest findet keine Fehler in den Arbeitsspeichermodulen. Was ist da los?

__________________
Gruß

Christian

Frankfurter Flusi-Stammtisch, mehr unter http://www.flusi-stammtisch-ffm.de/
Christian Wopp ist offline   Mit Zitat antworten
Alt 2015-03-22, 19:23   #2 (permalink)
 
Benutzerbild von Jörg Dolgner
 
Registriert seit: 2004-05-21
Ort: Dinslaken EDLD
Alter: 53
Beiträge: 3.809
Danke erteilt: 4.413
3.031 Danksagungen in 1.266 Beiträgen erhalten
Standard

Moin Christian!

Leider ist das, was der Windows Task Manager da anzeigt, nicht die eigentlich entscheidende Größe. Wichtig ist der für den FSX reservierte "Virtual Address Space" (VAS).

Anzeigen lassen kannst Du Dir den VAS beispielsweise mit dem Process Explorer aus der Sysinternals Suite. Es gibt auch ein LUA-Plugin für (registrierte) FSUIPC (bzw. für WideFS, bei mir erfolgt die Anzeige auf dem Remote-PC), das Dir den noch freien VAS anzeigt. Sollte beides mit Google nicht allzu schwer zu finden sein. Auf das Plugin bin ich vor einiger Zeit durch einen Forumsbeitrag hier aufmerksam geworden, also könnte auch eine Forumssuche weiterhelfen. Wenn Du nichts finden solltest, dann melde Dich noch einmal.
__________________
Tschö wa, Jörg

MQT66J ~~~ DLH6514 ~~~ D [C|E|F|G|H|I] JDO


Geändert von Jörg Dolgner (2015-03-23 um 01:06 Uhr) Grund: Typo
Jörg Dolgner ist offline   Mit Zitat antworten
Alt 2015-03-22, 19:43   #3 (permalink)
 
Benutzerbild von Klaus Basan
 
Registriert seit: 2011-01-14
Ort: Heidelberg
Beiträge: 1.465
Danke erteilt: 1.867
1.133 Danksagungen in 521 Beiträgen erhalten
Standard

Als Konsequenz (aus dem was JD schreibt), ggf. pagesize anpassen überprüfen.
Siehe hier, Antwort
__________________
Klaus Basan D[A|C|E]MBZ | VatGM - Flights on Google Map | swift Pilot client

Geändert von Klaus Basan (2015-03-23 um 13:57 Uhr)
Klaus Basan ist offline   Mit Zitat antworten
Alt 2015-03-22, 20:26   #4 (permalink)
 
Registriert seit: 2013-05-16
Beiträge: 220
Danke erteilt: 85
183 Danksagungen in 80 Beiträgen erhalten
Standard

Du brauchst kein LUA scrip und eine registrierte version von FSUIPC brauchst du auch nicht:
Damit kannst du dir die freie VAS anzeigen lassen.

Offset 024C, Type S32 und Display to FS Title bar anwählen und fertig!

__________________
Mit freundlichen Grüßen/kind regards
Patrick

Geändert von Patrick Meißner (2015-03-22 um 20:28 Uhr)
Patrick Meißner ist offline   Mit Zitat antworten
Alt 2015-03-22, 22:50   #5 (permalink)
 
Benutzerbild von Christian Wopp
 
Registriert seit: 2005-06-19
Ort: Erzhausen, neben EDFE
Alter: 41
Beiträge: 2.606
Danke erteilt: 827
1.676 Danksagungen in 839 Beiträgen erhalten
Standard

Ok vielen Dank erst mal, wie groß habt Ihr Euren virtuellen Speicher eingestellt?
__________________
Gruß

Christian

Frankfurter Flusi-Stammtisch, mehr unter http://www.flusi-stammtisch-ffm.de/
Christian Wopp ist offline   Mit Zitat antworten
Alt 2015-03-22, 23:30   #6 (permalink)
 
Benutzerbild von Klaus Basan
 
Registriert seit: 2011-01-14
Ort: Heidelberg
Beiträge: 1.465
Danke erteilt: 1.867
1.133 Danksagungen in 521 Beiträgen erhalten
Standard

Eigentlich kannst Du das auf "system managed" (Automatically manage ..) stellen. Voraussetzung: auf der Platte ist genug Platz. Bei mir sind es ca. 3,5GB.
Details: https://support.microsoft.com/en-us/kb/2860880

Falls es bei dir auf "auto" steht und die Platte genug Platz hat, sollte es damit eigentlich kein Problem geben.
__________________
Klaus Basan D[A|C|E]MBZ | VatGM - Flights on Google Map | swift Pilot client
Klaus Basan ist offline   Mit Zitat antworten
Alt 2015-03-23, 01:04   #7 (permalink)
 
Benutzerbild von Jörg Dolgner
 
Registriert seit: 2004-05-21
Ort: Dinslaken EDLD
Alter: 53
Beiträge: 3.809
Danke erteilt: 4.413
3.031 Danksagungen in 1.266 Beiträgen erhalten
Standard

Stop stop stop stop!

Der virtuelle Adressraum (virtual address space, VAS) hat nichts mit dem virtuellen Speicher (virtual memory, auch virtueller Arbeitsspeicher genannt) zu tun! Beides sind grundverschiedene Dinge, die eigentlich nur das Wort "virtuell" gemeinsam haben und die Tatsache, dass es letztlich bei beiden irgendwie um Speicher geht.

Der virtuelle Speicher ist das, was in Windows über die Auslagerungsdatei (page file) realisiert wird. Der virtuelle Adressraum (dessen Mangel für die OOMs beim FSX verantwortlich sein kann) ist aber etwas ganz anders. Und genauso wenig, wie der Einbau von mehr Speicher (über eine gewisse Mindestbestückung hinaus) gegen OOMs hilft, können diese durch Vergrößerung der Auslagerungsdatei beseitigt werden.

Letztlich ist das Thema zu komplex, um es mal eben in einem Forumsbeitrag abzuhandeln. Und als Nicht-Informatiker glaube ich zwar, das dahinter stehende Konzept verstanden zu haben, ob ich es aber auch (fehlerfrei) erklären könnte, ist eine andere Frage.

Hier noch ein paar Links zu dem Thema:

Ein kleinen Einstieg in das Thema VAS gibt es auch bei der englischen Wikipedia:

Wikipedia (en): Virtual address space

Aber da bitte der Versuchung widerstehen und nicht auf den Link zur angeblichen deutschen Version des Artikels klicken - der verweist nämlich exakt falsch auf den virtuellen Speicher, auch hier hat man die beiden Begriffe offenbar verwechselt: Wikipedia (de): http://de.wikipedia.org/wiki/Virtuelle_Speicherverwaltung. Immerhin: klickt man in diesem deutschen Artikel wieder auf den Link für die englische Version, landet man auch - dann korrekt - bei Wikipedia (en): Virtual memory.

Zum Schluss noch der Hinweis auf das von mir erwähnte LUA-Plugin für WideFS, das es hier bei AVSIM gibt. Sicherlich eine feine Sache, wenn man aus anderem Grund sowieso schon WideFS hat. WideFS extra dafür anzuschaffen lohnt sicher nicht, da ist der von Patrick aufgezeigte kostenlose Weg sicherlich erst einmal ausreichend. Danke an ihn dafür, das kannte ich noch nicht, werde ich persönlich allerdings nicht nutzen, da einerseits bei vorhandenem WideFS für mich nicht nötig, andererseits bei borderless angezeigtem FSX auch nicht funktionierend. O.k., man könnte es sich ja auch direkt ins FSX-Window einblenden lassen, aber bei der Allergie, die ich gegen das Auftauchen von das Realitätsgefühl stark störenden roten Schriften entwickelt habe, ist das sicherlich nichts für mich.

Und ja, auch die Methode von Patrick sollte korrekt den freien VAS anzeigen, Verwechslungen mit dem virtuellen Speicher liegen hier nicht vor.
__________________
Tschö wa, Jörg

MQT66J ~~~ DLH6514 ~~~ D [C|E|F|G|H|I] JDO

Jörg Dolgner ist offline   Mit Zitat antworten
Alt 2015-03-23, 09:19   #8 (permalink)
 
Benutzerbild von Peter Buschhorn
 
Registriert seit: 2008-04-20
Ort: Wyk auf Föhr
Beiträge: 813
Danke erteilt: 4.654
3.248 Danksagungen in 1.123 Beiträgen erhalten
Standard

in der Tat ist der Begriff hinter VAS komplett bescheuert gewählt. Man muss da halt unterscheiden, wie der Hauptspeicher organisiert ist, was das Betriebssystem daraus macht und wie Anwendungen damit umgehen.

Früher (zu den den Zeiten 6502, Z80, 8080 bis 8086) war es so, dass wenn das RAM belegt war, dann war Ende Gelände. Multitasking war damals noch hingekrückt mit dem Int 08, Speicher konnte im EMM (ihr erinnert Euch sicher alle an den A20 Handler ) verschoben werden, aber wenn voll, dann voll.

Spätere Generationen von Prozessoren griffen das Konzept des Linearen Adressraums auf. Bei den Intelprozessoren machte man sich die eigentlich für Pascal bestimmte Segmentierung des Speichers zu Nutze und spendierte u.a. Tabellen, die den pysischen Speicher organisierten. Gedacht war die LDT (die local descriptor table) für Anwendungsprogramme und die GDT (die global descriptor table) für geteilten Speicher, etwa für DLL's, IPC und lalalaa

In diesen Tabellen wurde für die Prozesse eingetragen, wo ein Anwendungsprogramm tatsächlich physisch im Speicher rumbommelt. Das ist meistens quer und bunt verteilt auf dem Hardware-RAM. Wenn ein Programm nun Speicher haben möchte, dann wird ein Eintrag in einer Tabelle vorbereitet und erst bei Zugriff auf diesen Bereich auch belegt; und zwar in 4k großen Blöcken (damals). Wenn man also ein Byte brauchte, waren gleich 4k weg. Diese Kacheln nannte man auch Seiten, daher paging. Vormals gab es nur das swapping mit der zugehörigen Swap Datei (heisst bei Linux auch heute noch so). Wirds also knapp im Laden, gibt's ein Faultsignal von der Hardware und das Betriebssystem kloppt lange nicht benutzte Kacheln anderer Prozesse auf die Platte.

Jeder Prozess (jedes Programm) glaubt, den Speicher schön von 0 an ohne Löcher durch nummeriert vor sich zu haben)

In den Einträgen der LDT/GDT stehen auch so Sachen wie Zugriffsrechte, Dirty und vieles mehr. Ein Prozess, der nun auf seine Daten, die vllt. eben wegen eines anderen Prozesses ausgelagert wurden, zugreifen möchte und in's Leere packt erzeugt einen Page-Fault und das Betriebssystem lagert die entsprechende Seite aus der Page/Swap Datei irgendwo im RAM ein, wo noch Platz ist.

Jetzt kann es zu thrashing (Seitenflattern) kommen, wenn ein anderer aktiver Prozess wiederum Speicher möchte und den von eben wieder verdrängt.

Der Programmierer und das Betriebssystem entscheiden zudem darüber, welche Programmteile nicht rausfliegen dürfen und welche direkt auf die Hardware zugreifen dürfen (Ring 0 von 3)

Weil jedes Programm glaubt, es habe 2^64 Adressen zur Verfügung, die auch schön linear der Reihe nach geordnet sind heisst diese Seite der Speicherverwaltung (MMU) "virtueller Speicher" weil er eben nur eine Illusion ist.

Jetzt kann das Betriebssystem selber entscheiden, wieviel Tabelleneinträge es einem Anwendungsprogramm maximal zuordnen will. In OS/2 waren es damals 512k und alles lief nur über die GDT.

Auch für die Tabellen<->Seitenzuordnung gibt es Caches, die Translation Lookaside Buffer... auch hier ist man bemüht, den so effektiv wie möglich zu nutzen, aber auch da gibt es Grenzen.

Wenn Windose entscheidet max. 2Gig pro Prozess, dann ist da softwareseitig Ende, die hardwäre könnte vielmehr. Das scheint dieses ominöse VAS zu sein, was technische Informatiker wie ich garnicht kennen, da Software und somit Babba
__________________

Mein Leben in der Nordsee... Blog
Peter Buschhorn ist offline   Mit Zitat antworten
Alt 2015-03-23, 15:03   #9 (permalink)
 
Benutzerbild von Klaus Basan
 
Registriert seit: 2011-01-14
Ort: Heidelberg
Beiträge: 1.465
Danke erteilt: 1.867
1.133 Danksagungen in 521 Beiträgen erhalten
Standard

Zitat:
Zitat von Jörg Dolgner Beitrag anzeigen
Stop stop stop stop!

Der virtuelle Adressraum (virtual address space, VAS) hat nichts mit dem virtuellen Speicher (virtual memory, auch virtueller Arbeitsspeicher genannt) zu tun! Beides sind grundverschiedene Dinge, die eigentlich nur das Wort "virtuell" gemeinsam haben und die Tatsache, dass es letztlich bei beiden irgendwie um Speicher geht.

Der virtuelle Speicher ist das, was in Windows über die Auslagerungsdatei (page file) realisiert wird. Der virtuelle Adressraum (dessen Mangel für die OOMs beim FSX verantwortlich sein kann) ist aber etwas ganz anders. Und genauso wenig, wie der Einbau von mehr Speicher (über eine gewisse Mindestbestückung hinaus) gegen OOMs hilft, können diese durch Vergrößerung der Auslagerungsdatei beseitigt werden.
Ja, eventuell kann man meine Aussage falsch verstehen. Ich hätte sagen sollen, pagefile überprüfen. Gegen das "NICHTS" oben lege ich VETO ein. Physikalisches RAM und pagefile beeinflussen die Vergabe des VAS. Hier berufe ich mich auf

Pushing the Limits of Windows: Virtual Memory, section Committed Memory

Leider geht die Begrifflichkeit wirklich durcheinander, aus dem oben genannten MR Artikel:
"There are two types of process virtual memory that do count toward the commit limit: private and pagefile-backed."

Hier ist "virtual memory" das, was JD als VAS bezeichnet.
Each process has its own virtual memory, called an address space, into which it maps the code that it executes and the data that the code references and manipulates

Aber - und das ist m.E. die richtige Kernaussage - wenn genügend reales RAM und pagefile zur Verfügung stehen, nützt eine weitere Vergrößerung nix mehr. So verstehe und teile ich die Aussage von JD. Und um das "wenn" zu überprüfen, sollte man (u.a.) kurz das pagefile überprüfen.

Was kann CW jetzt also machen? M.E. wäre das Vorgehen wie folgt.
  • Überprüfen, ob der OOM tatsächlich bei etwa 4GB verbrauchtem virtuellem memory (=VAS) erfolgt. Wie das geht, wurde ja beschrieben.
  • Jetzt gibt es m.E. zwei Mögichkeiten:
    • Ja, dann bekommt der FSX seine max. 4GB (64bit) und das VAS ist voll => dann muss man in den Erweiterungen usw. suchen.
    • Nein, der FSX bekommt keine 4GB VAS, dann hat das externe Ursachen
__________________
Klaus Basan D[A|C|E]MBZ | VatGM - Flights on Google Map | swift Pilot client

Geändert von Klaus Basan (2015-03-23 um 15:51 Uhr)
Klaus Basan ist offline   Mit Zitat antworten
Alt 2015-03-23, 16:00   #10 (permalink)
 
Benutzerbild von Peter Buschhorn
 
Registriert seit: 2008-04-20
Ort: Wyk auf Föhr
Beiträge: 813
Danke erteilt: 4.654
3.248 Danksagungen in 1.123 Beiträgen erhalten
Standard

jupp, so ähnlich. FSX ist ja nun ein Oldie und rennt im "compatibility modus" mit 32 bit. Damals hat standadmäßig alles oberhalb von 2 Gig sich Windows gegönnt (per Prozess)

0x00000000 bis 0x7FFFFFFF für den Prozess
0x80000000 bis 0xFFFFFFFF für Mutti äh Windows

Dann kam ja das 4GT, 4 Gigabyte Tuning. Wenn das erlaubt war, konnte der Programmierer mit der /LARGEADDRESSAWARE Option vom Linker das IMAGE_FILE_LARGE_ADDRESS_AWARE Flag im PE Header setzen, dann hatte man für die Anwendung 3GB
0x00000000 bis 0xBFFFFFFF per Prozess
0xC0000000 bis 0xFFFFFFFF Windows

Mit dem BCDedit Befehl konnte/kann man einen boot Eintrag ändern, der die Partitionsgröße (nicht Festplatte ändert

BCDEdit /set increaseuserva Megabytes

https://msdn.microsoft.com/en-us/library/ff542202.aspx

EDIT: ich seh grad, mit MSConfig.exe sollte es auch gehen.... bin Linuxer, sorry
__________________

Mein Leben in der Nordsee... Blog

Geändert von Peter Buschhorn (2015-03-23 um 16:02 Uhr)
Peter Buschhorn ist offline   Mit Zitat antworten
Antwort

  VATSIM Germany Forum > Flight Simulator > MS Flight Simulator X


Themen-Optionen
Ansicht

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an



Alle Zeitangaben in WEZ +2. Es ist jetzt 12:17 Uhr.


Powered by vBulletin® Version 3.8.4 (Deutsch)
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Template-Modifikationen durch TMS
© 2006 - 2018 vatsim-germany.org