Topic: Memory requirements for the Bridgewater-Brunel server

[Vladki]

I have just tried connecting to Bridgewater-Brunel server with 8 GB of RAM and it is clearly not enough. System was swapping and the game was "jumpy" even offline. Probably 10 GB are minimum for this game.

[jamespetts]

Yes, you will not be able to run this as a client with 8GB of RAM - the client takes more memory than the server as the client has but the server has not the graphics to consider.

However, this is not relating to the loss of synchronisation reported, but rather relates to the thread from which I split the thread about loss of synchronisation, so I have split this further.

[ACarlotti]

Are you running Simutrans Extended with the "-nosound" option? If not, then you will be loading over 300MB of sound which you presumably don't need.

EDIT: On my laptop I am running an optimised build (i.e. DEBUG not defined in the makefile) but with debugging symbols added, built using gcc and running on Arch Linux. Virtual memory usage is approximately 9.2GB but physical memory usage is only 6.9GB (out of 16GB RAM). Total physical memory usage is 50.8% (when I close my web browser but leave various text editor windows open - I think the text editors account for more than 0.8%). So in theory 8GB RAM ought to be just about enough, although if you system is more resource-intensive than my minimal Arch Linux system, that might cause more trouble.

EDIT 2: Ok, I just looked again and memory usage was up to 7.6GB, which is more troubling. I think that must be the path explorer kicking in when it wasn't previously running. So that does seem like slightly too much, although it's plausible that it might eventually settle down a bit more if it can ge the right things into swap.
Also, note that some jumpiness is due to 'step' being more computationally expensive than 'sync_step', so if your computer is resource limited you'll find that the gap between sync_steps will be noticeably larger after every 8th sync_step, when a step is being run.

[DrSuperGood]

The jumpiness when connected to the server is because of how the synchronization works. The server cannot run at full speed so the client must periodically pause and wait for the server to progress, likely for the reasons provided above. This once and forever solved the biggest cause of OoS drops in Simutrans, when a client ran ahead of the server.

[Vladki]

The game was jumpy even offline

[jamespetts]

"Jumpy" is ambiguous: it might refer to intermittent unresponsiveness of the interface or to the game simulation pausing whilst the interface remains responsive. The former would be due to slowness on the client. The latter would be due to slowness on the server, combined with Dr. Supergood's (very helpful) algorithm to prevent losses of synchronisation caused by clients running ahead. It is possible, of course, to have both at once, as the causes are not mutually exclusive.

[DrSuperGood]

The game was jumpy even offline

Did you pause and resume it? You might want to post your system specs since I am using a 10 year old I7 920 and have little issues. However I do have 18 GB of DDR3 so do not suffer any page faults when playing which can cause a massive performance decrease.

Sometimes the game time pacing gets messed up causing it to stutter and run at a stupidly low FPS. This usually happens when an action freezes the game, e.g. checking a non existent server. It will remain like this until caught up which can take several minutes. In such a case pausing and resuming resets the timing fixing the issue. I believe the cause is that it thinks it has fallen behind and so tries to skip more to catch up.

If your CPU cannot cope with the game, then when connected to the server you will experience ever increasing latency as you fall further and further behind. You may wish to consider getting a faster laptop then if you want to keep playing maps of such complexity (which I agree is a tad extreme, the server was slowed many times so my CPU could keep up).

[jamespetts]

One thing that is worth noting is that the poor server performance caused by being near the maximum memory consumption and having to use swap space might make the game more playable in the case of those with low performance clients by stopping them from falling behind the server and thus having unacceptable levels of lag.

[DrSuperGood]

One thing that is worth noting is that the poor server performance caused by being near the maximum memory consumption and having to use swap space might make the game more playable in the case of those with low performance clients by stopping them from falling behind the server and thus having unacceptable levels of lag.

The solution to this could be to allow the game to dynamically adjust tick rate based on connected clients, down to some low limit after which the player could be shown a message warning them that their computer is too slow to keep up with the server and will fall forever further behind. However that is a topic for another time and likely something that Standard can use as well.

