![]() |
Sehr interessanter Arbeitsspeicherartikel
Hallo Leute!
Habe diese interessante Seite zum Thema Arbeitsspeicher gefunden. Ich glaube da werden einige Fragen wie --Hab ich genug Arbeitsspeicher für meinen Flusi--halbwegs beantwortet. Ich habe selbst 1GB Arbeitsspeicher,128MB Grafikk. aber seit ich mit PSS A320 und MegaAirportFrankfurt unterwegs bin, stößt der Speicher an seine Grenzen. Wenn ich nähmlich nach der Landung in EDDF den Task Manager aufrufe und mir den zugesicherten Speicher anschaue so steht der bei 0.98-1.1GB. Bei Sichtwechsel usw.entstehen da sehr lange Ladezeiten. Grüße Harry http://www2.tomshardware.de/motherbo...117/index.html |
Interessanter Artikel, danke für den Hinweis!
Gruß Rolf |
Interessanter Artikel zum Thema "Was bringen 2 GB Ram":
http://www.computerbase.de/artikel/h..._was_2_gb_ram/ Was sind eure Erfahrungen? Was bringen 2 GB Ram im Vergleich zu "nur" 1 GB im Flusi? |
Re: Sehr interessanter Arbeitsspeicherartikel
Zitat:
Dabei ist die Sache so trivial einfach das man sie in einem Satz beantworten kann. Der Speicher muss so gross sein das er fuer die Anwendung ausreicht, swappen mangels Speicher bremst wegen der um den Faktor 1000 langsameren Platte. Die einzig relevante Frage ist demnach wieviel Speicher braucht der FS maximal. Und das kann nicht pauschal beantwortet werden sondern haengt auch von den verwendetetn AddOnScenerien ab und wenn sie schlecht gemacht sind gibt es Speicherlecks (fehlende Speicherfreigaben) und der Speicherbedarf steigt mit der Zeit immer weiter an. Gegen sowas ist selbst die maximal moegliche Aufruestung machtlos. |
Re: Re: Sehr interessanter Arbeitsspeicherartikel
Zitat:
Wichtig ist ob der Speicher für die Anwendung, eigentlich alle gerade aktiv laufenden Anwendungen ausreicht. Das ist auch das was ich zuvor schon immer bei der 2GB Ram Geschichte erwähnte. Da wird gesagt man braucht 2GB Ram bei dem Addon X. Das stimmt aber zum Teil überhaupt nicht. Es kommt oft darauf an was man sonst noch so hat. Das Addon X hat dann bei dem Anwender ev. nur den Ausschlag gegeben, dass ein zuvor schon nah an der 1GB Grenze arbeitender FS nun über 1GB kommt. Von daher immer die Empfehlung Speicherverbrauch mit dem Task Manager checken. Ist man hier sicher, dass man beim FS immer unter 1GB Ram bleibt, dann benötigt man keine 2GB RAM. Kommt man selten darüber, kann man sich immer noch überlegen ob es für diese Situation lohnt Speicher nachzukaufen. Auf jeden Fall ist es Unsinn generell zu sagen Du musst schon 2GB Ram haben, Du profitierst davon. |
Hallo zusammen,
kann es sein, daß die Speicherverwaltung des FS2004 eine gewisse Intelligenz hat? Seit ich meinen RAM auf 1,5 GB aufgestockt habe, hatte ich laut Taskmanager im Maximum 1,45 GB maximalen Speicherbedarf in einer FS-Sitzung. Vorher hatte ich nur 1 GB RAM und der Speicherbedarf ging nur selten über den vorhandenen Wert (in der Spitze hatte ich damals mal 1,2 GB Auslastung). Da stellt sich mir nun natürlich die Frage, ob 2 GB wirklich etwas bringen. Zumindest habe ich das leidige Thema der verschwommenen Geländetexturen mit 1,5 GB RAM nicht mehr so stark wie noch vorher. Jetzt könnte man ja versucht sein zu glauben, noch mehr Speicher verkürzen die Ladezeiten der Geländetexturen noch mehr. Dagegen spricht, daß ich keinen großen Unterschied bzgl. Nachladezeiten der Texturen bei AI-Fliegern zwischen 1 und 1,5 GB gemerkt habe, was mich eigentlich etwas wundert. Hat jemand da schon andere Erfahrungen gemacht? |
Zitat:
Wie gesagt kommt es natuerlich darauf an wieviel man von seinem Speicher denn ueberhaupt fuer den FS zur Verfuegung hat. Ein richtig grosser Batzen Speicher wird naemlich zum cachen der Plattenzugriffe von Windows verwendet was naetuerlich auch Sinn macht aber die fehlen dann natuerlich dem FS der dadurch eventuell sogar erst gezwungen werden koennte den fehlenden Speicher durch swappen zu kompensieren und Plattenzugriffe zu erzeugen. Das wird normalerweise dynamisch gemacht und um so mehr Speicher Windows findet um so mehr greift es sich auch dafuer. |
Zitat:
Der FS benötigt für die Bodentexturen nicht sehr viel Speicher, selbst bei Fotoscenery mit tausenden Fototexturen nicht. Die Terrainengine ist bewusst so programmiert, dass es hier auch bei Anwendern mit wenig RAM im Default FS noch funktioniert. Wäre der FS nicht so programmiert, würde der Default FS bei Anwendern mit nur 512 MB bei Fotoscenery arge Probleme bekommen. Wie gesagt in Deinem Fall wird noch ein anderes Problem gewesen sein. Die Ladezeiten der Texturen hängen auch überhaupt nicht mit dem Speicher direkt zusammen. Das entscheidende Kriterium ist die erreichte Framerate und die Lieferleistung des Festplattenverbundsystem. Klar wenn keine hohe Framerate erreicht wird, weiterhin zufälliger Weise ein bisheriger RAM durch viele Addons voll ist, nun auf Festplatte ausgelagert werden muss, von dort aber zeitgleich auch neue Bodentexturen angefordert werden müssen, weiterhin die Last durch anderen Objektcode hoch ist, dann hat man langsame Nachladeeffekte bei Bodentexturen. Nur wie gesagt der RAM ist hier nicht das eigentlich ausschlaggebende Kriterium. |
Hi,
als ich mein RAM von 512 MB auf 1024 MB erweiter habe, hatte ich ein "aha" Erlebnis. Den unterschied habe ich im FS deutlich gemerkt. Es lief deutlich flüssiger/glatter! Die Erweiterung von 1024 auf 2048 war kaum wahrnehmbar. Die Festplatte werkelt zwar weniger rum aber der FS bootet weder schneller noch habe ich dadurch mehr FPS bekommen. Die Texturnachladung ist auch nicht schneller geworden. Aber trotzdem habe ich das "Gefühl" es läuft alles ein wenig "glatter" Statt diese gelegentlich auftretende lästige ruckler von ca. 1 sek. sind diese jetzt vielleicht nur noch 1/2 sek. lang...aber trotzdem wahrnehmbar. Kurz: die Mehrkosten stehen m.E. in keiner gesunden Relation zur gewonnen Mehrleistung. |
Ah, ok. Kann natürlich sein, daß die Ladezeiten nicht nur von der Vergrößerung des RAMs profitiert haben. Wie wohl auf jedem Rechner ist mein Flusi eine Dauerbaustelle, an der sich häufig etwas tut.
Auch wenn 2GB nicht wirklich etwas bringen - so wie ich mich kenne, werde ich es doch mal ausprobieren. Wo stand denn noch gleich der Rechner mit einem 1GB-Riegel drin ... :D |
Zitat:
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. |
Zitat:
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 |
Zitat:
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 ;) |
Zitat:
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. |
Zitat:
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. Zitat:
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. |
Zitat:
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. |
Zitat:
Dieser Effekt tritt aber erst dann ein, wenn durch Addons usw. mehr als 1GB Ram benötigt werden. Hat man z.B nur 1GB RAM es wird aber mehr benötigt, dann muss ausgelagert werden. Das bedeutet Festplattenaktivität. Diese behindert dann aber das Nachladen neuer MIP Level der Fototexturen von Festplatte. Deshalb schrieb ich doch auch zuvor siehe oben: "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." Mit anderen Worten kurz wiederholt. Man benötigt als erstes ganz wichtig hohe Frameraten, weil dann von Festplatte mehr Ladezyklen für Texturmiplevel zur Verfügung stehen. Mit niedrigen Frameraten wird es nichts, selbst wenn man 20GB RAM hätte. Weiterhin ist es wichtig, dass das Nachladen von den MIP Leveln die ja auf der Festplatte liegen nicht behindert wird. Sprich andere Festplattenaktivitäten behindern das nachladen, dass können Auslagerungsprozesse sein, weil aufgrund von Addons der RAM bereits verbraucht ist. Ob das der Fall ist, kann man z.B mit dem Task Manager kontrollieren. Dann sieht man auch ob man von mehr als 1GB Ram profitieren wird. So wird z.B das nachladen der MIP Level nicht nur von ev. stattfindenen Auslagerungsprozessen auf Festplatte behindert sondern eben auch von Überwachungsfunktionen eines Virenscanners und von den Prozessen die sonst noch laufen selbst. Das führt dann weiterhin zum ruckeln. |
Ich wollte den einen Beitrag von oben noch mal ändern, war beim abschicken dann aber leider zu spät. Daher der Teil mit der Änderung hier noch mal.
Zitat:
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. Das wird eines der Basisprobleme gewesen sein. Denn eine Fotoscenery kann nun mal locker einen Informationsgehalt über 512MB haben. Man kam also nicht drum hin das Texturinformationen ständig während des Fluges abgefordert werden müssen. Ok man hätte die Nachladezyklen selbst von den Frameraten entkoppeln können. Aber warum sollte man das tun? Wäre das nicht unsinnig? Denn was soll man den Anwender sonst an die Hand geben. Etwa einen Regler wo er selbst bestimmen kann wie oft abgefragt wird? Was passiert aber bei sich ständig schwankender Performance die Belastung in der Scenery kann ja durch Addons ständig schwanken. Bricht dann das ganze restliche System zusammen, weil der FS jetzt nur noch Zeit in Bodentexturen investiert. Ich denke die Kopplung der Nachladezyklen an die Framerate ist schon sinnvoll gewesen, denn sie ist eine eindeutige Aussage (unabhängig vom dem was der Anwender am FS rumfummelt) wie stark das System gerade belastet ist. Zitat:
Ansonsten ist das ja im Prinzip die bisherige Lösung des FS2002 und FS2004. "die Nachladeaktivitaeten an die erreichte Framerate zu koppeln" schon exakt die geforderte Relation zur Leistungsfaehigkeit des Systems. Im Prinzip hat Microsoft genau Deine Forderung hier allerdings per Automatismus erfüllt. Habe ich eine gutes schnelles System und hohe Frames und begrenze die auch nicht, dann werden viele Texturmiplevel abgefragt. Wenn Der Rest dann auch noch mitspielt also wenig andere störende Prozesse laufen noch ausreichend RAM frei ist, dann habe ich auch scharfe Texturen. Habe ich nur wenig Frames werden auch nur wenig MIP Level abgefragt. Wenig abzufragende Informationen bedeutet zwar unschärfere Scenery aber auch weniger Belastung. Andere Prozesse stören visuell nicht so stark, da der FS eh nicht ganz so flüssig läuft. Von daher regelt sich der FS eigentlich schon ganz gut selbst. |
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
|
Ich denke es hat keinen Sinn darauf weiter zu antworten, was einige meinen was hier funktioniert und aus Ihrer Sicht machbar per Regelung wäre.
Man müsste zunächst vermitteln wie die Terrainengine mit Ihren Bodentexturen arbeitet. Ohne das besteht keine Grundlage um darüber weiter zu reden. Denn was geht und wie es geht, hängt von diesem Verfahren ab. Da nützt es nichts hier Aussagen zu machen von Reglern und Verhältnissen die man sich wünscht. Nur wie die Terrainengine genau arbeitet, dass jetzt zu erklären ist mir viel zu aufwendig. Das wird man irgendwann lesen können. Da habe ich schon sehr viel Text zu verfasst. Ich denke also ich investiere lieber Zeit, dass diese Doku endlich fertig wird, dann besteht hier eine eindeutigere Grundlage dazu wie die Terrainengine hier genau funktioniert. Dann wird man auch die Zusammenhänge erkennen wie die Effekte entstehen, warum es so und nicht anders ist. |
Zitat:
Wie aufwendig es waere und was geaendert werden muesste, da hast du natuerlich recht, weiss niemand ausser den Programmieren die den Quellcode kennen. Interressant ist nur ob sich diesbezueglich etwas beim FSX geaendert haben wird. Und um dies zu beantworten kann man sowieso nichts weiter tun als warten. Wenn es dann soweit ist werde ich mich hier nochmal melden um Lob oder Kritik zu verteilen ;) |
Wie gesagt das Terrainverfahren kann ich ziemlich genau erklären.
Was den FSX betrifft, gehe ich eigentlich ganz stark davon aus, dass sich das Verfahren ändern wird. Allein aufgrund der Screenshots habe ich den Verdacht hier könnte sich etwas gravierend geändert haben. Kann sein dass der FSX noch die alte Landclasstechnik unterstützt aber es scheint auch ein neues etwas anders funktionierendes System zu geben. |
Alle Zeitangaben in WEZ +2. Es ist jetzt 18:09 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag