Hardwarelastigkeit

[suppentrulli]

Ich baue derzeit ein etwas grösseres Fantasie-Netz. Dazu nutze ich bahn version 3.85r3. Die derzeitige Grösse des Netzes beträgt ca. 18,6 MB (MB nicht kB). Leider habe ich eine Geschwindigkeit auf höchster Stufe nicht von 20 sondern nur etwa von 3 bei einer CPU-Frequenz von 2,2 GHz. Das Netz soll bei vollständigem Abschluss eine Grösse von mind. 25,0 MB besitzen und dürfte dann stehenbleiben bzw. eine Geschwindigkeit von 0,2 bei 20 erreichen. Daher möchte ich fragen, ob es möglich ist die Hardwarelastigkeit des Programms zu reduzieren oder eine höhere Geschwindigkeit (anstatt 20 vielleicht 40 oder 60) zuzulassen. Vielleicht wäre es schon in version 3.86 umsetzbar.

[micha88]

Ich baue derzeit ein etwas grösseres Fantasie-Netz. Dazu nutze ich bahn version 3.85r3. Die derzeitige Grösse des Netzes beträgt ca. 18,6 MB (MB nicht kB). Leider habe ich eine Geschwindigkeit auf höchster Stufe nicht von 20 sondern nur etwa von 3 bei einer CPU-Frequenz von 2,2 GHz. Das Netz soll bei vollständigem Abschluss eine Grösse von mind. 25,0 MB besitzen und dürfte dann stehenbleiben bzw. eine Geschwindigkeit von 0,2 bei 20 erreichen.

Die Netzgröße an sich ist nicht das Problem, vor allem ist das die Zuganzahl. Aber die dürfte ja mit der Netzgröße auch steigen.

Aber ein Tipp dazu: Züge, die sich länger im Zustand "blockiert" (B) befinden, erzeugen besonders viel Rechenaufwand. Also alle Züge, die hinter einem anderen Zug stehen oder an einem Signal stehen. Freiabstellanlagen, bei denen viele Züge hintereinander warten sind diesbezüglich also sehr ungünstig.

Daher möchte ich fragen, ob es möglich ist die Hardwarelastigkeit des Programms zu reduzieren oder eine höhere Geschwindigkeit (anstatt 20 vielleicht 40 oder 60) zuzulassen. Vielleicht wäre es schon in version 3.86 umsetzbar.

Höhere Geschwindigkeiten als 20 gehen nicht. Bei den Geschwindigkeiten 1-19 bremst BAHN die Simulation unterschiedlich stark ab, bei Geschwindigkeit 20 läuft die Simulation einfach so schnell wie möglich. Die "Hardwarelastigkeit" lässt sich wohl kaum reduzieren. Viele Züge erfordern einfach viel Rechenaufwand.

Du kannst die Simulation etwas beschleunigen: In dem Buchstabenfeld rechts oben kannst du auf A klicken, und damit die animierten Grafiken abschalten (Rauchende Schornsteine, blinkende Bahnübergänge etc.). Mit einem Klick auf Z kannst du alle bewegte Grafiken abschalten - d.h., die Simulation läuft noch, aber die anzeige wird nicht mehr aktualisiert. Das ist praktisch, wenn man das Netz eine Weile laufen lässt, um zu testen, ob alles funktioniert.

[suppentrulli]

vielen dank für die antwort. schade das da nix zu machen geht, da die "lahmheit" der simulation bei mir eindeutig bei der anzahl der fahrzeuge (ca. 10.300 und steigend) liegt.

[Fuerst]

Dein Computer dürfte mit 2,2 GHz auch mittlerweile 6-7 Jahre auf dem Buckel haben. Auch die Hauptspeicheranforderung ist bei Netzen dieser Größe doch recht hoch. Hab ich auf meinem alten Athlon K6 (hatte glaub ich auch so knapp über 2 GHz) ziemlich gemerkt. Auf meinem neuen Rechner sind jetzt auch mehrere 1000 Züge kein Problem mehr.

[Jan Bochmann]

Guten Tag,

