Neues Plugin: STS Analyse

[duncyo]

So langsam komme ich der Sache näher.

Ich benötige folgende Infos von denjenigen, die das Problem [Performanceeinbruch des STS nach langer Spielzeit mit vielen Zügen] noch haben:

• Installierte Java-Versionen (alle!)
• Betriebsssystem + 64 Bit oder 32 Bit
• Browser version:
  1. Firefox: Adresse about:support, dort die Infos Name, Version und User Agent
  2. Internet Explorer: nur die Info unter Hilfe(Fragezeichen)->Info
  3. Opera: 64-Bit oder 32 Bit?
• Prozesse: java.exe / javaw.exe (während der STS ausgeführt wird und das Plugin offen ist! - laufen beide mit 64 Bit? beide mit 32 Bit? unterschiedlich?

Diese Infos sind extrem wichtig für mich und ich sage noch nicht was ich herausgefunden habe. Warte auf Infos

Gruß
duncyo

[js]

Ich gebe hier mal zu bedenken, dass in der Regel das Java im Browser 32 Bit ist, da der Browser auch meist 32 Bit ist. Eine Mischung (64 Bit Java 32 Bit Browser oder umgekehrt) klappt nicht.

Da Plugin und Sim via TCP miteinander reden, sollte die Art beim Plugin egal sein - ich sag mal sollte, denn man weiß ja nie was so ein Windows damit macht.

Unabhängig von der Bit-Zahl laufen Sim und Plugin aber in völlig getrennten JVMs, ja sogar völlig verschiedenen Prozessen. Ein Plugin hat jedoch durchaus etliche Möglichkeiten, den Sim ans Ende seiner Kräfte zu führen:

- sehr schnelle und häufige Abfragen (wir reden hier aber von Sekunden bzw. Sekundenbruchteilen)
- Plugin verbraucht den Speicher des Systems (dann dürften aber auch andere Programme Sorgen bekommen)
- denkbar, dass das Event-System für Zugbewegungen noch Fehler enthält (wobei zu beachten ist, dass jeder Zug nur 1x dort pro Event-Art registriert werden darf, jede weitere Registrierung wird ebenfalls angenommen und führt dann zu mehrfachen Meldungen, was dann schnell zum 1. Punkt führen könnte), die Event-Schnittstelle wurde auch noch nie im großen Stil mit vielen Zügen genutzt sondern immer nur mit wenigen, denkbar, dass da auch noch Problemfälle drin sind.

[duncyo]

Ich gebe hier mal zu bedenken, dass in der Regel das Java im Browser 32 Bit ist, da der Browser auch meist 32 Bit ist. Eine Mischung (64 Bit Java 32 Bit Browser oder umgekehrt) klappt nicht.

Das ist natürlich richtig. Und das hier ergaben meine Tests bisher:

• 32-Bit-Browser (und natürlich 32 Bit Java), Plugin mit der 32-Bit Java VM (keine Probleme)
• 64-Bit-Browser (und 64 Bit Java), Plugin mit 64-Bit Java (keine Probleme)
• 32-Bit-Browser (und 32 Bit Java), Plugin mit 64-Bit Java (ergibt die aktuellen Performanceprobleme nach einiger Zeit)

Und ich habe deinen Beitrag nicht missverstanden: Ich weiss, dass Du nur Browser und Java-Version im Browser meinst.
Ich teste noch weiter - mal sehen was da noch so kommt.

Unabhängig von der Bit-Zahl laufen Sim und Plugin aber in völlig getrennten JVMs, ja sogar völlig verschiedenen Prozessen. Ein Plugin hat jedoch durchaus etliche Möglichkeiten, den Sim ans Ende seiner Kräfte zu führen:
- sehr schnelle und häufige Abfragen (wir reden hier aber von Sekunden bzw. Sekundenbruchteilen)
- Plugin verbraucht den Speicher des Systems (dann dürften aber auch andere Programme Sorgen bekommen)

Das ist ja, was mich ganz wild macht Wenn diese extremen Performanceprobleme auftreten, wird im Sim Antialiasing automatisch ausgeschaltet und die Maus hakt im Sim im Sekundentakt (also friert ein, 0.5-1 Sek. später Mouse-Refresh). Wenn ich das/die Plugin/Schnittstelle alle 30 Sekunden aktualisieren lasse, ergibt dies den selben Effekt dieser Performanceprobleme - und diese sind auch gegen meine Erwartungen auch nicht vorbei, wenn man das Plugin (und alle aktiven Java-Prozesse) schließt. Der Sim hat diese "Krankheit" danach weiter!

- denkbar, dass das Event-System für Zugbewegungen noch Fehler enthält (wobei zu beachten ist, dass jeder Zug nur 1x dort pro Event-Art registriert werden darf, jede weitere Registrierung wird ebenfalls angenommen und führt dann zu mehrfachen Meldungen, was dann schnell zum 1. Punkt führen könnte), die Event-Schnittstelle wurde auch noch nie im großen Stil mit vielen Zügen genutzt sondern immer nur mit wenigen, denkbar, dass da auch noch Problemfälle drin sind.

Ich registriere die Events je Zug 1x und bekomme diese auch jeweils einmal. Einzige Ausnahme: Wenn ein Zug noch kein grünes Signal in einem Bahnhof hat, aber abfahren soll. Dann gibt es eine Eventflut. Das habe ich schon am Anfang eines Stellwerks mit mehreren Zügen probiert - das beeinträchtigt schnittstellenseitig scheinbar nichts. Von meinem Plugin her wird der Event nur beim ersten mal beachtet.

[edit: ich mache später noch einen Test ohne jegliche Events - das sollte vom Plugin (abgesehen vom Wecker, der damit ausschließlich arbeitet) genauso gemeistert werden]

[FDLRenningen]

Könnte es vielleicht daran liegen, dass die meisten einen 32bit browers verwenden (--> der sim auch mit 32bit java gestartet wird) das plugin durch den doppelklick allerdings als 64bit ausgeführt wird?

[duncyo]

Könnte es vielleicht daran liegen, dass die meisten einen 32bit browers verwenden (--> der sim auch mit 32bit java gestartet wird) das plugin durch den doppelklick allerdings als 64bit ausgeführt wird?

das meine ich damit ja .. bin mit den tests noch nicht durch

[Barrett]

Ich teste das ganze gleich mal auf Firefox 64 bit, Java 64 bit und Windows 64 bit...

[js]

Ich teste das ganze gleich mal auf Firefox 64 bit, Java 64 bit und Windows 64 bit...

Na das dürfte aber keine wirkliche Referenz sein, eine Firefox Alpha ist schon gewagt und könnte der Ergebnis sehr verzerren.

[duncyo]

Ich habs auch mit der Alpha probiert - aber halt nur aus Interesse und kein absolutes Verständnis für das Problem habe, da es eigentlich keins geben dürfte oO

Alle Tests wurden im Stellwerk Danmark Øst/Østerport durchgeführt, welches von der Zugdichte sehr schnell dieses Problem erzeugt.

1. Firefox 12 Nightly 64-Bit (STS Java 64) + Plugin in Java 6.31 64-Bit: alles ok (nach 90 Minuten weiterhin absolut flüssig)
2. Firefox 12 (und 11) Standard 32-Bit (STS Java 32) + Plugin in Java 6.31 32-Bit: alles ok (nach 90 Minuten weiterhin absolut flüssig)
3. Internet Explorer 32-Bit (STS Java 32) + Plugin in Java 6.31 32-Bit: alles ok (nach 90 Minuten weiterhin absolut flüssig)
4. Firefox 12 (und 11) Standard 32-Bit (STS Java 32) + Plugin in Java 6.31 64-Bit = Problem ~45-70 Min.
5. Firefox 12 Standard 32-Bit (STS Java 32) + Plugin in Java 7.03 64-Bit = Problem nach ~45-70 Min.
6. Firefox 12 Nightly 64-Bit (STS Java 64) + Plugin in Java 6.31 32-Bit = Problem nach ~45-70 Min.

Ergo tritt das Problem nur auf, wenn die Java-Version des Browsers (abhängig von der Browser Version) von der Java-Version des Systems abweicht.
Das sind die Ergebnisse aus meinen Tests heute und gestern - warum das so ist? Keine Ahnung.

Ich bin für heute durch mit dem Lack. Bis morgen - dann gibt's vielleicht mehr Erkenntnis.

Gruß
duncyo

[Barrett]

eine Firefox Alpha ist schon gewagt und könnte der Ergebnis sehr verzerren.

gewagt oder nicht, es läuft super mit der Kombi!
2:30 volle Action in Ruhleben/Spandau und keine Probleme gehabt! teilweise 17 Züge Zeitgleich im Stellbereich und das völlig problemlos

Dank des Plugins konnte ich trotz 2 kaputter Weichen im Hauptgleis und 4 Signalstörungen (gleichzeitig) die Verspätungen gut erkennen, und die Züge so disponieren, dass sich noch was retten lies. Ohne Plugin hätte ich garnicht die Übersicht dafür gehabt.

warum das so ist? Keine Ahnung.

Na weils halt Java ist

MfG

[duncyo]

Ich bin froh, dass nicht nur ich zu dem Ergebnis gekommen bin. Ich hoffe noch auf Meldungen anderer Spieler und werde mir dann etwas überlegen.

Gruß
duncyo

[DevonFrosch]

Moin,

evtl. hat auch Java ein Problem damit, sowohl mit 32 als auch 64 Bit parallel zu laufen, und haut sich irgentwann um gemeinsame Ressourcen (würde mich jedenfalls nicht wundern...). Ich werde jedenfalls demnächst auch nochmal testen, jetzt aber nicht mehr

Wer sich fragt: Wie kann ich mich unter Win7 64bit denn entscheiden, welche Java-Version ich nehme?

Code: Alles auswählen

Java 64bit:
"C:\Program Files\Java\jre6\bin\javaw.exe" -jar "C:\...\AnalysePlugin.jar"

Java 32bit:
"C:\Program Files (x86)\Java\jre6\bin\javaw.exe" -jar "C:\...\AnalysePlugin.jar"

Das "C:\...\AnalysePlugin.jar" muss natürlich an den jeweiligen Pfad angepasst werden. Wichtig sind die Anführungszeichen, solange der Pfad Leerzeichen enthält, sie schaden aber nicht.

Die jeweilige Zeile kann entweder in eine Verknüpfung oder in eine .cmd-Datei geschrieben werden. Befindet sich die cmd-Datei im selben Verzeichnis wie die jar-Datei, kann der Pfad auch weggelassen werden (Hinweis an unseren Programmierer ). Theoretisch kann man den Befehl auch jedes Mal in der Eingabeaufforderung eintippen, ich rate jedoch davon ab

Falls es noch eine einfachere Möglichkeit gibt, her damit, ich lerne gerne dazu

Gruß,
DevonFrosch

[js]

Jeder, der das Problem hat, soll sich doch mal den Process-Explorer von Sysinternals installieren und dann die beiden betreffenden Java-Prozesse (das eine ist ein Child vom Browser, das andere müsste das javaw sein) mal genauer ansehen:

Speichergröße
CPU-Last
I/O

Zu finden jeweils unter den Properties eines Prozesses. Am besten einfach mal mit laufen lassen, direkt von Anfang an. So müsste man ja sehen, wie sich diese Graphen mit der Zeit ändern. Vor allem, wie sie sich ändern: langsam stetig oder eher ein Sprung. Falls jemand Screenshots von den Fenstern machen will: 1x vom Anfang sagen wir 5 Minuten nach Start und ein 2. wenn das Problem auftritt.

[duncyo]

Da denk ich "komm - machst das einfach schnell mal" - Pustekuchen. Nach 2 Stunden und 30 Min immernoch alles flüssig (Murphys Gesetz lässt grüßen).
Getestet mit Firefox 12 / Java 3.31 32Bit und Plugin mit der 64 Bit VM, Stellwerk wie immer [Danmark Øst Østerport]

Die Werte haben sich bis 2:30 nicht großartig verändert.

java.exe vom STS / 32
Memory 360.000 KB +/- 50 MB (Anfangs knapp 320.000)
CPU: bei Normalzustand 8%, bei einem Pluginabfrage-Peak 15%
I/O: je Pluginabfrage-Peak Write ~500KB, gesamt nach 2:30 1,5 GB Write, fast kein Read (nur am Ende beim Stellwerk-Vollaufen-Lassen viel Read (1,7 GB) wegen dem Lokführer-BimmelSound in Massen)

javaw.exe vom Plugin / 64
Memory: 230.000 KB +/- 20 MB
CPU: bei Normalzustand 1%, bei einem Pluginabfrage-Peak 5%
I/O: nicht relevant (gesamt 14 MB Read, fast kein Write)

Da Bild zu groß als URL: Screenshot

Am Ende habe ich noch 15 Minuten lang das Stellwerk voll-laufen lassen, um die Eventflut zu starten - dabei ist jeder Bahnhof permanent am Event "Abfahrt" melden gewesen und trotzdem ist nichts dramatisches passiert oO

Nun bin ich noch ratloser - das Problem scheint nicht jedes mal aufzutreten - weshalb meine vorherigen Testergebnisse evtl. nichts aussagen.

Ich werde im Laufe des Tages noch die Datumsänderung als Update online stellen - die Info bekommt ihr aber auch über das Plugin. Also nichts großartiges, da ich eh nur mit dem Performancekram zugange bin

Gruß
duncyo

[Latte]

Hallo zusammen,

Ich habe ca. 4.5 Std Std. Braunschweig ohne Performance-Probleme gespielt. Allerdings unter Linux mit Firefox und Java-Plugin, während für das Plugin OpenJDK (64bit) genutzt wurde.

Der Systemmonitor spuckt folgende Details aus:
Das Java-Plugin vom Firefox:

Code: Alles auswählen

1024 KB	/usr/lib/jvm/java-1.6.0-sun-1.6.0.26/jre/lib/amd64/server/libjvm.so
448 KB	/usr/lib/jvm/java-1.6.0-sun-1.6.0.26/jre/lib/amd64/libawt.so
300 KB	/usr/lib/jvm/java-1.6.0-sun-1.6.0.26/jre/lib/amd64/libfontmanager.so
192 KB	/usr/lib/jvm/java-1.6.0-sun-1.6.0.26/jre/lib/amd64/xawt/libmawt.so

Das aufgerufene Plugin in der Konsole:

Code: Alles auswählen

7188 KB	/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
1600 KB	/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
424 KB	/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libawt.so
180 KB	/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/xawt/libmawt.so

Keine Ahnung, ob diese Infos über die "exotische" Kombination weiterhilft...?

Viele Grüße,
Marc

[duncyo]

Dank Dir für die Infos - aber helfen tun diese (mir zumindest) nicht. Das Problem ist ja auch nicht aufgetaucht

Ich habe dazu auch noch nichts neues. Weder Meldungen von Spielern zum Problem, noch eigene Testinfos (ich kann einfach nicht jeden Tag meine Zeit für stundenlange Tests einplanen).

Mal davon ab - Infos zu den nächsten Updates (Planung für nächste Woche, unter Vorbehalt)

Bestehende Plugin-Inhalte:

• Zugstatus: "Zug erwartet Kupplung" gibt es im Plugin noch nicht, das möchte ich noch einbauen
• Sortierung Zugliste: Die Liste "Alle im Stellwerk" ist aktuell unsortiert. Hier möchte ich euch mehrere Möglichkeiten geben, diese Liste zu sortieren.
• Sortierung Analyse: Ebenfalls Zuglistensortierung (die aktuell noch sehr unzuverlässig nach "hat Stellwerk verlassen um" sortiert ist)

Neue Plugin-Inhalte:

• Bahnhöfe/Haltestellen: In noch nicht festgelegter Form möchte ich Infos zu den Haltestellen anzeigen.
  Beispielsweise:
  • Bahnhof XY:
    Letzter Zughalt: RE 12000
    Aktueller Zughalt: RB 13000
    Vermutlich nächster Zughalt: ICE 123
  (und dies dann für alle Bahnhöfe auf einer/m Tafel / Registerkarte / neuen Fenster)
• Zugfilterung: Ich möchte einen von euch zu konfigurierenden (optionalen) Filter einbauen. In einigen Stellwerken interessieren einige Zugtypen nicht, weshalb diese die Informationsflut nur erweitern und daher ausgeblendet werden können

Niedrige Prio:

• Analyse: Fahrwege (wo wird am meisten Verspätung produziert?)

Diese Punkte werde ich je nach Lust/Laune programmieren. Genaue Zeitpunkte kann ich daher noch nicht nennen
Ihr habt weitere Ideen oder Probleme mit dem Plugin? Immer her damit!

Gruß
duncyo