[Csantucci]

Csantucci, on 02 November 2014 - 09:00 AM, said:

I and other people have an other problem since release 2619: after some seconds of route loading, the loading is interrupted and ORTS returns to the menu window. A subsequent load attempt sometimes has success, and sometimes again returns to menu. After some trials the route gets loaded.

Trying to load to instances of OR to make some MP tests, the second instance continues to return to the menu. I can't use it.

I had to increase the timeout time to have things loading regularly. I increased it to 40 seconds. Maybe 20 are enough. I kindly ask James to increase such value.

[eugenR]

Csantucci, on 03 November 2014 - 06:22 AM, said:

I had to increase the timeout time to have things loading regularly. I increased it to 40 seconds. Maybe 20 are enough. I kindly ask James to increase such value.

I has the same Problem with DVZO, this route has heavy KI-Trafic.
about 36 Trains scheduled in the 1/2 Hour before the Player Train start, about 300 KI-Trains programmed from 00:00 to 16:00.
If I start the activities without KI-Trafic, there is no error.

[disc]

commit 2623 did'n helped, just makes the game quit much faster. (5 seconds after loading started)

[Csantucci]

Neither was the problem solved for me. There can be more than one cause slowing down initial load of game. Many AI trains are only one of the causes.
Frankly speaking, to me the watchdog during initial load of game is more a problem than the solution of a problem, and I would remove it, also thinking at people with slow computers. After initial load I don't know yet.

[roeter]

The watchdog feature blocks the start of timetables for medium or large routes.
It seems that the various processes do not respond to the watchdog during the initial load process.
The major timetable I am using at the moment has about 1500 trains using about 400 different paths. The loading of the those paths takes quite a bit longer than 10 seconds - it actually takes several minutes. I set the time-out to 100 seconds but it still crashes.

This watchdog feature should be started only after the initial load. I can't tell if it works during the pre-run phase - it could well be that certain processes do not run frequently during the pre-run phase, for instance the display thread has no work during this phase. With the present set-up I can't even reach that phase.
With 10 sec. time-out I can't get through the signal initiation, with 100 sec. time-out the program crashes during path loading.

Regards,
Rob Roeterdink

[roeter]

I've had a further look at the way this watchdog has been implemented, but there are serious problems during start-up.
The watchdog assumes the various threads complete during the watchdog-interval, and they report this completion.

But during startup there are several instances when time-consuming actions are performed in loops within the thread, which will therefor not terminate within the watchdog timing, and the thread will time-out. The length taken by these loops depend on route configuration, activity or timetable set-up like no. of AI trains and timing of first AI train w.r.t. to start of player train, and computer configuration (file loading time).

There are at least five such routines which cause problems :

• Signalling : Signals.cs : loading of all world-files to obtain signal information.
  
• Activity : AI.cs : loading of activity traffic information.
  
• Timetable : ProcessTimetable.cs : loading of timetable path information.
  
• Timetable : ProcessTimetable.cs : loading of train details information.
  
• Activity and Timetable : AI.cs : AIPreRun.

There may be more which I have missed so far, depending on route configuration.

There are three possible ways to sort the problem :

• Rewrite said routines such that they will allow the thread to terminate.
  Does not seem a very realistic solution.
  
• Add 'pings' to the said routines.
  Could be done, but has the risk that, depending on route and computer configuration, there still may be other parts of the start-up sequence where similar problems could occur.
  
• Activate the watchdog only when the player train is started, and 'normal' processing begins.
  This seems to me to be the safest way out.

Regards,
Rob Roeterdink

[James Ross]

roeter, on 04 November 2014 - 02:12 AM, said:

• Add 'pings' to the said routines.
  Could be done, but has the risk that, depending on route and computer configuration, there still may be other parts of the start-up sequence where similar problems could occur.
  
• Activate the watchdog only when the player train is started, and 'normal' processing begins.
  This seems to me to be the safest way out.

Please do the ping options wherever you can - we've had hangs during startup because of these complex routines and I definitely don't want to just ignore those problems. The timeout will be increased soon but highlighting where things might need feedback added is worthwhile.

[Csantucci]

I haven't analyzed the code, but I think that also MP startup can be one of the points, because every player has to add data for all other players.

Personally I don't remember of having gotten hangs during startup, and I remember also very few hangs at runtime. But maybe I'm a lucky person.

[disc]

I had hangs both at startup, and runtime when a train reached a certain point in timetable mode... since that i managed to change it to simple deadlock exception, but hangs can happen any time.

[James Ross]

A hang reported once the game has started is probably very bad; the render, updater and sound processes certainly should get nowhere near the limit and the loaded isn't doing nearly as much as during initial start-up. I'd like to see some logs from runtime hang reports, preferably in bug reports.

As for the problems during loading, I will be increasing the limit either to the loader generally or at least during start-up to 30s+ later this week. Feel free to try changing that locally and seeing how well it works [1]. Long-term, I'd like to see us work towards having all the pre-run stuff happen as normal (but high-time-step) updates.

[1] In Source\RunActivity\Processes\WatchdogProcess.cs on line 152 change "MaximumLaxnessS" to be whatever limit you wish to test. "MinimumLaxnessS" doesn't have to be adjusted but performance may be a little better if it is closer to "MaximumLaxnessS" (i.e. min/max of 20s/30s is better than 2s/30s).