Fehler bei hoher Geschwindigkeit

[Dierk Nüchtern]

Hallo zusammen,

ich mache hier mal ein Problem aus dem WN3 öffentlich.

Ich habe in meiner Stadt mein Busnetz neu geordnet und lasse die Busse an Taktpunkten abfahren und abends fahren sie mittels Datenwechsel von verschiedenen Punkten mit Fahrgastbeförderung oder als Dienstwagen (Linie D) in den Betriebshof. Ich habe das Netz auf Geschwindigkeit 5 bis 8 eine Woche laufen lassen. Es lief wunderbar.

Dazu muss ich sagen, dass ich auch einige Finessen eingebaut habe. Teilweise wechseln die Fahrzeuge die Linien oder Gelenkbusse fahren ein und Standardbusse fahren aus usw. Zudem fahren die Busse im Hof je nach Kursnummer auf bestimmte Stränge in den Hallen. So kann ich zum Beispiel steuern, dass ein Bus, der morgens einfährt, am Nachmittag von einem bestimmten Taktpunkt wieder neu ausfährt. Dieses System spart natürlich - wie in der Realität -einige Fahrzeuge.

Bei einigen Mitbauern kamen nun aber diverse Fehler. Busse fuhren nicht ein oder wechselten nicht usw. Im letzten und schlimmsten Chaos stand das Netz auf Geschwindigkeit 18.

Teilweise war es so, dass das Netz kam und Busse standen nachts an den Endstellen, Fahrten sind ausgefallen usw. Dann hab ich alles korrigiert und das Netz auf moderater Geschwindigkeit laufen lassen und es lief alles reibungslos.

Mein Fazit: Die hohen Laufgeschwindigkeiten verursachen diese willkürlichen Fehler.

Hat sonst jemand ähnliche Erfahrungen dieser Art gemacht?

[DerPhysiker]

Hallo Dierk,

das Problem tritt bei meinem großen Netz auch auf (Bahn 4.00).
Ich ging (und gehe) bisher davon aus, dass ab einem bestimmten Punkt mein Rechner einfach nicht mehr mithalten kann und dann pro Bahn-Zeiteinheit es nicht mehr schafft, alle Aufgaben abzuarbeiten. Ich habe bei mir auch festgestellt, dass es umso schlimmer wird, je mehr Fahrzeuge an Taktpunkten stehen oder blockiert sind - was ja hier auch mal vor einigen Jahren von Jan B. als rechenintensiv bestätigt wurde.

Hier mal zur Einordnung die Statusinformationen:

Netz: Spiel400b4test.nt3
zuletzt gespeichert: 05.06.2017 02:58:44
Datenformat: 3954
Überschrift:
Meine kleine Welt
Laufzeit des Netzes (d h:min): 1148 08:14

Infotexte vorhanden 16465 Zeichen in 121 Stück
Weichen vorhanden 53851 Stück
Rangierpunkte vorhanden 667 Stück
Taktpunkte vorhanden 2918 Stück
Datenwechsel vorhanden 1048 Stück
Signalanlagen: 5290 Anlagen/ 9722 Elemente
Fahrstraßen vorhanden 0 Stück
Haltestellen vorhanden 8023 Stück
Langsamfahrstrecken vorhanden 9567 Zeichen
Depots vorhanden 108 Gleis[e] in 108 Stück
Text vorhanden 7910 Stück
Textformate vorhanden 1 Stück
Linien noch frei 88% = 4429 Stück
Fahrziele vorhanden 27 Stück
Log-Punkte vorhanden 24 Stück
Wendepunkte/Streckenenden vorhanden 2779 Stück
Pfeif-/Läutetafeln (Soundpunkte) vh. 0 Stück

Züge insgesamt: 1882

im STOP-Zustand: 45
im Depot (ohne STOP): 109
im Kuppelzustand: 59
wartend (rangieren): 4
an Haltestellen: 152
an Taktpunkten: 674
bei der Abfahrt: 0
blockiert (wartend): 349
in Fahrt: 490
unterwegs inkl. wartend + blockiert: 1669

