The International Simutrans Forum

 

Author Topic: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1  (Read 217986 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #245 on: February 27, 2014, 10:49:01 AM »
Thank you for noticing this. It is difficult to know exactly what is causing the difficulties, but it does seem that they are at least correlated with the increase in computational load caused by the existence of a large number of convoys, particularly ships, which are more demanding on route-finding.

TurfIt had some interesting ideas about this earlier in the thread, but nothing seems to have come of that, unfortunately.

Incidentally, the time to load the game is a combination of the time to transfer the data (but that is the time during which there is a "transferring data..." progress bar) and the time for the server to re-load the game (which will be slower for the server than the client because the server is single-threaded). This should not by itself by responsible for desyncs.

Offline Sarlock

  • Devotees (Inactive)
  • *
  • Posts: 1340
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #246 on: February 27, 2014, 03:24:50 PM »
Ah, that explains the long delay after the game loads.  My connection is quite fast as well, I typically reach speeds of 2-4 MB/s for most downloads.  The server download only takes 20-30 seconds to occur, then the long wait while the server loads, then the desynch happens within seconds of the game starting.  Given that I seem to be getting the worst of it, it must have to do with my 150ms lag time to the server (due to geographic distance).

I've thought about setting up a parallel copy of the game but at a much closer location to test if that is my issue.  Are you running this server locally (in your home) or do you have it set up on a remote server?  I haven't set up a game server before but I imagine it isn't too complicated.

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #247 on: February 27, 2014, 08:25:12 PM »
What is working for me...

1st connection is almost always instant desync when the game progresses
After switching to another player, 2nd connection will work for some 30mins (so far)

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1443
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #248 on: February 27, 2014, 08:32:25 PM »
TurfIt had some interesting ideas about this earlier in the thread, but nothing seems to have come of that, unfortunately.
Patience  8)
I got distracted by the Mac thing... but I've gone far enough there for now. Back to experimenting with the client timing. I don't want to introduce any other bad side effects like the current algorithm does when the server gets overloaded.

Also, the bulk of the 'loading' time is actually waiting on the server to destroy the map. Specifically destroying the halts takes a ludicrously long time in Experimental vs Standard. Something you should really look at fixing as it's taking 10x longer to join than it should...

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #249 on: February 27, 2014, 11:06:39 PM »
Thank you - and apologies for being a tad hasty. These things take time, I know.

Thank you very much for pointing out the issue with destroying halts - I had not noticed that difference before. I will look into it and see whether any routines in the destructor can be skipped when destroying the world entirely.

Offline AP

  • Devotee
  • *
  • Posts: 1213
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #250 on: February 28, 2014, 02:40:35 AM »
"Having discovered the invention of the plateway, the owner of Associated Shipping decided to survey a new route, which might one day prove useful."

Or put another way, engineering takes ages, and noting the appearance of several sections of strategic plateway on the map, AP decided to make a start sooner rather than later. Ferries and horse drawn trains may follow shortly :-)

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #251 on: February 28, 2014, 02:50:20 AM »
oh yeah, I just wanted to make sure I didn't need to make an awkward climb to get to Monkington from the north.

My intention is to have two mainlines. Furbury-Saltlow through the eastern coast and Norley-Binlock through the canal.

Other than those two, I am not really interested on the west island.

« Last Edit: February 28, 2014, 02:58:18 AM by ӔO »

Offline Sarlock

  • Devotees (Inactive)
  • *
  • Posts: 1340
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #252 on: February 28, 2014, 03:39:36 AM »
Interesting how blind chance made Monkington the largest city on the map and was also placed in a very strategic location at the centre of a large area of cities.

I plan to build a similar system on the eastern island (assuming I can connect for more than 5 seconds at a time), connecting the large urban centres in the south with the north.

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #253 on: February 28, 2014, 04:29:49 AM »
I took a look, but that is very ambitious.

I would suggest watching out for the maintenance costs of such a long line.

and also, if pax use is desired, I would suggest more passing loops.

Offline AP

  • Devotee
  • *
  • Posts: 1213
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #254 on: February 28, 2014, 08:00:45 AM »
oh yeah, I just wanted to make sure I didn't need to make an awkward climb to get to Monkington from the north.
Safeguarding the route; the same reason I figured I had to start building my route soon -  several of the islands are really hilly with just one viable short route along the edge. Hills are such a pain (roll on twin-slope simutrans!)