Ich baue derzeit ein etwas grösseres Fantasie-Netz. Dazu nutze ich bahn version 3.85r3. Die derzeitige Grösse des Netzes beträgt ca. 18,6 MB (MB nicht kB). Leider habe ich eine Geschwindigkeit auf höchster Stufe nicht von 20 sondern nur etwa von 3 bei einer CPU-Frequenz von 2,2 GHz. Das Netz soll bei vollständigem Abschluss eine Grösse von mind. 25,0 MB besitzen und dürfte dann stehenbleiben bzw. eine Geschwindigkeit von 0,2 bei 20 erreichen. Daher möchte ich fragen, ob es möglich ist die Hardwarelastigkeit des Programms zu reduzieren...

Wie soll das gehen? Das ist in etwa das selbe, als wenn Du zu Siemens gehst und sagst: "Ich hätte gern einen ICE-3, der 600km/h schafft, aber mit einem kleineren und schwächeren Motor als der DB 403."

oder eine höhere Geschwindigkeit (anstatt 20 vielleicht 40 oder 60) zuzulassen.

Bei 20 läuft die Simulation ungebremst. Eine Änderung der Zahlen ist völlig wirkungslos, denn das ändert nur die Skala. Stell Dir vor, Du hast ein Fahrzeug mit einem Tachometer, der von 0 bis 100km/h anzeigt, und Dein Fahrzeug schafft 90. Nun ist Dir das zu langsam. Also nimmst Du einen Edding-Stift und malst noch eine 0 hinter alle Zahlen auf dem Tacho. Nun geht die Anzeige von 0 bis 1000, und Dein Fahrzeug schafft 900. Es ist aber nicht wirklich schneller geworden, und das ist auch kein Wunder, denn es ist die selbe Technik geblieben.

MfG
Jan B.

[suppentrulli]

vielleicht sollte ich mich entschuldigen, da hier offensichtlich konstruktive kritik und anfragen zu problemlösungen unerwünscht sind. bei den beiden letzten beiträgen komme ich mir vor, als hätte ich zwei viertklässlern das butterbrot geklaut !!!
@fuerst : erzähle es keinem weiter, mein rechner ist ca. 2,5 jahre alt und athlon-prozessoren nutze ich auch nicht, da diese intel immernoch unterlegen sind.
@jan bochmann : auch auf einem rechner mit intel quad 4 (mit 3,0 Ghz) läuft das netz nicht schneller. also bitte: ich erwarte eine intelligente antwort und keine beleidigungen.
ich kann mich also nur noch einmal bei micha88 bedanken.

[jf007]

Mal ganz von vorne: Bekannt sein dürfte, dass BAHN kaum von Dual- oder Quad-Cores profitiert. Dass es keine Lösung ist, den Faktor einfach auf 40 oder 60 zu drehen, hat Jan Bochmann ja auch beschrieben.

Was willst du dann eigentlich? Die Aussage, dass das Netz eben nicht schneller läuft, als es läuft, scheint dich nicht zu befriedigen. Die Aussage, dass du mit weniger Leistung auch nicht mehr Züge fahren können wirst, auch nicht. Also stellt sich - erneut - die Frage: Was ist denn dein Anliegen?

Beleidigt hat dich übrigens niemand - oder du bist sehr leicht beleidigt.

Und nur so als Hinweis: Wer über Groß- und Kleinschreibung und eines gewisses Maß an Sozialverhalten verfügt, darf dann auch zu Recht eine intelligente Antwort erwarten; ansonsten wäre es vielleicht adäquat, erst einmal eigene Verhaltensweisen zu überdenken.

In diesem Sinne

Trotzdem Viele Grüße

Johannes

[Olli_K]

suppentrulli, wenn du intelligente Antworten anmahnst stellst du implizit fest, dass die vorher gegebenen Antworten nicht „intelligent“ waren, man könnte auch sagen dumm. Dies wiederum finde ich von dir wenig intelligent.

Bahn ist als Programm ein tolles Beispiel für objektorientierte Programmierung.
Wie weiter oben bereits erwähnt, wäre es vielleicht erst günstig das eigene Netz zu optimieren, bevor am Programm Optimierungen angemahnt werden.

[Han_Solo1981]

Moin,

bei mir läuft Bahn auf auf ner recht alten "Suppenschüssel", AMD Athlon 1800+, Arbeitsspeicher liegt gerade mal bei 768 MB .
Selbst die Grafikkarte ist noch ne gute alte Geforce 2 mit 64 MB ^^.