Ausdehnung des aktuellen Netzes:

minX = 0 maxX = 49216 Elemente: 49217
minY = 0 maxY = 41368 Elemente: 41369
minZ = -3 maxZ = +0 Ebenen: 4

Maßstab 80 Elemente/km

»» West-Ost = 615.212 km Nord-Süd = 517.112 km

Interne Betriebssystem-Version:
Win 7
6.1 Service Pack 1

Hauptspeicher (phys.): 4194303 KB ( 4095 MB)
Freier Hauptspeicher: 4194303 KB ( 4095 MB)
Virtueller Speicher: 2097024 KB ( 2047 MB)
Freier virtueller Speicher: 1071920 KB ( 1046 MB)
Genutzter Speicher: 23%
Anzahl Blöcke: 333136
Gesamtlänge [Byte]: 918105795 ( 875 MB)

für Netz reserviert: 260250 KB (130125 Quadrant[en])
(1 Quadrant = 32 × 32 Elemente in 1 Ebene)

Grafik: 32 Bit per Pixel (bpp), Monitore: 1
Auflösung (Pixel): Breite × Höhe 1920 × 1080

geladene Sprachdateien:
Programmtexte: "bahn.lng"
Fahrzeugtexte: "bahn.lnv"
Hilfedatei: "bahn.chm"

Installiert am 08.06.2017 (Tage: 0)
Nutzungszeit aktuelle Sitzung (d h:min): 0 00:00
Nutzungszeit gesamt (d h:min): 0 00:00

[Dierk Nüchtern]

Hier sind mal die Daten aus dem WN3:

Code: Alles auswählen

Netz: wn3-regio.nt3
zuletzt gespeichert: 09.06.2017 16:27:24
Datenformat: 3882
Überschrift:
WanderNetz3 - Regio
Laufzeit des Netzes (d h:min): 3269 09:49
 
Infotexte vorhanden  113342 Zeichen in   936 Stück
Weichen vorhanden                      73795 Stück
Rangierpunkte vorhanden                 6779 Stück
Taktpunkte vorhanden                    6071 Stück
Datenwechsel vorhanden                  3656 Stück
Signalanlagen:        7712 Anlagen/ 29102 Elemente
Fahrstraßen vorhanden                    284 Stück
Haltestellen vorhanden                 25882 Stück
Langsamfahrstrecken vorhanden        44576 Zeichen
Depots vorhanden       653 Gleis[e] in   479 Stück
Texte vorhanden                        21326 Stück
Textformate vorhanden                     81 Stück
Linien noch frei                 56% =  2813 Stück
Fahrziele vorhanden                      168 Stück
Log-Punkte vorhanden                     103 Stück
Prellböcke/Streckenenden vorhanden      8782 Stück
Pfeif-/Läutetafeln (Soundpunkte) vh.      50 Stück
 
Züge insgesamt:         4948 (Fahrzeuge: 26870)
 
 im STOP-Zustand:        281
 im Depot (ohne STOP):   434
 im Kuppelzustand:       604
 wartend (rangieren):     19
 an Haltestellen:        517
 an Taktpunkten:        1299
 bei der Abfahrt:          0
 blockiert (wartend):    148
 in Fahrt:              1646
 unterwegs inkl. wartend + blockiert: 3629
 
Ausdehnung des aktuellen Netzes:
 
 minX =    32   maxX = 32746   Elemente: 32715
 minY =  4582   maxY = 32755   Elemente: 28174
 minZ =    -4   maxZ =    +0   Ebenen:       5
 
 Maßstab 60 Elemente/km
 
»» West-Ost = 545.250 km    Nord-Süd = 469.566 km
 
Interne Betriebssystem-Version:
 Win 7
 6.1 Service Pack 1
 
Hauptspeicher (phys.):        2097151 KB ( 2047 MB)
Freier Hauptspeicher:         1679428 KB ( 1640 MB)
Virtueller Speicher:          2097024 KB ( 2047 MB)
Freier virtueller Speicher:   1639228 KB ( 1600 MB)
Genutzter Speicher:                46%
Anzahl Blöcke:                 365309
Gesamtlänge [Byte]:         376075129    (  358 MB)
 
