German Railroads Forum

Hallo Gerhard,

es gibt schon eine elegante Möglichkeit dem MSTS nur einen Kern zu zuweisen und das für ständig.
Karsten Pohl hat dazu eine Anleitung ins Forum gestellt. Ich wende diese Methode erfolgreich an und habe dem MSTS
den Kern 1 von 4 Kernen zugewiesen. Kern 1 deshalb, weil der MSTS ja von Hause aus nur einen Kern kannte.
Also ausprobieren. Meine Meinung: Seit dem läuft der MSTS problemlos und stabiler.

Gruß
Detlef

hmm - interessanter Artikel...

Es scheint ja aber eher um das Mobil-Segment zu gehen. Der Trick scheint ja darin zu bestehen, die Pipelines einer CPU besser zu nutzen - ein ähnlicher Gedanke wie beim Hyperthreading, nur viel konsequenter. Große Teile einer CPU warten ja die meiste Zeit nur darauf, dass ein anderer Teil der CPU mit seiner Arbeit fertig wird. Am Ende soll die gleiche Performanz bei wesentlich niedrigerem Takt stehen, um Energie zu sparen. Und Energie ist speziell in Mobilgeräten ein kostbares Gut.

Eine Single-Thread-Anwendung wird dadurch aber nicht auf mehrere Kerne skalierbar. Das wird ja auch gar nicht behauptet. Der Thread wird zerhackt und die Bruchstücke (im Artikel "Threadlets" genannt) werden dann (Zitat) "nicht unbedingt wie sonst in den Multi-Core-Architekturen üblich 'parallel', sondern 'concurrent' ausgeführt. Das heißt sie können sich zeitlich nur teilweise oder auch gar nicht überlappen." (Zitat Ende). Es geht wohl eher darum, die einzelnen Threadlets aller Threads so auf die CPU-Kerne zu verteilen, dass eine optimale Auslastung der in Silizium gegossenen Transistoren dabei herauskommt. Darum wird auch so auf den IPC-Werten herumgeritten...

Ich halte es auch für extrem schwer, eine Single-Thread-Anwendung wirklich parallel auf mehrere Kerne zu verteilen. Spätestens wenn eine Operation das Ergebnis der vorhergehenden Operation benötigt, fliegt einem die Geschichte um die Ohren. Das macht ja gerade die Kunst bei Multi-Thread-Anwendungen aus: Eine Aufgabe in viele voneinander unabhängige Teilaufgaben zu zerlegen und die Ergebnisse am Ende wieder zu sammeln und zu einem Gesamtbild zusammenzufügen.

Wenn ich mir dann überlege, dass der MSTS schon zu Abstürzen neigt, sobald die Ausführung von einem Kern auf einen anderen springt, was wir ja über den Zauber mit der Kernzuweisung zu verhindern suchen (s. Beitrag von Detlef), dann möchte ich nicht wissen, wie er reagiert, wenn er zur Bearbeitung in der CPU komplett zerlegt und auch noch in den Befehlssatz eines VISC-Prozessors konvertiert wird. Wahrscheinlich gibt es dann wieder die schöne Meldung "Microsoft Train Simulator funktioniert nicht mehr."

Hallo Gerhard,

Zitat von »gerhard«

Wer also ein Programm auf einen Kern festlegt stellt sich in Sachen Performance selbst ein Bein.

Es ist prinzipiell richtig, dass ein Eingriff in den Job-Scheduler (über die Methoden der Kernzuweisung) seit Windows Vista in aller Regel nur Nachteile hat. Rein rechnerisch muss die Kernzuweisung einer Anwendung einen Performanzverlust für diese Anwendung darstellen. Es sei denn, es würde gelingen, alle anderen Theads von diesem einen Kern fernzuhalten - dann könnte es sogar einen winzigen Performanzgewinn geben. Aber - es lassen sich nicht alle Threads von einem Kern fernhalten. Der Betriebssystem-Core und ihm sehr nahestehende Dienste laufen unbeirrt auf allen zur Verfügung stehenden Kernen und ignorieren stumpf irgendwelche Versuche, sie dort wegzuziehen.

Bekannt ist aber auch, dass es sehr alte Anwendungen gibt, die mit Multi-Core-Prozessoren ihre Probleme haben. Hierzu gehören vor allem sehr hardwarenah programmierte Spiele. Der MSTS gehört leider dazu. Es gibt dazu auch einen Beitrag im MSDN, wo Microsoft genau diesen einen Fall als Grund für einen gerechtfertigten Eingriff in das Job-Scheduling von Windows nennt.