Das Programm läuft auch auf dieser "Alten Kiste" ohne Probleme. Bei etwas größeren Netzen wie z.B den Wandernetzen braucht es etwas länger zum laden, was aber nicht weiter schlimm ist. Diese Netze laufen auch ohne Probleme wenn sie geladen sind.
Das Bahn selbst noch auch solchen alten Rechnern läuft ist ne sehr gute Sache.
Ich denke mal wenn Bahn zu Hardwarelastig ist, würde mein Rechner öfter still stehen, was aber selbst bei etlichen anderen Programmen im Hintergrund nicht der Fall ist.

Gruß

Mark

[Rolf R]

Hallo Zusammen,

ich habe gerade mit Interesse verfolgt, wohin Diskussionen führen, wenn bestimmte Aussagen falsch verstanden bzw. gedeutet werden.
Mein Vorschlag: Ruhe bewahren.
Ich habe übrigens - wie einige Vorredner auch - keine beleidigenden Äußerungen gelesen.

Zum Thema Darstellung, mit dem Fürst hier angetreten ist, hab' ich auch keinen konkreten Lösungsvorschlag. Zum Einen bin kein Programmierer und zum Anderen könnte ich selbst dann aus einem Zebra kein Krokodil machen, wenn ich Programmierer wäre.

Vielleicht geht kann man die Simulationsgeschwindigkeit durch ändern der Bremsfaktoren erhöhen. Ich habe eine Diskussion aus dem Jahre 2008 gefunden:
http://www.das-bahn-forum.de/bahnforum/ ... 55&p=47299

Vielleicht hilft es ja etwas.

Gruß
Rolf

Übrigens: Sollten die Anforderungen von BAHN an die Hardware steigen, müsste ich auch passen, da dann mein Rechner dann in die Tonne müsste. Deshalb bin ich mit der jetzigen Version eigentlich sehr zufrieden.

[suppentrulli]

na endlich. leute mit denen man diskutieren kann! also folgendes das "fanta-netz" hat folgende anforderungen. es gibt 39 öpnv-betriebe (davon derzeit 25 aktiv), dazu 5 eisenbahn-gesellschaften (davon 2 derzeit mit ca. 40 Linien aktiv) dazu kommen noch 7 autobahnen. daher die hohe anzahl von fahrzeugen (ca.10750 derzeit), welche alle unterwegs sind (wirklich alle). wie sähe denn eine autobahn aus auf der ca. 2 fahrzeuge pro stunde an ein und demselben punkt vorbeiziehen. da ich selbst kein programmierer bin, die abläufe in meinem pc aber zu ca. 80% verstehe, machte mich die antwort von han_solo1981 etwas stutzig. ich erreiche zwar immernoch nicht die geschwindigkeit von 6000 fahrzeugen, habe ein teilproblem aber gefunden: BAHN kommunzierte und interagierte mit vier weiteren programmen (hauptsächlich security-bereich). nach umstellung der progamme wurde BAHN merklich schneller, da die cpu-auslastung (vorher 87 %, jetzt ca. 50%) abnahm. ich hatte also nur jemanden gesucht, dem ähnliches widerfahren ist und der mir berichten kann, was ich ändern kann bzw. muss. Übrigens schätze ich herrn jan bochmann sehr, da er als entwickler von BAHN mir mit diesem Programm aus der seele spricht.

[micha88]

habe ein teilproblem aber gefunden: BAHN kommunzierte und interagierte mit vier weiteren programmen (hauptsächlich security-bereich). nach umstellung der progamme wurde BAHN merklich schneller, da die cpu-auslastung (vorher 87 %, jetzt ca. 50%) abnahm.

Interessant, dass das so deutliche Auswirkungen hat. Ich hätte bisher gedacht, das lediglich Antiviren-Programme beim Öffnen und Speichern von Dateien den PC merkbar ausbremsen. BAHN "kommuniziert" aber nicht mit diesen Programmen, diese klinken sich vielmehr ungefragt in andere Programme/Treiber ein, um Dateizugriffe, Netzwerkzugriffe etc. zu überwachen/zu blockieren.

[Christopher Spies]

Hallo allerseits!

Längerfristig wäre es eine Möglichkeit, den Simulationskern von BAHN konsequent auf ereignisdiskrete Simulation umzubauen. Darüber habe ich mit Jan Bochmann schon einmal gesprochen.