für Netz reserviert: 110866 KB (55433 Quadrant[en])
 (1 Quadrant = 32 × 32 Elemente in 1 Ebene)
 
Grafik: 32 Bit per Pixel (bpp), Monitore: 1
 Auflösung (Pixel): Breite × Höhe  1920 × 1080
 
geladene Sprachdateien:
 Programmtexte: "bahn.lng"
 Fahrzeugtexte: "bahn.lnv"
 Hilfedatei: "bahn.chm"
 
Installiert am 03.11.2016 (Tage: 217)
Nutzungszeit aktuelle Sitzung (d h:min):   0 00:57
          Nutzungszeit gesamt (d h:min):  25 13:07
 

[Jan Bochmann]

Guten Tag,

Hallo zusammen,

ich mache hier mal ein Problem aus dem WN3 öffentlich...

Mein Fazit: Die hohen Laufgeschwindigkeiten verursachen diese willkürlichen Fehler.

Hat sonst jemand ähnliche Erfahrungen dieser Art gemacht?

Diese Idee ist nicht neu. Sie taucht immer mal wieder auf, seitdem es BAHN gibt, meistens im Zusammenhang mit der Geschwindigkeit 20 (Maximum).

Der Ablauf und die innere Logik einer Software und von deren Daten ist aber praktisch völlig unabhängig davon, wie schnell diese Software abgearbeitet wird. Ob schnell oder langsam, oder auch mal angehalten und fortgesetzt - die Reihenfolge der Schritte, die Abhängigkeiten und alle daraus folgenden Kausalitäten sind immer exakt gleich.

Das ist genau wie bei einer mechanischen Uhr: Auch wenn das Uhrwerk mal angehalten wird oder wenn es jemand bremst oder mit Gewalt schneller laufen läßt - oder gar rückwärts - es wird sich am Verhältnis der beiden Zeiger absolut nichts ändern. Wenn der kleine Zeiger exakt auf einer Zahl steht, dann steht der große Zeiger auf der 12 - immer.

Ich habe das Netz auf Geschwindigkeit 5 bis 8 eine Woche laufen lassen. Es lief wunderbar.

Nehmen wir mal an, alle 7 Tage haben exakt den selben Fahrplan. Dann hast Du also 7 Versuche gemacht.

Dazu muss ich sagen, dass ich auch einige Finessen eingebaut habe...

Damit ist anzunehmen, daß bei einem Durchlauf von 7 Tagen nur ein sehr kleiner Teil der möglichen Abläufe überhaupt stattgefunden hat. Die anderen wurden vielleicht gar nicht getestet, man kann also nicht behaupten, sie würden fehlerfrei ablaufen.

Bei einigen Mitbauern kamen nun aber diverse Fehler. Busse fuhren nicht ein oder wechselten nicht usw. Im letzten und schlimmsten Chaos stand das Netz auf Geschwindigkeit 18.

Ist es da auch nur 7 Tage gelaufen? Wahrscheinlich wesentlich mehr, und genau darin liegt das "Problem".

In nahezu allen Netzen wird mit zufälligen Werten gearbeitet, z.B. bei den Aufenthaltszeiten an Haltestellen. In der Regel prüft niemand (ich auch nicht), wie sich ein Extremfall auswirken würde, d.h. daß ein Bus entweder an allen Haltestellen mit der Minimalzeit oder an allen mit der Maximalzeit abgefertigt wird. Dieser Fall ist natürlich auch extrem selten. Bei 7 Versuchen kommt er praktisch nicht vor. Bei 100 oder 1000 Versuchen kann er aber schon mal auftreten. Um so viele Versuche überhaupt durchführen zu können, muß das Programm mit einer höheren Geschwindigkeit laufen, denn soviel Zeit hätte man sonst nicht. Diese Geschwindigkeit ist aber nicht die Ursache, sondern einfach die größere Zahl der Versuche.