Das Problem liegt hier in der Nutzung der Prozessorregister, wo es einige schmutzige Tricks gab, um die Performance der eigenen Anwendung zu erhöhen. Diese Tricks gehen aber davon aus, dass der eigene Thread, sobald er wieder an der Reihe ist, auf denselben Registersatz trifft. Auf einem Ein-Kern-Prozessor war das so sicher, wie das Amen in der Kirche. Die Welt hat sich allerdings gewandelt. Da in Mehrkern-Prozessoren in der Regel jeder Kern seinen eigenen Registersatz besitzt (von einigen AMD-CPUs abgesehen), funktionieren diese Tricks nicht mehr, wenn der Thread plötzlich auf einem anderen Kern läuft.

Der MSTS stürzt z.B. reproduzierbar in bestimmten Situationen ab. Die Abstürze finden in aller Regel beim Auftauchen eines KI-Zuges statt, sobald er in Hörweite kommt. Wenn man mal zufällig einen Speicherpunkt einige Sekunden vor einer solchen Begegnung gesetzt hat, also der Ort und die Zeit der Begegnung immer wieder hergestellt werden können, wird der MSTS, wenn er einmal abgestürzt ist, von diesem Speicherpunkt aus immer abstürzen. Eine Kernzuweisung löst die Situation auf.

Ich habe seit der Kernzuweisung nicht einen einzigen Absturz mehr gehabt - es sei denn ich habe beim Experimentieren mit Konfigurationsdateien einen Fehler gemacht. Ohne Kernzuweisung läuft der MSTS bei mir mäßig stabil, d.h. ich komme durch längere Aufgaben häufig nicht "am Stück" durch.

Daher meine klare Empfehlung für die Kernzuweisung beim MSTS - trotz der Nachteile, die man sich vielleicht an anderer Stelle einkauft.

Im von Detlef angesprochenen Beitrag habe ich eine Methode vorgestellt, die Handarbeit oder externe Tools überflüssig macht. Vom Einsatz externer Tools zur "Optimierung" kann ich nur dringend abraten - Defragmentierer für konventionelle Festplatten mal ausgenommen.

Der angesprochene Beitrag findet sich in den FAQ (<-- hier klicken)

Zitat von »gerhard«

Moderne Prozessoren können zwar einen Kern hochtakten wenn die anderen nicht benutzt werden, wie Messungen gezeigt haben geschieht dieses aber stets nur kurzfristig weil die höhere Wärmebelastung nicht dauerhaft abgeführt werden kann.

Der Grund dürfte wohl kaum die Wärmebelastung sein - es sei denn, das Kühlsystem ist schlecht dimensioniert. Der Grund für das Heruntertakten ist ganz einfach: Es gibt zu viele laufende Prozesse im System, die natürlich über die Kerne verteilt werden.

Zur Wärmebelastung: Ich habe einen i5 3570K im Rechner stecken. Er ist mit 3,4GHz angegeben, wird aber - zumindest auf Gigabyte-Mainboards standardmäßig mit 3,6 GHz betrieben. In der angesprochenen Turbo-Boost-Funktion taktet er auf 3,8 GHz hoch.

Ich betreibe den Prozessor mit 4,3 GHz auf allen vier Kernen (ohne weitere Takterhöhung bei weniger aktiven Kernen) und bleibe selbst im Sommer noch etwa 30°C unter der maximal zulässigen Temperatur (nach 2 Stunden Volllast mit Prime95). Auf dem Prozessor sitzt ein höherwertiger Luftkühler mit einem einzelnen Ventilator. Aber selbst der Kühler aus der Intel-Box schaufelt die Wärme innerhalb der Grenzen weg - macht nur viel Lärm dabei.

Günstige Massen-Notebooks könnten da allerdings in Probleme kommen, da dort die Kühlsysteme nicht zwangsläufig auf Dauer-Spitzen-Last ausgelegt sind. Der Trend, die Geräte immer kleiner werden zu lassen, macht ausreichende Kühlsysteme immer teurer...

Hallo,

Zitat von »gerhard«

Ich weiß ja nicht was du da für eine CPU/Kühler Kombination betreibst

CPU: Intel Core i5 3570K
Kühler: EKL Alpenföhn Matterhorn rev.B (Lüfter ist sogar auf der "falschen" Seite (saugend) montiert, da Speicherriegel im Weg)

Zitat von »gerhard«

dass du die TDP derart überreizen kannst

