News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

[Fixed v3.8] Avg speed dropping too quickly when train waits at stop

Started by tick tock, May 08, 2009, 12:11:19 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

tick tock

James -

Is the Avg Speed seen in Line Management supposed to be average speed over the entire month?

If so, then Avg Speed seems to drop far too quickly when a train sits loading in a station.  I did a small test with one convoy on a single rail line between two stops.  From the beginning of a 30 day month I ran the train for 27 days with no loading time at its stops (so it had an Avg Speed relatively close to its max speed), then on day 27 I set the train to stay in the station until loaded.  After 1 day of sitting there the Avg Speed had dropped by almost 50% of its value established over 27 days.  If Avg Speed is truly an average speed, then it shouldn't drop so precipitously.  Can you look into this, or verify that this is how you intend it to work?  Thanks.

Edit:  Fixed in v3.8

jamespetts

Tick Tock,

thank you for your feedback :-) I do not think that this is a bug, however: the average speed is not the average over the whole month in terms of time, but in terms of trips. So, if the convoy undertakes 4 trips with an average speed of 100kph, and 1 trip with an average speed of 10kph, the overall average would be 82kph.

Setting a convoy to wait until it is fully loaded before departing will very substantially decrease average speed, as speed is calculated from distance divided by time, and time is counted from when the vehicle starts loading. This is intentional: would you travel on a train that waited in the station until it was at least half full, no matter how long that that took? Just as in real life, the use of wait until loaded commands should be restricted to cargoes that are not sensitive about their travel time (i.e., have a low or zero speed bonus rating).
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.

tick tock

Quote from: jamespetts on May 08, 2009, 03:48:54 PM
the average speed is not the average over the whole month in terms of time, but in terms of trips. So, if the convoy undertakes 4 trips with an average speed of 100kph, and 1 trip with an average speed of 10kph, the overall average would be 82kph.

James -

Ignoring the OP for the time being.  It seems that trips are weighted equally; so a 10km trip with average speed 90kph averaged with a 90km trip at average speed 10kph gives an Avg Speed of 50kph?

jamespetts

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.

tick tock

Hmmm...this takes out some fun and realism for me.  I can have a convoy that travels from stop A to stop B, with stop C in between, make much more or less income simply based on whether I place C closer to an endpoint or the midpoint of the line, despite the time from A to B remaining constant.

jamespetts

Hmm, I'm not sure that I follow: it is the average speed that counts, not the total time. What counts for passengers is whether their trip is fast or slow, not the abstracted average speed of the vehicle itself. As a matter of coding implementation, it would be very difficult to separate out each origin/destination pair, and assign each its own average speed: that would greatly increase memory consumption and computational cost.
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.

tick tock

James -

To illustrate:

As a test, I created 2 straight side-by-side rail lines of equal length (around 120 tiles, but the absolute distances aren't really important).  I placed stops at the endpoints, so both lines had 2 stops (a stop A and B for each line).  On line 1, I placed another stop (C) relatively close to stop A (11 tiles away).  On line 2, I placed a stop (D) at approximately the midpoint.  So I had something like:

line 1:      A----C---------------------------B
line 2:      A----------------D---------------B

I then put identical passenger trains on the lines (1 convoy on each line) and started them from their respective "A" stops as close to the same instant as possible.  There were no passengers to pick up, so the trains simply did a "touch and go" at each stop. 

Average speed (not Avg Speed) over the whole line is close to the same for both lines, based on visual observations.  Obviously, in terms of average speed, the short-distance leg (A-C) is much lower than the long-distance leg (C-B) on line 1, but over the length of the entire line the train on line 1 takes the same amount of time to travel as the train on line 2 takes to travel its length (so their average speeds are the same).  However, Avg Speed of line 1 is around 135, while line 2 is around 167.  Quite a difference, considering over the course of a month both convoys travel close to the same distance over the same amount of time (thus the same average speed).  They don't match up perfectly, the convoy with the lower Avg Speed on line 1 actually outdistances its counterpart on line 2 by a little bit over time.

Perhaps we differ on how "average speed for a line" is defined?  For a given month and line, I would define it simply as: distance traveled this month divided by time elapsed this month.  I'm definitely not suggesting an Avg Speed for orig/dest pairs.  I'm just suggesting that Avg Speed accurately reflect distance divided by time.

knightly

James,

The problem pointed out by Tick Tock arises because average speed is not calculated as a weighted average based on travelling distance. Is there an easy way to do so?

jamespetts

This issue is not entirely clear cut. Firstly, from a techincal perspective, it is not entirely easy to set up a weighted average speed: currently, average speed is stored as part of the "financial history" set for the convoy (meaning that it shows on the graphs in the convoy's information window). The average speed stored is a sum of all the average speeds recorded in the last month, plus a separate variable storing the number of trips in the last month. The display is then given by dividing the sum of the speeds by the number of trips. This enables the graph to be updated instantly whenever the average speed is changed.

Secondly, the reason for having average speed in the first place is to measure trip speed. People might take trips from A to C, from C to B, from A to B, from B to A or from C to A. Each of those passengers care about their speed, and, to the extent to which they care about their speed less the shorter the journey, that is already accounted for in the revenue calculation, so adding it here would be double counting, and make convoys that have a local stopping section (remember, the declaration time to stop at each stop substantially reduces the speed) and a fast section appear faster than they are for all but trips involving the long-distance part of their run. The passengers taking the convoy between any pair of stops in the local stopping section would get a service far slower than the average would then indicate. Thus, weighting it by distance does not  necessarily produce a correct result, since the passengers taking shorter trips are uninterested in the distance that the convoy travels overall.
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.

knightly

James,

If you are talking about average speed, then weighted-average based on distance travelled should be the correct way of calculation. You think that it does not produce a "correct result", only because you somehow want a metric other than average speed. Besides, while you may say that weighted average will understimate the journey time of local stopping section, I can also say that your current approach will seriously overestimate the journey time of the fast section.

As for implementation of weighted average, you can record the total distance travelled instead of average speeds, and record the total journey time instead of the number of trips (probably you need to change rolling_average[] from uint16 to uint32). In this way you can calculate weighted average speed as easily as with your approach.

jamespetts

QuoteBesides, while you may say that weighted average will understimate the journey time of local stopping section, I can also say that your current approach will seriously overestimate the journey time of the fast section.

That may be so, but the question is then which is worse, and why?
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.

knightly

#11
There is no absolute answer, James, for it depends on the situation. All I can say is, we cannot expect a single metric to take care of all the different situations equally well. With this in mind, a desirable metric is one which does not assume or expect specific circumstances. I would say weighted average is more preferable, as it is the natural formula for speed, and it does not make any assumption. Besides, it is more intuitive to players too.

jamespetts

I'm not sure that I understand that answer - both methods make different assumptions. It is not clear what the reason is for favouring weighted averages here. If the gameplay reasons are equally weighted both ways, then performance will favour the current approach.
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.

knightly

Well, James, I don't want to argue with you on this, just as I don't want to argue with you on the issue of congestion in the other thread.

I just want to remind you that speed = distance / time, and when you calculate an average of speeds with different journey times/distances, you can't simply perform arithmetic average (i.e. adding up all the speeds and dividing by the count). At least that was what I was taught in my Maths and Physics classes. This is what I mean by natural, and I don't think it assumes anything anyhow. And anything that is natural is more intuitive to players.

Anyway, I think it is pointless to discuss further on this subject. I have expressed my opinions and suggestions, and whether or not to accept them it's at your own discretion. You don't need to convince me, for I don't think I will be convinced, much like the case of congestion.

tick tock

James -

As with Knightly, I'm not going to continue to argue this point either.  (Well at least not at this time.  :D)  Thanks for taking the time to discuss it anyway.


I'll wait a day or two to see if anyone else wants to post here regarding the Avg Speed discussion, then I'm going to test the latest version and get back to addressing the issue in the OP again.

Thanks.



Edit: reworded a sentence

tick tock

James -

Okay, back to the OP!

I think I found the problem.  In operation anyway; as it would probably take me many more hours to actually find this in the code.  :D

When a train is idle at a stop, it seems that a trip of 0 speed is being added into the Avg Speed calculation on a periodic basis.  What I see in practice is that Avg Speed is recalculated very frequently (every 1/256 of a month or so?), and Avg Speed's new value is what it would be if a zero speed trip had just been completed. 

For reference, this does not happen when the convoy is idling at a signal.  In this case, Avg Speed is not recalculated until the train has made its next stop and the new Avg Speed value is what would be expected when taking into account the time delay from sitting at the signal.

v3.7 pak128, tested with a passenger train only

jamespetts

What do you mean when you refer to idling at a stop? If you mean that the convoy is waiting for a full or partly full load, then that behaviour is intentional: the waiting time is counted as part of the journey time, which is realistic. Just imagine how long that a 'bus journey would take if the 'bus waited until it got a full load at some or all of the 'bus stops!
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.

tick tock

Quote from: jamespetts on May 12, 2009, 08:22:00 AM
[snip] the waiting time is counted as part of the journey time, which is realistic.

James -

I agree completely with your statement - waiting time should be taken into account, and it is.  But waiting time accrued at signals is being accounted for in a manner that is significantly different from that spent at a stop.  I wasn't questioning whether waiting time should be taken into account, just that it seems that there is a bug that results in a significant difference depending on where the delay occurs.  Whether it's an extra 2 seconds (real time) sitting at the stop, at a signal just outside the stop, or when the User opens up the schedule window without hitting pause; I would think it would have the same effect on the passengers, wouldn't it?  (No sarcasm meant - a serious question)

I've been testing the different ways that the convoy can be brought to a halt.  Setting to load at a stop, making to wait at a signal, and opening up the convoy schedule window are the options I've tested.  Having the convoy stop at a signal or by opening up the schedule window both seem to have the same effect - the waiting time is added to the convoy's time for its current trip and thus Avg Speed is lowered when it's recalculated at the next stop.  This is completely as expected.

But as detailed in my previous post, the same thing is not happening at the stops.  Of course, I agree with your statement about waiting at a stop for passengers - any waiting time should be added to the convoy's trip time.  However, waiting for a period as brief as ~1/256 month causes a drop in Avg Speed that is much greater than that which occurs after waiting a much longer period of time at a signal 1 tile outside the stop.

This isn't a bug?

jamespetts

Hmm - I see what you mean. A difference between the behaviour when stopping at signals and when stopping at stations is not intended. The latest average speed is added to the convoy when it is loaded. Perhaps when the convoy is waiting at a stop, the load routine is called a large number of times (that is not code that I have written, but is part of Simutrans-Standard). I will have a look into this when I get back home - if that is the case, then moving the waiting time addition to the unloading should solve it.

Thank you for reporting that issue, and sorry that I didn't realise what you meant at first.
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.

tick tock