There are a couple of spots where I'd appreciate it if roads could slightly be realigned, have put up signs. (2200,1060)(1984,1017)(3996,478), but no immediate hurry to do so.

Am hoping I can run it as a single track main line, but I've allowed enough space to double it, because my experience with single track and intensive service has been mixed thus far. But it would keep the maintenance down, since I'll need 7 short(!) tunnels too. I now need to figure out the passing loop spacing and where I aim for at each end.
Interesting how blind chance made Monkington the largest city on the map and was also placed in a very strategic location at the centre of a large area of cities.
Was it chance or did the city cluster setting have an effect? I was thinking I'd aim for Monkington and if you are making it the key node of your network, that makes even more sense. Anyone drawn up plans for the east island yet? ;)

Edit: typo.
 
« Last Edit: February 28, 2014, 06:40:55 PM by AP »

Offline VOLVO

  • *
  • Posts: 115
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #255 on: February 28, 2014, 11:31:51 AM »
Safeguarding the route; the same reason I figured I had to start building my route soon -  several of the islands are really hilly with just one viable short route along the edge. Hills are such a pain (roll on twin-slope simutrans!)

There are a couple of spots where I'd appreciate it if roads could slightly be realigned, have put up signs. (2200,1060)(1984,1017)(3996,478), but no immediate hurry to do so.

Am hoping I can run it as a single track main line, but I've allowed enough space to double it, because my experience with single track and intensive service has been mixed thus far. Bit it would keep the maintenance down, since I'll need 7 short(!) tunnels too. I now need to figure out the passing loop spacing and where I aim for at each end. Was it chance or did the city cluster setting have an effect? I was thinking I'd for Monkington there and if you are making it the key node of your network, that makes even more sense. Anyone drawn up plans for the east island yet? ;)
(NAF&C) [is going to be renamed..]
May I have the franchise on building and operating local service in this area?
(It will mostly be running underground)
And you can operate the intercity service in it.
Also I might (if i have the money rolled in..) extend the eastern mainline to radshot metropolitan area.
« Last Edit: February 28, 2014, 11:51:53 AM by VOLVO »

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #256 on: February 28, 2014, 10:14:07 PM »
@Volvo
I don't mind.

@AP
1984 to 2200, wouldn't it be easier if you go through the south side of the Barnbridge?
Then you wouldn't need to cross the roads there or go through the mountain.
« Last Edit: February 28, 2014, 10:34:16 PM by ӔO »

Offline Sarlock

  • Devotees (Inactive)
  • *
  • Posts: 1340
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #257 on: February 28, 2014, 10:47:00 PM »
I haven't given the east island a great deal of thought on exactly how to lay things out yet, but I have laid a general concept many years ago with canals and am quite content to continue to serve the cities' pax/mail needs through canals for a while longer... at least until better trains arrive.  The cites have grown a lot and many have amalgamated into huge urban areas.

A general concept below, conceptual routes in white, existing hub cities in red, probably remain the same once I advance to rail.  Eventually connect the two networks, but that's a lot of open ground to cover in between on the east side.

This is, of course, predicated on the fact that I will be able to connect for more than 5 seconds at a time.

« Last Edit: February 28, 2014, 11:08:07 PM by Sarlock »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #258 on: February 28, 2014, 11:13:28 PM »
Gosh, you are all planning ahead - it is the 1820s before passenger rail transport over distances becomes viable!

Offline AP

  • Devotee
  • *
  • Posts: 1213
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #259 on: February 28, 2014, 11:47:13 PM »
There's rather little else to do in this era, once one's canal / overseas trading empire is up and running. Possibly explains why the British kept invading places all the time...

James - what is the game setting for maximum interchanges in a journey, for both passengers and freight? I recall the default used to be 7. I'm assuming I have to use undersea tunnels to link the two islands right from the start, because if I have 6 ferries and 7 train journeys, it will exceed the maximum setting and nobody will travel.

@AP
1984 to 2200, wouldn't it be easier if you go through the south side of the Barnbridge?
Then you wouldn't need to cross the roads there or go through the mountain.
By preference I try to use the existing terrain in a realistic fashion rather than just reclaim the ocean. There's enough space to get both a road and railway through along the coastline, am happy to build road bridges.

