|
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
Zitat:
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 |
Halo Bernd,
herzlich Willkommen! Falls Du einen zweiten IDE-Controller on Board hast (meistens der Fall) so versuch doch dort die zweite Platte mal als Master anzuschließen. CD-Roms o.ä. dann jeweils als Slave. |
Hallo Leute!
Ich habe auch mit den Texturen Probleme(siehe meinen Beitrag vom 08.01 in diesem Forum "PMDG Texturproblem"! Wie kann ich denn die Auslagerungsdatei vergrößern? Diese zeigt bei mir immer nur 106 MB im Task Manager an:confused:?!?Ich hab sie auch schon versucht zu vergrößern, aber der Manager bleibt immer bei den 106 MB! Bringt Cacheman etwas? MFG GERT! |
Auf Symbol Arbeitsplatz gehen, rechte Mousetaste,
Eigenschaften wählen, auf Erweitert gehen, auf Einstellungen gehen, Erweitert wählen und dann auf "Virttuellen Arbeitsspeicher Ändern" Mit dem Programm Chacheman habe ich keine Leistungssteigerung feststellen können. Gruß sieggi |
Auf wieviel soll ich den virtuellen Arbeitsspeicher erhöhen, und für welche Partition des Laufwerks(C:Windows, D:Office,E:Flusi)? Ich hab 1024 MB Arbeitsspeicher!
|
Hallo Gerd:
Meine Empfehlung: Insgesamt 2048 MB, jeweils min und max. (Option festlegen wählen, nicht durch XP verwalten lassen. Dies in c:, wenn Du eine zweite HD hast legst Du da dieselbe nochmal an. Dann sollte der Flusi aber nicht auf derselben HD liegen. Wenns geht sollten die Festplatten auch nicht am selben IDE-Kontroller hängen. |
Moin,
bei mir lagen die Ruckler daran, das ich meiner Netzwerkkarte keine feste IP gegeben habe. Wenn das nicht der Fall ist, wartet die Karte in regelmäßigen Abständen auf einen Server, der ihr eine IP-Adresse zuordnet. Also geh mal zu den Netzwerkverbindungen, laß dir die Eigenschaften deiner Netzwerkkarte zeigen und bearbeite die TCP/IP-Einstellungen. Von Automatisch beziehen auf feste IP wechseln. IP z.B. 192.168.100.1 SubNet 255.255.255.0 Ich hoffe es hilft auch bei dir. |
XP Indexdienst
Hi!
Ich habe mal schnell diesen Thread durchgeforstet, folgenden Tipp aber nicht entdeckt, obwohl er eigentlich einigen "Füchsen" hier bekannt ist: Unter XP gibt es einen Dienst mit dem Namen "Indexdienst", der eigentlich den Festplattenzugriff beschleunigen soll. Leider neigt dieser Dienst dazu, ständig auf den Festplatten "herumzuwurschteln" und eben dieses "pulsierende Ruckeln" im FS zu verursachen. Wenn dieser Dienst deaktiviert wird, ist bei mir zumindest kein Nachteil entstanden, aber das Ruckeln ist weg. Jeder kann diesen Dienst unter XP (Administratorrechte!!!) deaktivieren. Einfach Rechtsklick auf Arbeitsplatz - Verwalten - Dienste und Anwendungen - Dienste. Dann den Indexdienst suchen, rechtsklicken und Eigenschaften. Den Dienst beenden und Starttyp auf manuell oder deaktiviert setzen. Fertig! Vielleicht hilft es dem einen oder anderen. Gruß Thomas |
Hi Thomas,
kannst Du mir bitte erklären, was soll ich einstellen? Bei mir steht zur Auswahl, "manuell, automatisch, deaktivieren" Wie sollte es eingestellt sein? Was bewirken diese Einstellungen? Merci Gruss |
Hi Stefan, klick den Eintrag für den Indexdienst einfach doppelt an.
Im danach erscheinenden Fenster wählst du beim Starttyp "Manuell" aus. Wenn die Schaltfläche "Beenden" auswählbar ist dann klicke darauf um den Dienst sofort zu beenden. |
Hi Stefan!
Marcus hat es ja schon geschrieben, wie es geht. Ob Du "deaktiviert" oder "manuell" wählst, ist eigentlich egal. Denn nur bei der Einstellung "automatisch" wird der Dienst beim Systemstart mitgestartet. "Deaktiviert" heißt einfach nur, dass der Dienst überhaupt nicht zur Verfügung steht (aber trotzdem über das Dienstemenü gestartet werden kann). "Manuell" bedeutet, dass der Dienst gestartet wird, wenn ein benutztes Programm darauf angewiesen ist und den Start fordert. Da das beim Indexdienst nie der Fall ist, ist es gleich, ob Du das eine oder das andere auswählst. Hauptsache ist. dass der Dienst nicht läuft. Gruß Thomas |
Hi
Ich habe vor zwei Tage diese Info bez. IDE und zwei HDs am gleichen Strang gelesen und gewartet, ob dies jemand richtig stellt. Scheint noch nicht der Fall zu sein... Also, mach ich es. Das IDE pro Strang nur eine HD erträgt ist ein Märchen. Tut mir leid Jungs. Wer's nicht glaubt, kann z.B. bei c't in den FAQ's schauen. Diese Geschichte, eine der ältesten Ammenmärchen im IT. Bitte, wenn zukünftig jemand diese Info verbreitet, korrigiert es sofort. Sonst bauen unsere Freunde Ihre FlyTendos unnütz um. Danke. Bei der Bauweise, der Gehäuse muss man sich ja nur die Schwierigkeiten bei der Verdrahtung vorstellen. IDE hoch zum CD-Schacht und dann wieder runter zum HD Käfig... Gruss Jaap |
Zitat:
Ich habe seit Jahren am primären Controller zwei HD´s und am sekundären Controller CD- oder DVD-ROM (oder Brenner). Diese ganzen Geschichten mit bremsenden Millisekunden stammen aus Zeiten da man Zugriffszeiten von 25 ms hatte. Mit den heutigen HD´s und deren Zugriffszeiten und vor allem HD-internem Cache spielt da alles keine Rolle mehr. Insbesondere ist auch das I/O-Management auf dem Board wesentlich intelligenter geworden. Auch von mir ein Wort zum Einbau. In meinem Dell-Rechner wäre eine solche komische Trennung nicht möglich. Jaap hat schon beschrieben wieso. Ein Nachtrag noch zu den Diensten, dennen ja auch gewaltige Potenzen nachgesagt werden. Hier ein Link zu einlesen: http://www.tweakpc.de/berichte/tipps...p_tuning_2.htm |
Also macht mal halblang! Die genannze Zeitschrift lese ich auch, und zwar seit der Erstausgabe. So etwas hat da in dieser Weise nie gestanden, Ihr müsst schon exakt sein.
Richtig ist, dass es nur eine marginale Rolle spielt, aber wenn man das Thema schon ausreizen will, dann ist es eben doch ein messbarer Unterschied. Das habe ich noch vor kurzem getestet, mit mehreren neuesten Boards von Expox, Asus und MSI und neuen Platten. Es geht ja nicht um einen prinzipiell schnelleren Zugriff, sondern um das Vermeiden von Schreib/Lesekonflikten im Zusammenhang mit dem Swapfile, und bei den großen Dateien, mit denen der Flusi umgeht, sind die evident. Zwar wie gesagt nicht dramatisch, aber in einem Tuning-Gesamtpaket lohnt es sich doch. |
Hallo,
ich habe keinen geraten irgendwelche Umbauten am Rechner vorzunehmen. Des weiteren habe ich lediglich die Spezifikation des IDE Busses erläutert und dieser besagt, das 2 Geräte an einen Kabel nur simultan (Das heißt nicht gleichzeitig) angesprochen werden können. Auf die Vorherigen Postings angesprochen habe ich damit zur Aufklärung möglicher Probleme mit beitragen wollen. Da nicht jeder einen 3GHZ Rechner zu Hause hat und noch mit älterer Hardware fliegt kann dieses durchaus ein Punkt sein. Das dieser wir hier nur von Millisekunden reden ist richtig, aber auf einen langsamen System kann dieses durchaus eine Rolle spielen, zudem die Festplatten aufgrund Ihrer niedrigen Geschwindigkeit gegenüber anderen Speichermeiden im Rechner am schnellsten einen Flaschenhals darstellt. Also, bevor Ihr irgendwelche Fakten als Märchen darstellt fangt lieber mal an auch die Beiträge und nicht nur die Überschriften in der CT zu lesen. Gruß Juergen |
Hi Thomas, Markus,
herzlichen Dank für Eure ausführlichen Erläuterungen:) Bei mir war alles so eingestellt, wie Ihr es empfohlen habt. Anyway, mein System kann so schnell nichts mehr langsamer machen...;) :o :p P.S. Wolf-Dieter, auch Dir Danke vielmals für den interessanten Link :rolleyes: Gruss |
@Juergen
Bitte nicht gleich ärgerlich werden! Du hast was mißverstanden, weder ich noch irgend jemand sonst hat dich als Märchenerzähler tituliert. Solltest du es so verstanden habe, dann sorry, war nicht meine Absicht. Übrigens heißt "simultan" a) gemeinsam b) gleichzeitig. Erinnert sei hier an den Begriff Simultandolmetscher, der gleichzeitig während des Sprechens übersetzt. Und genau dieses findet im Rechner nicht statt! Alles findet sequentiell (nacheinander) statt. Wenngleich die hohe Geschwindigkeit es einem suggeriert, es geht nichts gleichzeitig. Ich habe vor über 30 Jahren in einem großen Rechenzentrum zugeschaut wie etwa 10 Drucker Papier auswarfen, das erst etwa 1 m nach den Druckern zu Boden ging. Auf meine Frage wer denn diese Drucker dermaßen ansteuert, wurde ich belehrt, dass die Drucker nicht gleichzeitig, sondern nacheinander angesteuert wurden. Seit der Zeit habe ich noch mehr Respekt vor dem, was im Rechner vorgeht. Was ich sagen will ist, wenn die Frage lautet, warum der Flusi ruckelt trotz 22 Frames, dann liegt es mit Sicherheit nicht daran, dass zwei HD´s an einem HD-Controller hängen und mann es durch das aufteilen auf zwei Controller beseitigen könne. Noch ein Wort dazu: Hier wurde u.a. auch von "... und bei den großen Dateien, mit denen der Flusi umgeht..." gesprochen. Ich habe in meinem Flusiordner die größte Datei mit knapp 40 MB, und das ist die Traffic.bgl. Alles was sonst interessant ist, ist maximal 4 MB groß. Wo sind denn die gewaltigen Dateien? Die heutigen HD´s haben Übertragungsraten von bis 20 und mehr MB/s. Die Zeiten, wo die IDE-Platten mit 2 MB/s aushereizt waren sind lange vorbei. Und eine solche alte Hardware hat hier niemand, denn auf solchen Platten könnte niemand den Flusi installieren, weil viel zu wenig Speicher vorhanden wäre. Ich stimme allen Argumenten zu, dass sie irgendwann ihre Berechtigung hatten, aber nicht mehr heute und mit aktueller Hardware. Und unter aktuell meine ich nicht 4 Wochen alt. Und was die 3 GHz angeht, die CPU ist völlig unausgelastet. Mit HT beansprucht der Flusi sie mal gerade mit 52 bis 54 Prozent (incl. aller weiteren Programme). Der Flaschenhals ist die Grafikkarte. Und wer beim Flusi die Frames drastisch drückt ist das Wetter, und hier insbesondere die Wolken. Wenn dann der RAM "ausgebucht" ist, dann findet ein hin und her mit dem Laden der vielen kleinen Dateien statt, was Zeit ( ja viele kleine Millisekunden) kostet und dann schließlich das Ruckeln verursacht. Im Zusammenhang mit diesem Beitrag habe ich festgestellt, dass im Gegensatz zum 2k2 der 2k4 die Dateien nicht mehr entlädt und somit ein langsames Anwachsen des belegten Speichers die Folge ist. Ich habe festgestellt, dass nicht "... wegen der komplexen Szenerien..." , sondern wegen dieses bug´s die Performance des Flusi nach gewisser Zeit, je nach RAM-Größe nach 20 min bis zu einer Stunde oder mehr, nachlässt. Ach ja, und danke für den Tipp in der c´t nicht nur die Überschriften zu lesen. Ich werde darüber nachdenken. |
Hallo Dieter,
ich verfolge die Ausführungen hier mit großer Aufmerksamkeit. Du sprachst davon, daß der FS9 den Speicher immer mehr aufbläht je länger man fliegt.Ja genau das habe ich auch schon beobachtet. Nun die Frage muß ich damit bis zum FS10 leben oder gibt es da eine Möglichleit es zu ändern? An einen Patch seitens MS glaube ich eher nicht. Gruss Reinhard |
Tja Reinhard, gute Frage.
Im Moment habe ich (noch) keine Antwort parat. Auf alle Fälle habe ich bemerkt, dass sich verschiedene Szenerien unterschiedlich verhalten. Z.B. die schon zitierte Helgoland-Szenerie ist ganz besonders "gut" und belegt gleich 1,3 GB(!). Das ist aber die Ausnahme. Ich vermute, wir müssen damit leben, denn nicht XP legt dieses Verhalten vor, sondern der Flusi. Verschieden Versuche über das XP-Speichermanagement haben bei mir zu keinem Erfolg geführt. Ein Patch von MS würde sicher Abhilfe schaffen, aber auf den werden wir wohl vergeblich warten. |
Hallo Dieter
Danke das Du das mal so offen ausgesprochen hast: Der FS9 ist nicht sauber und hat einen Bug. Ich habe ehrlich gesagt auch keine Lust solche Verrenkungen wie Wolfgang sie beschreibt zu unternehmen um mit dem Neuen einigermaßen zu fliegen. So etwas hat es solange ich mit dem Flusi fliege noch nie gegeben. Der FS2002 war jetzt genau auf dem Stand wie ich es mir vorgestellt habe und er läuft flüssig, sogar mit meinen 2 Grakas und 3 Monitoren was eben beim FS9 nicht der Fall ist. Insofern bleibt es bei mir dabei: FS9 ruht und FS2002 läuft. Vor allem vermisse ich nichts, im Gegenteil: Die unübertroffene PIC 767 läuft hier und auf dem FS9 nicht. Ich bin eigentlich immer sofort auf jeden Neuen umgestiegen weil es mit der Zeit sowieso nicht anders geht aber im Moment verspüre ich keine Lust dazu wobei ich immer noch damit spekuliere eine neue Graka (9800XT o.ä.) zu versuchen. Aber ich glaube die löst das Problem wahrscheinlich auch nicht komplett. Gruß Rolf |
So ist es Rolf,
ich hatte mir eigentlich vorgenommen, dass der 2k4 der letzte oder zumindest für eine gewisse Zeit der letzet Flusi sein sollte. Mittlerweile rücke ich von dem Vorsatz ab. Im Zusammenhang mit diesen Thread habe ich verschiedene Erkenntnisse gewonnen, die es einen überlegen lassen nicht doch auf den 2k2 zurück zu gehen. Auch bin ich zu der Erkenntnis gekommen, dass die Grafikkarte gar nicht genug Power bringen kann. Sie ist nach wie vor der Flaschenhals, zumindest bei aktuellen Systemen mit den Power CPU´s von Intel und deren Chipsatz. Ob das uneingeschränkt für AMD auch so gilt kann ich nicht sagen, aber ab CPU´s mit 2,5 GHz und darüber auf alle Fälle. Zu den (AMD-)Chipsätzen kann ich mir kein Urteil erlauben. |
Hallo Dieter,
habe mich wieder beruhigt und bin auch nicht böse :-) Gruß Juergen |
Jut so, war auch nicht böse gemeint...
|
Zitat:
|
Dieter,
99% Zustimmung (und allgemein Hochachtung vor dem angenehmen Ton, in dem die Diskussion hier im Thread geführt wird) :) warum nur 99% ? Zitat:
Die anderen 50% werden dann netterweise für den restlichen Kram verwendet, so dass HT eben doch noch was bringt, wenn auch viel weniger, als manche denken mögen. HansJürgen |
"Auch bin ich zu der Erkenntnis gekommen, dass die Grafikkarte gar nicht genug Power bringen kann. Sie ist nach wie vor der Flaschenhals, zumindest bei aktuellen Systemen"
Ist schon mal ein guter Ansatz. Hat da schon jemand mal Testversuche mit Grakas gemacht?. Bei Flightxpress wurde dies mal getestet, aber da war von einem Flaschenhals nicht die Rede. Hatte Probeweise FS 2002 und FS 2004 drauf. Musste allerdings feststellen, das der Bildaufbau beim FS 2004 wesentlich besser war als beim FS 2002. Von den FPs waren alle beide gleich. Das der FS 2002 besser läuft als der der neue habe ich nicht feststellen können. Ich persönlich werde den FS 2004 etwas weiter ausbauen und dann auch weiterhin behalten. Glaube nicht, das ich dann auf den FS 10 gehen werde. Gruß sieggi |
HanJürgen,
es ist völlig richtig was du sagst, der Flusi "verlangt" immer (fast) 100% der CPU. Es gibt aber eine Reihe von Fällen, bei denen das nicht so zu sein scheint. Beispiel: Der PSS-A320 steht auf dem RWy und die CPU1 zeigt 99%, die CPU2 dümpelt bei 1 bis 3%. Nun wechsle ich (nur) das Flugzeug (z.B. einen A310) und die CPU1 hat etwa 30% und die CPU2 etwa 70%. Nun wechsle ich erneut den Flieger und die CPU1 hat 1 bis 3% und die CPU2 hat 100%. Dies lässt sich aber immer wiederholen und ist nicht mal so und mal so! Eine schlüssige Erkärung habe ich nicht dafür, ausser dass XP eine wie auch immer geartete Intelligenz bei HT walten läßt. Meiner Ansicht (und Erfahrung seit Mai 03) nach ist es nicht relevant, ob ein Programm HT unterstützt. Es ist XP welches die Steuerung übernimmt. Noch ein Beispiel: Der Flusi läuft, CPU1 hat 99% und CPU2 3%. Nun holt sich FSMeteo seine Daten online. Die CPU2 geht hoch auf 80% und dem Flusi ist nicht anzumerken, dass da was im Gange ist. Gleiche Ausgangsbedingungen, nur das Wetter holt sich nicht FSMeteo, sondern der FLsui selbst. Was passiert? CPU1 bleibt auf 100%, die CPU2 bleibt auf 3% und der Flusi ruckelt ein wenig. Also in Summe aller Erfahrungen halte ich HT auch für den Flusi für eine durchaus interessante Sache. @Sieggi Ich neige tendenziell zu deiner Meinung. Im FS10 werden dann die Wartenden auf der Terrasse winken oder so was ... |
@Sieggi
Ich neige tendenziell zu deiner Meinung. Im FS10 werden dann die Wartenden auf der Terrasse winken oder so was Hallo Dieter, klasse Antwort. Vermute ich auch mal. Wenn mal sich hier alles durchliest, dann muss man vermuten, das diese nicht nur ein kleines Problem beim Flusi darstellt. Wenn man diese Sachen alle bereinigen will, so muß doch der Flusi kompett neu erfunden (programmiert) werden. Da aber die Viehlzahl der Nutzer sich den Flusi ohne Adons kauft, wird für den Rest der Nutzer nicht viel übrigbleiben. Ich denke nicht, das sich MS wegen einiger eingfleischter Flusi Fans da etwas tun wird. Gruß sieggi |
Liebe Leute,
es wird dabei bleiben, dass der Flusi ein Kompromiss aus Spiel und Simulation bleiben wird, sonst wird es dafür keinen Markt geben. Dasselbe gilt für das Betriebssystem auf dem er läuft, auch hier kann die Anwendung Flusi nicht optimal unterstützt werden. Gutes Beispiel ist das Handling des Prefetching, was da für Office sehr sinnvoll und nahezu unverzichtbar ist, ist für den Flusi eher kontraproduktiv. Ähnliches gilt auch für die Hardware, Stichwort HT. Dazu kommt eines der großen Vorteile des PCs: seine freie Konfiguration. Das schafft Probleme für unerfahrene Anwender, ist aber für den Poweruser ein Segen. Was man da an Optimierung machen kann, sollte man auch tun, ich sehe da keine "Verrenkungen". Die momentanen Probleme sind unübersehbar, aber sie waren auch bei anderen Generationswechseln evident. Ich halte sie für prinzipiell nicht für vermeidbar, da eine fehlerfreie Endentwicklung nicht möglich ist. Wer schon mal programmiert hat, weiß um die Unmöglichkeit der Fehlerfreiheit. Mal ganz zu schweigen vom Open Source Bereich, wo die Probleme noch größer sind, weil so viele mitmischen, nur spricht niemand darüber. Der FS hat auch diese "Schwäche" der relativen Offenheit. Übrigens sehe ich die Probleme beim genauen Hinsehen als nicht so gravierend an. Meiner Meinung nach liegen sie vor allem im Textur-Bereich, und da in zwei Bereichen: Einmal das Speicherhandling und zweitens die generelle Struktur der Texturen, siehe die CTD-Threads. Das wird man aber in den nächsten Monaten in den Griff kriegen, so wie es bisher bei der Veröffnetlichung der SDKs immer war. |
Hallo allerseits!
Ich hatte die gleichen Probleme wie am Anfang beschrieben, also dieses nervende "Zucken", besonders schlimm in Kurven und bei Start und Landung. Ich habe eigentlich ein sehr starkes System und bis ich von meinen flightproject Kollegen den Hinweis zu diesem topic bekam, suchte ich lange vergebens nach Tipps zu diesem Problem. Ich hab mir eine 2. Festplatte (80gb) zugelegt und beide auf ein Kabel legen müssen, weil kein bus mehr frei war. (was vielleicht nicht so arg ist) Danach den FS9 alleine auf die 80gb Platte geschmissen. Partition auf die Platte mit Windows, darauf 3gb Auslagerungs-space festgelegt und 400mb auf C: direkt. (wie erwähnt für den kernel???).... Soweit so gut, alles defragmiert, indexdienst aus, "Zwischenspeicher beim Beenden" löschen im Flusi angekreutzt und mit "xp antispy" die Option "Auslagerungsdatei löschen" auch aktiviert. Beim ersten Test waren die Stocker nicht mehr so schlimm wie am Anfang aber sie sind immer noch da :mad: :mad: :heul: Ich kann glaub ich keine 3. HD einbaun weil kein Stecker mehr frei ist. Es sei denn es gibt Kabel mit 3 Stecker??? (kenn mich da nicht aus) Tja, also, es ist dadurch etwas besser geworden aber noch lang nicht weg. :rolleyes: Was kann ich noch machen??? lg. manu |
Servus Manuel,
freut mich, daß mein Hinweis auf dieses Forum etwas geholfen hat. Zum Problem selber kann ich dir nichts sagen, nur daß du eventuell die beiden Festplatten auf unterschiedliche Busse hängen könntest - mußt du halt CD-ROM oder DVD auf den anderen BUs umhängen. Mehr als 2 Geräte kannst du bei IDE nicht an einen Bus hängen! Dafür müßtest du dir ein SCSI-System besorgen - das ist aber um sehr viel teurer als IDE. |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 04:46 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag