News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

Route timing bug [11.34]?

Started by DrSuperGood, June 14, 2014, 12:16:08 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DrSuperGood

The screen shot pretty much speaks for itself. A route which takes only 30 hours to traverse there and back (15 hours to reach the station mentioned) is showing up as 60 hours. Even if the "8+ hour" waiting time was factored in there is no way this would convert 15 into 60.

Explanation of how this came about:
With an increasing flow of Bulk goods I considered it time to move from parallel asynchronous lines (loading to X% on one side then unloading on the other, two lines for both sides) to a time tabled convoy flow between my two exchange hubs. These are pretty massive hubs with well over 15k bulk flowing between them every month so I wanted to try 8 convoys a month initially and see if more were needed.

The line was set to load to 100 and wait at the middle exchange for 8 convoys a month spacing. To do this I had 38 convoys which mathematically should be capable of making 8 journeys per month between the two exchanges (there may even be some spare time, required to prevent clumping as convoys take 3 hours to load so need at least a time slots in 3 hours time in order to leave on time).

Obviously with the introduction of new convoys and the addition of existing convoys onto this time tabled line there was quite a waiting time at the start while the convoys spaced out.

What I think is happening? My guess is it takes the waiting time of the convoys as part of the journey time creating a false journey time result since the convoys make the journey much faster, just they need to sit around to make up time while they space out and act as a buffer for loading.

Time a convoy spends waiting for a timetable schedule should only apply to routes that transit through a stop with timetable in effect. "End of line" stops should not add time table delay to route time since there is no actual delay to the cargo (it is the end of the line, all goods were unloaded and the convoy is sitting empty waiting for a time slot to depart).

The result of this is all my bulk cargo destined for the west exchange is now routing via Sarlock's exchange probably to end up in Blue's Scarden Seaport. Not only would this totally flood already strained shipping networks (which are out of my control) with even more cargo, but also loses my company profit. Eventually things should settle down, the journey and wait times should drop away and the route will begin to operate normally but it still is a bit unfair/makes no sense that the journey time is registering so high in the mean time.

Sarlock

Indeed, this has been going on for a while now.  I reported the same issue here.

I have the same problem with a lot of goods choosing other routes due to incorrect transit time calculations.  Sometimes they take circuitous routes on my own lines and sometimes they jump over to other people's lines.
Current projects: Pak128 Trees, blender graphics

DrSuperGood

Currently you are getting terribly flooded by 10k+ bulk goods a month which has overloaded a lot of stations from many of your international docks to Blue's Scaden Seaport. I have tried to restrict the flow to within my own ports by dropping the transfer capacity (keeping it orientated at moving goods out your network). Hopefully the route will compute that it is faster to ship directly between the exchanges and everything will go back to normal.

I am pretty sure this is related to time table scheduling. Everything was working fine until I queued up 30 odd ships waiting for time slots.

jamespetts

Thank you for this report: I have been trying to look into this, although it is always quite difficult using the server game for debugging because it is so enormous. It would help to have some information in order to narrow it down: does the line that goes between Middle Exchange and West Exchange have a complex schedule? How is it set up?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

I've seen this too (currently it takes about 73 hours to get from Glasgow to Penzance). I put this down to poor initial estimates and an absence of point-to-point data. It remains to be seen whether it will iron itself out. I think the length of the route will be a factor here.

DrSuperGood

Quotedoes the line that goes between Middle Exchange and West Exchange have a complex schedule? How is it set up?
It is a two stop schedule.

1. Middle Exchange -> load to 100%
2. West Exchange

After above I finished setting up the line.
50 convoys were deployed to make 11 journeys per month with no offset.
All these convoys are dedicated Bulk goods Clipper (hull) capable of holding 1050t of Bulk.

For 6 months the route time did not update and convoys were running empty (round trip time + delay at port?). Eventually the time updated and things returned to normal.
It now lists West Exchange as 16:37:48 mins travel with 2:26:30 mins waiting.

The line is moving >10,000t of bulk a month so was in urgent need of operation. It has been working nearly 6 months now and finally things are starting to settle. By the looks of things I might even have to raise it to 12-14 convoys a month and hopefully this will go better.

jamespetts

Hmm - very curious. It cannot be the waiting time at the stops at the end of the route, as this is not how the trip time is calculated. In order to understand what is happening, I need to be able to reproduce an occasion on which the incorrect time is set in the first place and use a debugger to find out exactly what happens in the code when this occurs. The more intermittent and less predictable the problem, the harder that it is to do this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

Oh a detail I forgot to mentioned (sorry).

Most of the convoys on the line (30ish?) were re-assigned from other lines doing the same route. This was done mid-journey and involved me having to stop the ship (open schedule) and select the new line. Maybe the pausing and changing of schedule had something to do with it?

jamespetts

Quote from: DrSuperGood on June 16, 2014, 01:21:53 PM
Oh a detail I forgot to mentioned (sorry).

Most of the convoys on the line (30ish?) were re-assigned from other lines doing the same route. This was done mid-journey and involved me having to stop the ship (open schedule) and select the new line. Maybe the pausing and changing of schedule had something to do with it?

Hmm - this is interesting. Has anyone else noticed this sort of issue occurring in these circumstances? It is certainly possible that the two are connected.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

I have further information regarding this problem. It appears related to changing the time table on a route and adding additional convoys.

Two lines (the same bulk line above as well as a food line, same route) had their capacity improved.

This was done in the following order.
1. Raise convoys per month by +1 (for food this was to 5 per month and for bulk to 13).
2. Add an additional 5 convoys to the line to cope with increased service.

Come December (next month) suddenly it is back to insane times like 30 hours travel for bulk and 60 hours travel for food.

All other destinations and goods types (which are different lines) were not affected and still are reasonable. The long goods and packed goods lines still function normall with the same 16 hour time bulk and food used to have.

Cattle ->16:37:48
Long Goods ->16:37:48
Piece Goods ->16:37:48
Bulk -> 35:06:36
Foods -> 63:12:00

Each type of good has a dedicated line with only Clipper (hull) moving the type of good appropriate to the line. All these lines are physically identical with exception of different time table (convoys per month). The idea behind this is that it can allow me to control the flow of goods between exchanges and add extra capacity very easily when required (which was the case above).

However when I do add convoys and increase convoys per month it appears to generate rather random and large times which obviously breaks the line as it appears faster to route indirectly via multiple players (losing me profit and causing them grief as their lines overload) than take the direct connection line between the exchanges. This line then proceeds to empty out and run empty all the time.

If we take 16:37:48 as the standard transit time (as shown by other goods and used to be shown by bulk and foods).
Bulk -> about 2.111 * standard
Foods -> about 3.8 * standard

The different factors could be related to the difference in convoy waiting time as a result of the change to schedule (12->13 is less than 4->5 as far as waiting time change goes).
The different factors could also be related to the difference in convoy number as adding 5 convoys to 55 (bulk line) is much less significant than adding 5 convoys to 20 (foods line).

It could also be some kind of garbage left in memory being interpreted as a time. Changing convoy numbers or schedule causes a rather random and incorrect time to be generated.

jamespetts

Thank you very much for that information: narrowing this down is helpful. I am currently in the process of trying to buy a flat, and so have rather less spare time for Simutrans than normal, as a result of which it might be a while before I am able to look into this, but it is very useful to have this information to hand for when I am available.  Thank you again.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

My first attempts to reproduce this in a simple environment have failed. I can confirm, however, that it seems to not disappear on a month change/path explore, even when these journey times should have been refreshed. I'll let you know if I find out anything else...

DrSuperGood

It seems strongly correlated to performing both a timetable change (raising convoys per month) and adding convoys to the line (especially existing convoys) almost at the same time. If both are performed with considerable time between (say on different months) it seems to always have the correct time. It is also possible that both have to be done very close to the end of a month (as you said, this stuff is computed monthly so it is possible that that computation grabs some invalid state off the new convoys/time table).

Carl

I take back what I said above - I have now seen this disappear after a month change.

jamespetts

Thank you very much for all of your research into this: that is most helpful. As I have indicated before, I am currently preoccupied with some other things and have only limited time to deal with Simutrans matters, but this will be most helpful to me when I do have time to investigate further. In the meantime, if anyone would like to look into the code to see what might be happening, that would be very useful indeed.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

I have noticed that when such strange timing occurs the line average speed is being reported as excessively slow (1). Is it possible the two are some how connected? I mean it would make sense that a huge in-transit time is allocated if it thinks the servicing line average speed is excessively slow like 1 km/h.

jamespetts

It is very possible, indeed quite likely, that the two are connected.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

#17
May I ask: what are the simplest conditions in which anyone has managed to reproduce this? Carl: when you tried to reproduce this and failed in a simple environment, what exactly did you do?

Edit: I have also failed to reproduce this in a simple environment. May I ask a few more specific questions:

(1) how long between re-assigning vehicles to lines does it take for this error to become apparent in the stop to stop timings shown in the detail window in stops;
(2) what is the shortest route on which this has been observed;
(3) has this been observed on any kind of route other than overseas shipping;
(4) does this only occur when assigning vehicles from one line to another, or does it occur in other circumstances, such as adding new vehicles from a depot, removing vehicles from a line, upgrading convoys on a line or opening the schedule window of a vehicle on a line and closing it again without making changes after a minute or so; and
(5) is the average speed of the whole line affected, or only particular convoys?

The greater precision with which I can reproduce this, the easier that it will be for me to fix. Thank you all for your help so far.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

Quote(1) how long between re-assigning vehicles to lines does it take for this error to become apparent in the stop to stop timings shown in the detail window in stops;
Usually by the next month.

Quote(2) what is the shortest route on which this has been observed;
I think I have seen such strange results in very short routes (<1 month transit time). However they also fix themselves faster as it seems that it takes between 1 and 2 round trips to correct.

Quote(3) has this been observed on any kind of route other than overseas shipping;
Slow moving horse drawn coaches along a large costal route when I was setting them up. I wondered why demand would drop when I altered timetable or added new convoys. I think I recall seeing it giving huge values for in transit time. The route had a round trip time of about 2-3 months.

Trains I think also suffer from it but all the passenger lines I run have sub month round trip times so fix very faster before any problem is noticeable.

Quote(4) does this only occur when assigning vehicles from one line to another, or does it occur in other circumstances, such as adding new vehicles from a depot, removing vehicles from a line, upgrading convoys on a line or opening the schedule window of a vehicle on a line and closing it again without making changes after a minute or so; and
So far I have had it occur in the following situations.
1. Changing schedule (moving sub position in stops, changing convoy spacing, etc).
2. Adding new convoys from a depot.
3. Re-assigning convoys from another line that was doing exactly the same route.

I have also seen that adding waypoints to a route makes average speed unstable. I think it is related in this case to the ships breaking when reaching the waypoint for some reason (not all do, some do).

Quote(5) is the average speed of the whole line affected, or only particular convoys?
Whole line average speed. Most convoys report correct average speed. In fact, it makes no sense why average line speed is reporting 0 when all convoys on it are reporting a stable 19. Some convoys suffer periods of "half speed" average speed. In this case a clear 19 km/H average speed convoy (its practically in a straight line for 3 months flat) was showing for several months 10 km/h (1 round trip time?) before returning to the expected 19 km/h.

Although the two problems seem related, there seems to be no connection between line average speed and computed in-transit time. A line with average speed 19 for a certain good (bulk in this case) was still showing a computed in-transit time of 70 hours for a 18 hour journey (food was showing the correct time).

There is a direct correlation between line average speed and profit. When the line is correctly at 19 km/h it makes >1.5 million per month yet when it is at 0 km/h it makes only 15,000 odd.

An almost guaranteed way to recreate it with the server is to use GRANITE player and modify the "-B FLOW EX WE <-> ME" and "-F FLOW EX WE <-> ME" lines (which are the main problem causers). Add new convoys especially causes the problem, you could also try changing which tiles the ships stop at the stops.

jamespetts

Thank you very much for that: that is very helpful. One further question, if I may, which might help to narrow this down greatly: does this problem always occur only after the new/rescheduled vehicles have reached the stop at which the problem manifests itself, or does it sometimes occur before this happens?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

#20
I have not particularly noticed, all these convoys reach one of the two stops very fast as the depot is right outside. The problem is symmetrical so nonsense times are show from both stops to each other.

EDIT

It seems "-B FLOW EX WE <-> ME" is now permanently broken. Despite being fixed to 19 km/h for nearly a year it still reports a journey time >70 hours (correct time is 18 odd). This has been the longest this problem has lasted now, with all other lines that suffered during the change having fixed themselves a many months ago.

jamespetts

I have spent a considerable time this evening looking into this. The ultimate cause of the problem, I strongly suspect, is that the initial timing is not being recorded correctly when a convoy leaves the depot or changes its schedule, resulting in incorrect times being recorded. I do not know what the issue is with the line that seems to be stuck.

Tracking down this problem from the server game is extremely difficult because the game is so enormous that (1) when loading it in a debug build, it becomes so unresponsive as to be more or less unusable; (2) the long shipping lines on which the problem occurs take an extremely long time to traverse a complete journey; and (3) there are so many different things happening that it takes a great deal of work to isolate the particular lines affected: just actually finding the particular part of the code where the bug is occurring using a debugger and looking at the values of variables could well take days. For this reason, I have resorted to trying to find problems in what I believe is probably the relevant area by inspecting the code.

There is a related difficulty, however, which is that the way-improvements branch is quite radically different from the 11.x branch in respect of how it handles the recording of journey times. I have implemented a possible fix to this on the way-improvements branch that, with some care, might be able to be backported to the 11.x branch, although it is not clear whether this bug even existed on the 11.x branch. I do not have time to test this now, but it would be very helpful indeed if somebody could compile a build from the way-improvements branch and test whether this bug can now be reproduced there. Thank you all for your reports and information: that is most helpful.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Sarlock

Here is some interesting info regarding this:



This is a new line filled with newly purchased ships that travels across the entire map from station N001 all the way to N031, then back again to N001.  These stations are served by windjammers, moving at 18km/h.

I took this data from a central station on the line, N016.  I took the list and sorted it numerically so that it is easier to understand.  The ships go sequentially through the stations in each direction -- take a look at the station distances, they increment as you move further away from N016.  But note the transit times!  All over the map -- there is no consistency or logic to why they are these times.  Particularly note N017 and N015 -- these are the nearest stations to N016 and yet it's reporting an 80 and 84 hour transit time... for a journey that is only 29/32km!  This should be less than two hours.

There is no other route for goods to get from N016 to N017 and N015 (and even if there was, it still doesn't explain the 80+ hour transit time), it has to take these lines.
Current projects: Pak128 Trees, blender graphics

DrSuperGood

A temporary fix I found was to set up other small routes with only 1-10 ships in them servicing the same stops. It seems the fewer the number of convoys, the more accurate the time (or less likely for it to become bugged).

Jando

Hello James, and thanks to the moderator who fixed my account!

Apologies for posting in this old thread, but just wanted to let you know that I'm seeing this same bug in my current stand-alone game (Experimental 11.35, normal Experimental pak, no changes to configuration). Can provide screen shots and save-game if wanted.

jamespetts

Can you provide a saved game? I should like to see whether this occurs on the latest development branch.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Hello James!

Saved game can be found at http://simutrans-germany.com/files/upload/Swanminster_Timing_Bug.sve

It's a simple route between 2 towns, run by a number of stage coaches, here's a screen shot:



Average trip time is 2h 35min, travelling time at Intvale (town to the left) is stated as 16h 54min, travelling time at Steepleington (town to the right) is given as 12h 45mins. Eventually the wrong times cleared (through recalculation?) and correct times were shown. After I added a coach or two to the route and modified the spacing on the route travelling times were soon shown wrong again, as can be seen in this second screen:



Now we get travelling times of 54h 58min and 32h 12min. Thanks!

jamespetts

In the latest development code on devel-new, these timings cannot be reproduced: the trip is either 1:11h or 1:02h depending on the direction. This problem, I think, has been solved in the latest code.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

James, is there any chance to revert to an older version of Experimental before 11.35/11.34 where the bug doesn't happen?

Or does anybody have an older version without this bug that he could share?

jamespetts

The trouble is that older versions had other bugs, too.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.