[jamespetts]

The solution to this could be to allow the game to dynamically adjust tick rate based on connected clients, down to some low limit after which the player could be shown a message warning them that their computer is too slow to keep up with the server and will fall forever further behind. However that is a topic for another time and likely something that Standard can use as well.

That is an interesting idea which might make things easier for players, although not urgent by any means; by "tick rate", do you mean the framerate here?

[ACarlotti]

That is an interesting idea which might make things easier for players, although not urgent by any means; by "tick rate", do you mean the framerate here?

Sync_step rate, presumably. The gui frame rate can be higher than this.

[jamespetts]

Interesting.

[DrSuperGood]

That is an interesting idea which might make things easier for players, although not urgent by any means; by "tick rate", do you mean the framerate here?

Frame rate is too ambiguous in this context since simulation speed is not necessarily tied to frame rate and ideally should not be at all for smoother client side animation. I am referring to the rate at which state update steps are made. This could either slow game speed down (same results but take longer) or increase time interpolation difference (slightly different results but same relative game speed). As long as the timing changes take effect on the same tick/update step for all clients then they should all remain in sync.

[jamespetts]

It would be very worthwhile to have a method of allowing faster clients to have a smoother, higher framerate experience while connecting to a server that cannot keep up with that framerate. I am not sure how fundamental a change that this would require; unless trivial to implement, I am unlikely to be able to prioritise this myself for many years, but if someone else were interested in working on this, it would be most useful.

Slowing the actual progress of the game should be avoided, as this is likely to be frustrating for players, but if there is a way of allowing faster clients to have a higher local framerate whilst staying in sync with a slower server and slower clients, this would be excellent.

[ACarlotti]

I am referring to the rate at which state update steps are made. This could either slow game speed down (same results but take longer) or increase time interpolation difference (slightly different results but same relative game speed). As long as the timing changes take effect on the same tick/update step for all clients then they should all remain in sync.

I think it would be a bad idea to dynamically adjust the number of ticks in a sync_step according to the speed of connected clients, since it would make the game less stable and harder to debug. For the former point, I'd note that some vehicle movement could become more glitchy or imprecise if the number of ticks in a sync_step is increased (although you might be able to restrict yourself to a range where this is unlikely to become a problem). For the latter, I'd point out that a bug on a server game that only occurs when a sufficiently slow (but not too slow) client connects would be very hard to reproduce and diagnose.

I think the better solution would for a server to have a target sync_step rate and a minimum sync_step rate. The server will aim to run at the target sync_step rate, but will run slower if any of its clients aren't keeping up with that sync_step rate. However, a client that can't keep up with the minimum sync_step rate would be left to fall behind so as not to impact upon the experience of other players too much. (Of course, if the server cannot itself maintain the minimum sync_step rate, it would run slower. Any sufficiently powerful client ideally should be able to run with a faster gui frame rate than sync_step rate; I believe this is already the case.

[Vladki]

Did you pause and resume it? You might want to post your system specs since I am using a 10 year old I7 920 and have little issues. However I do have 18 GB of DDR3 so do not suffer any page faults when playing which can cause a massive performance decrease.

My CPU is Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz (2-core + HT), 8 GB RAM, maybe 4 years old (intel NUC)
I have connected to the bridgewater brunel game 1-2 years ago without any problems.
Looking at cpu usage - that might be problem too, it is at 200-400 %.

And the game is jumpy even after pause/unpause... UI is not responsive... Simply my computer is to slow for that size of map.

[DrSuperGood]

My CPU is Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz (2-core + HT), 8 GB RAM, maybe 4 years old (intel NUC)I have connected to the bridgewater brunel game 1-2 years ago without any problems. Looking at cpu usage - that might be problem too, it is at 200-400 %.

The CPU should not be an issue. As long as it is boosting to 2.60 GHz (not being thermal throttled) it should run the server fine. The 8 GB of RAM is more likely the issue seeing how I can see Simutrans Extended hit 6GB or more of memory usage.