I mocked up the entire route offline, about a week ago, but since then that road had appeared  ??? It was that in fact that persuaded me I had to build the route now, 4 decades earlier than ideal, but whilst it was still mostly unobstructed.
« Last Edit: March 01, 2014, 12:03:09 AM by AP »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1
« Reply #260 on: February 28, 2014, 11:59:46 PM »
max_transfers is set to 13 currently. Is that sufficient?

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp

I mocked up the entire route offline, about a week ago, but since then that road had appeared  ??? It was that in fact that persuaded me I had to build the route now, 4 decades earlier than ideal, but whilst it was still mostly unobstructed.

okay, gotcha.

I'll fix up those roads when I can log in for a while.

I tried earlier, but I was instantly desynched.

Offline Sarlock

  • Devotees (Inactive)
  • *
  • Posts: 1340
  • Languages: EN
13 should be more than plenty.  I can't imagine connections beyond 9-10 at most, even cross-map.  Especially once travel times increase.

Offline AP

  • Devotee
  • *
  • Posts: 1213
  • Languages: EN
Having properly checked the map, I think 5 ferries and 6 trains is the more likely option in that case, not 6&7*, so 10 interchanges end to end using ferries. max_transfers=15 might allow more flexibility in terms of feeder routes at each end? If it can be handled computationally. I presume extra interchanges don't by themselves introduce a penalty, it remains all about speed & comfort? But I'm still unsure if ferries or tunnels are the way to go...

*island at 1366,1025 is tiny so hardy worth building a railway on.

  • There is an error in the toolbar which says stone rail tunnel (from 1829) costs $22000 to build and $480 to maintain. In game testing shows it costs $2750 to build, maintenance I don't know (any ideas?)
I prefer the tunnel option for simplicity sake, one railway right through but I'm aware the maintenance might be punishingly high.

Route Data (approx)

No 1 Tunnel =   30 tiles
No 2 Tunnel = 100 tiles
No 3 Tunnel =   20 tiles  -  @AEO: hence why going through the mountain doesn't concern me unduly
No 4 Tunnel = 800 tiles
No 5 Tunnel = 170 tiles
No 6 Tunnel = 300 tiles  (200x, 100y) - not sure if there is a maintenance reduction for diagonal ways?
No 7 Tunnel = 250 tiles
___________________+
                     1,670 tiles of tunnel  (at $2750/tile, $tbc/mth)
Route length: 3,954 tiles (Latitude)
Ergo route is 42% underground

Stone Tunnel 1670 tiles long = $4.5M to build,  but how much to maintain???
« Last Edit: March 01, 2014, 12:55:24 AM by AP »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Ahh, remember that the cost shown on the toolstrip is per kilometre, not per tile.

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp
okay I touched the roads up so you can remove those markers.


FYI, there is a ship off the coast of Dule that is stuck.

Offline VOLVO

  • *
  • Posts: 115
The thing is that cross-atlantic (let's say..) trains is really a bit crazy, a bit like what the victorians proposed..
I think the two main island realistically should be coneected by either ships or planes..
But then, you got the money to do so.. oh well.. ;D

Offline AP

  • Devotee
  • *
  • Posts: 1213
  • Languages: EN
@AEO - Thanks :)   I wonder about a bridge at 2167,1048 also, but i can't remove the level crossing now (it's on your tile of road).
@James - oh yes, always forget that one.

The English Channel tunnel construction was stopped only by politics, not engineering. Serious proposals were put forward several times from 1857, the first had an intermediate ventilation shaft on the varne sandbank. But the military were opposed to it.

They actually started building it in 1882, they said they could have built it in 10 years. http://sussexhistoryforum.co.uk/index.php?topic=841.0

Also, don't forget this one: when the water is shallow enough many things are possible :)
« Last Edit: March 01, 2014, 11:30:02 AM by AP »

Offline Carl

  • Devotee
  • *
  • Posts: 1682
    • Website
  • Languages: EN