Dieser Extremfall erscheint nun etwas konstruiert. Es ist aber schon viel wahrscheinlicher, daß zwar nicht immer der Extremwert, aber zumindest Werte nahe daran erreicht werden. Außerdem können kleine Abweichungen manchmal zu sehr großen führen, z.B. wenn sich dadurch die Reihenfolge der Ankunft an einem Taktpunkt ändert oder eine Zugkreuzung auf eingleisiger Strecke an eine andere Stelle verlegt wird. Dann muß plötzlich ein Zug mehrere Minuten warten, der am anderen Tag pünktlich war.

Ich lasse Netze oft wochenlang (Siumlationszeit) durchlaufen - mit Geschwindigkeit 20. Jeder Tag mit eigenem Fahrplan muß da mehrmals dabei sein, das betrifft meistens Sa und So. Wenn dann am 4. Sonntag eine Störung auftritt, dann muß ich eben nach der Ursache suchen. Das ist leider mühselig, weil es sich nicht gezielt wiederholen läßt. Das Auswerten von Dispatcher-Nachrichten hilft manchmal. Man kann diese auch protokollieren lassen.
Ich kann aber nicht sagen, wenn ich das Netz langsamer laufen lasse, so daß es gar nicht bis zum 4. Sonntag kommt, dann läuft es störungsfrei. Ich weiß es nur einfach nicht.

Viele Grüße,
Jan B.

[Dierk Nüchtern]

Nun, die ersten Linien fahren schon länger als 7 Sim-Tage! Auffällig ist eben, dass gerade bei hohen Geschwindigkeiten diese Fehler auftreten.

Klar, ich verstehe deine Ausführungen, Jan! Aber dass die Probleme immer in bestimmten Kombinationen auftreten?!

[Jan Eisold]

Hallo,

vor ein paar Jahren gab es bereits die Beobachtung, dass bei einigen Nutzern mehr oder andere Fehler auftraten, wenn das Netz mit Geschwindigkeit 20 lief. Warum es bei Geschwindigkeit 20 irgendein anderes Verhalten von BAHN geben könnte, war aber auch damals nicht nachvollziehbar...

Aus meiner Sicht ist es wahrscheinlicher, dass durch zufällige Verspätungen manchmal auch größere Fehler entstehen, aber eben nicht systematisch und auch nicht unbedingt reproduzierbar. Dazu müsste man sich die Ursachen der Probleme anschauen und nicht nur die Symptome. Beispiel: Durch Verspätungen kommen Züge in anderer Reihenfolge an bestimmten Stellen an, dann passt der Umlauf vielleicht schon nicht mehr oder die Reihenfolge in der Abstellanlage bei nächsten Ausrücken. Oder die Gültigkeit von Taktpunkten mit Linienwechsel oder von Datenwechselpunkten ist gerade abgelaufen, etc. - da gibt es leider viele Möglichkeiten...

MfG Jan

[piefke53]

In der Technik gilt ein bitterböser Satz: Toleranzen addieren sich immer in der unerwünschten Richtung.

Und genau das dürfte auch das Problem bei diesen "Verschluckern" sein. Wenn an Haltestellen ein von/bis-Aufenthalt eingestellt ist, was ja realitätsnah ist, können sich dadurch auch an "auf durchschnittliche Bedingungen" eingestellten Signalanlagen und Taktpunkten aufsummierte Differenzen ergeben. Als nächste Folge dann ein Rückstau vor Depoteinfahrten und/oder Warteschleifen. Andererseits wäre es in der Simulation blödsinnig, weil unübersichtlich, jede dritte oder fünfte Haltestelle als Taktpunkt auszuführen. In der Realität hat man das durchaus, was ich jeden Tag auf meinem Bus sehe. Öfter liegen 2 Haltestellen auf einer Planzeit (in einem Extremfall sind diese über einen Kilometer auseinander), sodaß man die zweite automatisch mit einem "+" im RBL bedient .... und, oh Wunder, zwei Stationen weiter ist man auf einmal eine halbe Minute im "-".

[Dierk Nüchtern]