Ich betreibe die CPU innerhalb der Spezifikationen von Intel. Der Core i5 3570K hat sehr viele Reserven - eine Eigenschaft, die man auch seinem Nachfolger Core i5 4690K nachsagt. Diese beiden CPUs sind da aber auch recht ungewöhnlich.

Die spezifizierten Limits würde ich verlassen, wenn ich noch höher takten würde. Dann müsste ich nämlich die Kernspannung künstlich anheben, um die CPU stabil zu halten. Dann klettern aber auch die Leistungsaufnahme und die Temperaturen sehr schnell in kritische Bereiche. Das ist es nicht wert, denn geschenkt sind die CPUs ja schließlich auch nicht .

Ich kann für mich Karstens Hinweise zur " Einkernzuweisung " nur bestätigen. Fahre viel auf der SOB oder der TRAT 324 zur Zeit 7 h Güterzugact von @Alcapone. Seit dem ich den Zuweisungspfad meiner Train.exe ( C:\Windows\System32\cmd.exe /c start /high /affinity 0x01 "MSTS auf CPU-0" "C:\Train\train.exe" -mem:2048 -timeacceleration -nofiltercab ) so geändert hatte, habe ich eigentlich nur noch hier und da Abstürze wenn ich beispielsweise in großen Bahnhöfen mit der Tastenfolge 1 - 5 - Klavierspiele- .

Für mich ein großer in Schritt in Richtung Fahrfreude.

Schönen Sonntag

Schnell heißt nicht zwangsläufig laut

Man kann auch einen schnellen Rechner leise bauen. Da mein Rechner im Wohnzimmer steht, hatte ich strenge Auflagen von der Regierung bekommen

Zitat von »Karsten Pohl«

Das Problem liegt hier in der Nutzung der Prozessorregister, wo es einige schmutzige Tricks gab, um die Performance der eigenen Anwendung zu erhöhen...
Diese Tricks gehen aber davon aus, dass der eigene Thread, sobald er wieder an der Reihe ist, auf denselben Registersatz trifft...
Da in Mehrkern-Prozessoren in der Regel jeder Kern seinen eigenen Registersatz besitzt, funktionieren diese Tricks nicht mehr, wenn der Thread plötzlich auf einem anderen Kern läuft.

Der MSTS stürzt z.B. reproduzierbar in bestimmten Situationen ab. Die Abstürze finden in aller Regel beim Auftauchen eines KI-Zuges statt, sobald er in Hörweite kommt...

Interessante Info, Danke für die Erklärung.
Das "Warum" für dieses Problem war mir nämlich nicht bekannt.

Was mir allerdings noch auffällt, ist das unterschiedliche Verhalten von Win XP und 7-64.
XP ist bei mir sehr stabil gelaufen, Win 7 ist dagegen etwas zickig. Bei XP gab es "Mega-Ruckler", wo der MSTS mal eben für mehrere Sekunden eingefroren war, danach lief er aber wieder. Unter Win 7 stürzt der MSTS bei Problemen dagegen verzugslos ab.

Hallo Kris,

die Mega-Ruckler haben ihre Ursache vermutlich im Nachladen von Daten von der Festplatte. Ich habe es auch beobachtet, dass der MSTS unter Windows 7 bei zu langen Nachladezeiten (im Bereich von ein bis zwei Sekunden) den Schirm dicht macht. Warum es hier einen Unterschied zwischen Windows XP und Windows 7 gibt, kann ich aus dem Stand nicht beantworten. Ich habe eine Vermutung, die aber rein spekulativ ist. Um sie abzusichern, müsste ich "Grundlagenforschung" betreiben, wofür mir gerade etwas die Zeit fehlt.

Falls der MSTS auf einer konventionellen Festplatte installiert ist, hilft möglicherweise eine Defragmentierung mit Anordnung der Dateien nach Namen. O&O Defrag wäre hierzu in der Lage. Allerdings wäre dies auch nur eine recht schwache Medizin. Nachhaltig beseitigen kann man Nachladeruckler durch den Einsatz einer SSD.

Guten Abend @Gerhard , den Eintrag - Nofiltercab - in meinem Train exe Pfad benötige ich für das entfernen von einigen Nähten in der Führerstandsansicht. Da ich im Rahmen verschiedener BETA Test Aufgaben schnell einen Punkt aufsuchen möchte, ist es mir mit dieser Eintragung - timeacceleration- und der Strg- T Taste möglich die Aufgabe im Zeitraffer laufen zu lassen.

Persönlich, Gerhard bin ich auch weiter interessiert über das Thema " Prozessorentwicklung könnte MSTS noch mal beflügeln "mehr lesen zu können.

Gruß