(I was going to post a new topic for this, but since it's being discussed here, I thought it better not to clutter up the dev board!)

The clock is rather "jerky" in that it freezes up for a few seconds, then bursts ahead again.  It does this in offline play as well though not quite as pronounced (fast forward jumps between 7x and 13x, back and forth).  It may be related to there being over 3,000 convoys in motion and the amount of calculation required.  I suspect that it is this that is causing the frequent desynchs.  It was fine earlier but that was because over 1,000 of the 3,000 convoys were in depot.  After we sent them all back out the game because quite lagged again and the desynchs returned.

Quote from: James Petts
It is difficult to know exactly what is causing the difficulties, but it does seem that they are at least correlated with the increase in computational load caused by the existence of a large number of convoys, particularly ships, which are more demanding on route-finding.

I've been using 11.9 for a while, and in testing 11.21 the most noticeable difference is this "jerkiness". The most recent savegame for the Balkans map, which features no ships, bears this out -- in 11.9, on my machine, fastforward fluctuates between the high 30s and the low 50s, spending almost all its time between 40x and 49x. In 11.21 (and 11.20) the variation is much more stark, from 10x-40x ish. (Your numbers will vary depending on CPU, obviously). This effect is most obvious when following a convoy whilst fastforwarding. It suggests that the issue is not merely the volume of computational load but also the way in which it is being managed.

This is partly an aesthetic issue - when following convoys, it's nice to see them moving smoothly rather than "jerkily". But the jerkiness means that overall performance is lower, so it is a genuine issue, I think. Perhaps it's simply a necessary consequence of recent code changes, but it might be worth looking into.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Carl - thank you for the feedback: that is useful. Do you actually mean 11.9, or are you referring to 11.19? 11.9 is really rather old now, dating from August last year.

Offline Carl

  • Devotee
  • *
  • Posts: 1682
    • Website
  • Languages: EN
I'm afraid I do mean 11.9 -- this is a dual effect of my (a) not playing Simutrans much in late 2013 and (b) erring on the side of conservatism when faced with a new version.

I appreciate that an 11.9 vs. 11.21 comparison is not very useful, so I apologise for this. If it helps, 11.15 is also much less "jerky" than 11.21 when loading the same map. 11.17, however, is comparable to the latest version - so whatever had this effect seems may have taken hold between 11.15 and 11.17.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Ahh, thank you for narrowing it down. I will look into the differences between those versions and consider whether anything can be done.

Edit: Hmm - there is nothing obvious that impacts on performance critical code between those two versions.

Offline Sarlock

  • Devotees (Inactive)
  • *
  • Posts: 1340
  • Languages: EN
The "jerkiness" came with release version 11.19.  Before that, when fast forwarding, you got a fairly consistent rate of speed increase, but after 11.19 it bounced between two fairly constant numbers (in the online game, I get 8x and 15x).  It also introduced the same effect in the server game, at normal speed, the clock bursts ahead, then slows, bursts ahead again, etc.  There must be some significant computational load that happened with 11.19.

EDIT It seems to occur every 4-6 game seconds in the server game at normal speed, just by watching the clock tick.

EDIT 2 For whatever reason, I've been able to connect longer today than I have in days.  Has anything changed or am I just lucky today?
« Last Edit: March 01, 2014, 06:32:24 PM by Sarlock »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
I have not changed anything on the server. It is odd that Carl and Sarlock report a different point at which the performance issue arose. Is it still present in 11.21? I thought that this had been eliminated when the wayfinding bug was fixed.

Incidentally, testing on the way-improvements branch, which is closely based on the 112.5-merge branch, which forms the basis for the next major release, shows much more reliable connexions than testing with the 11.x branch using a saved game from 1779: the 11.x branch will engender a desync very shortly after connexion, whereas the way-improvements branch will allow the client to stay connected for as long as I tested, which was over an hour.

Offline Sarlock

  • Devotees (Inactive)
  • *
  • Posts: 1340
  • Languages: EN
This may very well be the source of the issue: having over 3,000 ships all way-finding at the same time.  Perhaps the jerkiness was introduced earlier but we only started to notice it once we reached a certain amount of convoys in motion.

We'll see if the merge to 112.5 resolves this (once the conversion is complete).

Offline Carl

  • Devotee
  • *
  • Posts: 1682
    • Website
  • Languages: EN
I have not changed anything on the server. It is odd that Carl and Sarlock report a different point at which the performance issue arose. Is it still present in 11.21? I thought that this had been eliminated when the wayfinding bug was fixed.

The degree of certainty in Sarlock's assertion makes me suspect that I would have reached the same conclusion had I tested for longer ;) I'll take another look later.

Offline Sarlock

  • Devotees (Inactive)
  • *
  • Posts: 1340
  • Languages: EN
Unfortunately I have a very vague understanding of the way the network interface is coded, but it seems to me that there should be a way to resolve the frequent desynch issue.  I just had another one occur right when there was a seasonal update to the area that I was working in.  Given that there is a fair amount of CPU load now, for both server and client, how does the system ensure that both systems are in alignment with their clocks?  If one CPU is computing faster than the other, how does it realign itself?  Is there a mechanism for the client to speed up or slow down to keep in time with the server?

Without knowing the details, I imagine that a desynch occurs when the clocks reach a certain spread apart... or are there other factors involved?

If there's a way to significantly speed up the map destruction process, it would help a lot... the worst part of desynchs is that you have to wait 5 minutes to reconnect again.  Not only is this a long time to wait but it also forces any other players in the game to wait that long as well before they can continue playing.  There has been periods where 2-3 players are all trying to play but we each get desynched and then you spend most of your time just waiting to play.  For now I am only logging in to the game when there is only myself playing - any additional players and I desynch far more frequently.

re: the "jerkiness"
Carl, you may be right in your determination of when it started.  We only noticed it in the server game recently but it may have occurred before and we just didn't have enough convoys in motion to see it.  Your GB map has a lot of convoys and would probably have highlighted the issue before we saw it.  There is some computational load that was added that seems to be dragging things down every time it does its calculation (every 4-6 seconds, it seems, in the server game).

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
The way that it works is that the client and server produce the same result in parallel: information is sent from the server to the client whenever any other player performs a task to update the client's world, and from the client to the server whenever the local player performs a task. The simulation is broken down into steps, and it is imperative that the action is performed in precisely the same step on the server and every client, or else they will get out of sync and disconnect. The server frequently checks with the client whether it is in sync by checking whether a sample of important variables, most importantly the random number generator seed, is identical for the same step number on the client and server. If there is any difference, the server will kick the client. The server will also kick the client if the client runs ahead of the server (the client can safely run behind the server: it will just cause a delay between a player sending a command and it being executed).

Offline TurfIt

  • Dev Team, Coder/patcher
  • Devotee
  • *
  • Posts: 1443
Is there a mechanism for the client to speed up or slow down to keep in time with the server?
There is, unfortunately it does not handle the case where the server is overloaded very well. I've had a chance to continue working on improving things this weekend, but it'll likely still be a couple weeks before I'm happy with it. It's easy to have the client maintain time with the server, it's hard to do it in a way that doesn't make you seasick watching the vehicles!

There's also a bug in the existing algorithm that can result in the client falling farther and farther behind. I ended up over 30 seconds behind once within 5 mins of connecting. That would make it virtually impossible to build anything.

Finally, the server itself is much more erratic than I can duplicate with a local server. I suspect due to its VPS nature. Likely trying to run a heavily loaded server on a VPS is futile. And note, heavily loaded won't show up on any CPU utilization graph, the simutrans workload is too spiky.


Without knowing the details, I imagine that a desynch occurs when the clocks reach a certain spread apart... or are there other factors involved?
jamespetts answer is good. Although in the case of the client running ahead it disconnects itself rather than the server doing the kicking.
You can run the game with 'simutrans-experimental -debug 2 -log', and check the resulting simu.log file after a desync for the reason. Most common would be 'wanted to execute in past' meaning the client ran ahead, and 'checklist mismatch' meaning a game bug.
If you're running ahead, you should set additional_client_frames_behind to a higher number. Also while closely watching the timing lately, I've found things work much better if the sum of server_frames_ahead and additional_client_frames_behind is integral with server_frames_per_step. So for the current server settings, you want client settings of 4, 9, 14, etc. Also @jamespetts - server_frames_between_checks should also be integral with frames_per_step.


If there's a way to significantly speed up the map destruction process, it would help a lot... the worst part of desynchs is that you have to wait 5 minutes to reconnect
I see jamespetts made a change trying to help, but most of the delay is coming from the removing from halt lists section which is shared with Standard. I took a quick look and it looks safe to skip when destroying the world. @jamespetts - care to assess that section closer?  it's responsible for 48 of the 52 seconds the map currently spends unloading.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Administrator
  • *
  • Posts: 20918
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
TurfIt - thank you very much for your input. I have had another go at reducing the map unloading time based on your latest suggestion, which is now on the 11.x branch: I should be very interested in any comments on this.

I must confess to being slightly confused by what you mean by "server_frames_between_checks should also be integral with frames_per_step": perhaps I am just being dim, but I should be very grateful if you could elaborate. Thank you.