In der Realität hat man das durchaus, was ich jeden Tag auf meinem Bus sehe. Öfter liegen 2 Haltestellen auf einer Planzeit (in einem Extremfall sind diese über einen Kilometer auseinander), sodaß man die zweite automatisch mit einem "+" im RBL bedient .... und, oh Wunder, zwei Stationen weiter ist man auf einmal eine halbe Minute im "-".

Das haben wir zum Beispiel bei uns am Betriebshof. Man kann an der Haltestelle "Renninghausen" durchaus 1 Minute später abfahren (Abfahrt immer x:x4) und ist zwei Stationen in Brünninghausen trotzdem ne halbe bis eine Minute zu früh. Eine Haltestelle weiter am Rombergpark hat man planmäßig ne Standzeit. Sowas lässt sich in BAHN eben nicht realisieren.

Und trotzdem bleibt eine Frage: Warum treten diese Besonderheiten überweigend bei Geschwindigkeiten von 15 und höher auf?

[Seb144]

Hallo,

ich kann aus eigener Erfahrung nicht bestätigen, dass das Auftreten von Fehlern etwas mit der Geschwindigkeit zu tun hätte.
Klar bekommt man bei 20 unterm Strich mehr Ereignisse, das liegt dann aber daran, dass die Simulationstage auch häufiger durchlaufen.
Ich mach es so: Autospeichern jede (Simulations-)Stunde, dann volle Geschwindigkeit und wenn es nennenswerte Fehler gibt, mit einem alten Stand nach der Ursache forschen. Der Fehler - i.d.R. ist er bei einer recht kurz vorher gespeicherten Netzversion reproduzierbar - tritt dann auch bei geringer Geschwindigkeit auf.
Meistens ist ja nur eine Kleinigkeit, die ggf. nur selten eintritt, die aber einen großen Folgeeffekt haben kann.

Viele Grüße,


Sebastian
_________________
Berlin und Umgebung im Jahr 1989

http://www.bahn1989.berlin

[Jan Bochmann]

Guten Tag,

Das haben wir zum Beispiel bei uns am Betriebshof. Man kann an der Haltestelle "Renninghausen" durchaus 1 Minute später abfahren (Abfahrt immer x:x4) und ist zwei Stationen in Brünninghausen trotzdem ne halbe bis eine Minute zu früh...

Außer vielleicht einmal im Jahr, wo eine Baustelle dazwischen ist und man erstmal 2min dort warten muß, bis die Bauarbeiter ihre Technik weggeräumt haben. Das wäre dann 1 von 365 Versuchen.

Und trotzdem bleibt eine Frage: Warum treten diese Besonderheiten überweigend bei Geschwindigkeiten von 15 und höher auf?

Diese Frage ist ähnlich wie "Warum ist die Sonne grün?". Nach meiner Meinung ist die Sonne nicht grün, und deshalb gibt es auch kein "Warum" dazu.
Nach meiner Meinung treten die oben diskutierten Probleme bei jeder x-beliebigen Geschwindigkeit auf, und deshalb kann ich auch kein "Warum" dazu beantworten.

Ich habe heute mal meinen PC ein paar Stunden mit WN3 Regio (Variante 1318) laufen lassen, mit Geschwindigkeit 20. Es wurde keine Störung gemeldet.

Allerdings enthält das Netz ein paar Dinge, die vielleicht zu Störungen führen können und wo man lange nach der Ursache suchen kann. Zum Beispiel die Linie R82, auf der sich sowohl Busse (in Hassee) als auch Güterzüge (am Taktpunkt TP_00019) durcheinander tummeln. Hoffentlich wird sie nicht irgendwo für komplizierte Signalsteuerungen verwendet.

Grüße,
Jan B.

[Philipp K.]

Und trotzdem bleibt eine Frage: Warum treten diese Besonderheiten überweigend bei Geschwindigkeiten von 15 und höher auf?

Ich selber habe bei meinen Netzen bisher keine Auffälligkeiten bei steigender Geschwindigkeit feststellen können. Wenn ich alle CPU-Kerne mit irgendeinem anderen Programm auslaste, sodass für BAHN nicht mehr genug Rechenzeit übrig bleibt, bleibt BAHN hier einfach stehen, wenn man die Geschwindigkeit hochdreht. Erst, wenn wieder Rechenzeit vorhanden ist, rechnet es weiter.