Damit wäre beispielsweise zeitverzögertes Zurückschalten von Signalanlagen, wie neulich hier im Forum gewünscht, kein Problem, und Züge im Zustand "blockiert" würden keine Rechenzeit mehr verschlingen, weil nicht permanent geprüft werden müsste, ob der Folgeabschnitt frei geworden ist, sondern der Zug per Ereignis über die Fahrtstellung des vor ihm liegenden Signals oder die Weiterfahrt des vor ihm stehenden Zuges informiert werden würde.
Außerdem ist ereignisdiskrete Simulation ein Thema, welches in den letzten Jahrzehnten gründlich erforscht wurde und immer noch wird. Somit sind die entsprechenden Algorithmen hochgradig optimiert, was die Simulationsgeschwindigkeit erhöht bzw. die benötigte Rechenleistung vermindert. Es existieren auch verschiedene Verfahren zur verteilten Simulationen auf mehreren Rechnern oder mehreren Prozessorkernen innerhalb eines Rechners.

Dass diese Idee nicht ganz neu ist, zeigt die Dissertation von Dr.-Ing. Hans Schlenker mit dem Titel "Verteilte Constraint-basierte Eisenbahn-Simulation" (TU Berlin, 2004).

Gruß
- Christopher

[Indi]

Hallo zusammen

Ich hab hier grad folgenden Satz gelesen:

[...]
Züge, die sich länger im Zustand "blockiert" (B) befinden, erzeugen besonders viel Rechenaufwand. Also alle Züge, die hinter einem anderen Zug stehen oder an einem Signal stehen.
[...]

nun hab ich dazu eine Frage.
Ich verwende in meinem Netz meistens Haltestellen mit zeitgesteuerten Signalanlagen anstelle von Taktpunkten. Dies damit verspätete Züge die nur ein paar Sekunden vor der geplanten Abfahrtszeit ankommen trotzdem eine normale Haltezeit haben.
Wenn ich nun den oben zitierten Satz lese, kann ich mir vorstellen, dass ich so viel Rechenkapazität verbrauche. Gibt es vielleicht eine andere Möglichkeit eine "normale" Haltezeit zu erreichen ohne dass der Zug zu früh abfahren kann?

Grüsse
Indi

[Jan Bochmann]

Guten Tag,

Hallo zusammen

Ich hab hier grad folgenden Satz gelesen:

[...]
Züge, die sich länger im Zustand "blockiert" (B) befinden, erzeugen besonders viel Rechenaufwand. Also alle Züge, die hinter einem anderen Zug stehen oder an einem Signal stehen.
[...]

Dieser Effekt wurde schon vor Jahren gemindert, d.h. es ist bei neueren BAHN-Versionen nicht mehr so gravierend.

nun hab ich dazu eine Frage.
Ich verwende in meinem Netz meistens Haltestellen mit zeitgesteuerten Signalanlagen anstelle von Taktpunkten. Dies damit verspätete Züge die nur ein paar Sekunden vor der geplanten Abfahrtszeit ankommen trotzdem eine normale Haltezeit haben.
Wenn ich nun den oben zitierten Satz lese, kann ich mir vorstellen, dass ich so viel Rechenkapazität verbrauche. Gibt es vielleicht eine andere Möglichkeit eine "normale" Haltezeit zu erreichen ohne dass der Zug zu früh abfahren kann?

Grüsse
Indi

Z.Zt. gibt es keine solche Möglichkeit. Es ist aber eine Option für Taktpunkte in Vorbereitung, womit in diesem Fall der Aufenthalt auf einen normalen Halt verlängert werden kann.

Beispiel: Planabfahrt 10:00:00, Hst.-Intervall des Zugs 20-30s, d.h. Wartezeit im Durchschnitt 25s.

Ankunft sei nun um 9:59:55. Bisher erfolgt die Abfahrt in dieser Situation schon um 10:00:00, d.h. bereits nach 5s.

Mit der neuen Option wird das auf einen normalen Aufenthalt verlängert, d.h. bis 10:00:00 wird am Taktpunkt gewartet und dann noch (20..30)-5s zusätzlich gewartet wie an einer Haltestelle.

Grüße
Jan B.