Möglicherweise treten die Probleme mit erhöhter Geschwindigkeit garnicht häufiger auf (gemessen an der verstrichenen Zeit in BAHN), sondern nur häufiger gemessen an der verstrichenen realen Zeit? Bei erhöhter Geschwindigkeit verstreicht ja erheblich mehr Zeit in BAHN, also passiert auch deutlich mehr, dass Probleme verursachen könnte.

[Dierk Nüchtern]

Allerdings enthält das Netz ein paar Dinge, die vielleicht zu Störungen führen können und wo man lange nach der Ursache suchen kann. Zum Beispiel die Linie R82, auf der sich sowohl Busse (in Hassee) als auch Güterzüge (am Taktpunkt TP_00019) durcheinander tummeln. Hoffentlich wird sie nicht irgendwo für komplizierte Signalsteuerungen verwendet.

Die Rxx-Buslinien stammen noch von mir. Die werden Stück für Stück entfernt, dass Jan die Nummern für seinen Güterverkehr hat.

Ich habe eben Ampeln laufen und an einigen Haltestellen fahren die Busse eben durch.

Mir ist es halt nur aufgefallen, weil diese Probleme mit den Buslinien eben nicht dauerhaft auftreten.

[Sander Fondse]

Ich müss auch sagen, bei Geschwindigkeit 20 läuft Wn3 bei mir total nicht stabil. Bei 19 gibt es ab und zu auch vermehrt Fehler. Ab 18 wird's rühiger. Es sind ab und zu Fahrten mit mehr als 8 Minuten Wendezeit an einen Endpunkt, und dann fällt plötzlich einen Fahrt aus, dannach nicht mehr.


Kleiner technischer Frage :

wird die variabele Haltezeit bei Haltepunkte durch einen RNG (RandomNummerGenerator) erstellt ? Vielleicht hat das etwas damit zu tun. Diese Zähler sind nicht wirklich random. Vielleicht wird bei höheren Geschwinditkeit öfter der selbe Nummer gewählt, was zum Beispiel zur Folge hat dass einen Bus bei Jede Haltestelle die längste Zeit wartest.

Das wäre mal einen interessanter Experiment für Programierer. Wenn man zum Beispiel 1000 mal einen RNG 100 Nummer drehen lässt auf niedriger und auf höhe Geschwindigkeit. Die durchschnittswerte sollte gleich bleiben, aber wird das wirklich so ?

[Philipp K.]

Das wäre mal einen interessanter Experiment für Programierer. Wenn man zum Beispiel 1000 mal einen RNG 100 Nummer drehen lässt auf niedriger und auf höhe Geschwindigkeit. Die durchschnittswerte sollte gleich bleiben, aber wird das wirklich so ?

Normalerweise arbeiten Zufallszahlengeneratoren so, dass sie mit einem bestimmten "seed" gefüttert werden (damit die Zahlenfolge möglichst bei jedem Programmaufruf anders ist, wird dann gerne die aktuelle Systemzeit in Sekunden als Seed genutzt) und dann eine immer gleiche Sequenz von Zufallszahlen erzeugen, unabhängig vom Timing der Aufrufe. Einzig der Zugriff auf den gleichen Zufallszahlengenerator durch zwei Threads oder anderweitig getauschte Reihenfolge der Berechnung der Zufallswerte kann die Folge beeinflussen.

[Jan Bochmann]

Guten Tag,

Möglicherweise treten die Probleme mit erhöhter Geschwindigkeit gar nicht häufiger auf (gemessen an der verstrichenen Zeit in BAHN), sondern nur häufiger gemessen an der verstrichenen realen Zeit? Bei erhöhter Geschwindigkeit verstreicht ja erheblich mehr Zeit in BAHN, also passiert auch deutlich mehr, dass Probleme verursachen könnte.

Genau so sehe ich das auch, habe es nur nicht so klar formuliert.

Grüße,
Jan B.