There is a simutrans experimental test server.
(http://zeropoint.cc/simutrans/teststatusico.png)
System: Minimal Debian 6.0 VPS with 256MB RAM / 256MB swap.
Some basic information about the current status of the server can be found here (http://zeropoint.cc/simutrans/statpause.php).
Game clients can connect to it at zeropoint.cc
It uses Pak128.Britain-Ex-0.8 and uses version here: (http://forum.simutrans.com/index.php?topic=7604.0)- (version 9.12 clients should work)
Any and all feedback appreciated.
Thanks.
dM
I have tried to connect to it but I always have a pak mismatch (even though the server and client use exactly the same setup apart from the binaries, as I am connecting from a windows client)
DeMangler,
thank you for checking this. I am not sure what is causing the mismatch (perhaps case sensitivity in the pakset file names?), but you can force join, ignoring the erroneous pakset mismatch by using the load game dialogue and typing in the server address (there might be an additional switch; but I do not immediately remember now).
I shall try connecting to this when I get home. Thank you very much for setting up a server; it is most appreciated.
I noticed that even though I thought I was running a 9.6 windows exe it was in fact 9.5.
I think this is because I was mistakenly downloading the wrong zip (your github link to the windows latest zip is not working.)
I used the alternative link posted here http://forum.simutrans.com/index.php?topic=1894.msg70939#msg70939
Now I am running a 9.6 windows exe it does not report a pak mis-match and I can connect fine.
Thanks.
Nice. No problem so far. :)
But I think you should password public service player.
Quote from: vonjo on June 04, 2011, 08:24:02 AM
Nice. No problem so far. :)
But I think you should password public service player.
Thanks for the tip, (and the info about using simgraph0.cc from standard btw).
I will definitely password the public service player when I start up a serious one, I will probably use obey timeline too on at least one game.
This game is mainly so I can get an idea of how large a map the hardware can handle. I normally play with huge maps and I think with multi-player, the bigger map the better.
At the moment the server is using about 30% of the total RAM (including swap) available to it (according to top).
I need to see how that changes when people build large networks and passenger / vehicle numbers increase.
I do not really want to go over 50% on the RAM for the game server alone, so we shall see.
:)
dM
Ok, no problem. :) It means, to test the server, I can build factories and cities, right? So we can test the server under heavier load.
Quote from: vonjo on June 04, 2011, 03:45:16 PM
Ok, no problem. :) It means, to test the server, I can build factories and cities, right? So we can test the server under heavier load.
Yes. :)
I should note that playing with the timeline off is very much not recommended for par128.Britain, especially the Experimental version.
Quote from: jamespetts on June 04, 2011, 05:07:36 PM
I should note that playing with the timeline off is very much not recommended for par128.Britain, especially the Experimental version.
I am glad you said that. I normally play with huge maps and obey timeline on from 1830. I hope to be able to do this with the server too when I have an idea what it can handle.
If anyone has any knowledge of the resource usage of simutrans experimental servers on linux with various size maps and populations I would be pretty interested.
In any case, I hope to be able to contribute to such knowledge soon.
dM
deMangler,
I think that you are the pioneer in this field so far - I shall be very interested in your results!
I have now started playing this as a provider of express coach services - "Brown Line". I am noticing desyncs when I try to change the names of stops, players or lines, but, aside from that, all is going well.
Edit: DeMangler - I suggest that you connect your dock in Pentchester to a 'bus stop to integrate with my 'bus network there to increase the ridership on your ferry.
Edit 2: One particular problem that comes from playing with the timeline off is that road vehicles get stuck behind horse and cart type private cars that should not exist in later eras.
Quote from: jamespetts on June 05, 2011, 10:40:57 AM
I have now started playing this as a provider of express coach services - "Brown Line". I am noticing desyncs when I try to change the names of stops, players or lines, but, aside from that, all is going well.
In total I have had 5 desyncs. 3 were when adjusting or renaming lines from within 'new line' in a depot. The other two were just when I was observing.
The server itself has been 100% stable with no CPU/memory use spikes or other signs of a problem.
As of 1869 the memory usage has increased from 80MB to 85MB since the game started in 1830.
Bandwidth usage:
1 client 25kbits/sec
2 clients 37kbits/sec
<edit> Hmm. actually there was iptraf over ssh in there too. My bad. Very approximate figures anyway.
Quote from: jamespetts on June 05, 2011, 10:40:57 AM
Edit: DeMangler - I suggest that you connect your dock in Pentchester to a 'bus stop to integrate with my 'bus network there to increase the ridership on your ferry.
I figure I may as well make it public as that is something that has not happened yet in this game.
Quote from: jamespetts on June 05, 2011, 10:40:57 AM
Edit 2: One particular problem that comes from playing with the timeline off is that road vehicles get stuck behind horse and cart type private cars that should not exist in later eras.
Yes, I had problems with that early on which was why I set up the ferry service between Birnwell and Brushliegh Docks.
Thanks to your technologically miraculous coach service the captain of the SS Great Britain has had to sell his daughter's virtue to pay for his aging mother's medical bills and import cheap slave labour from the furthest reaches of the empire to run the boilers.
:D
<edit> I just noticed actually that due to it's minimum load limit SS Great Britain is spending all it's time in the dock. Reminds me of when I used to live in Bristol I use to walk past the SS Great Britain regularly.
Now I live in Swindon I walk past a big statue of Isambard Kingdom Brunel lots. He certainly did leave a legacy. A statue of him in pak128 Britain would be very appropriate. Anyway, off topic, blah blah.....
This is encouraging indeed! It's good to see that this remains stable. I am just about to push version 9.7 with a few bugfixes - perhaps we could start again with the new version and a map twice as large with 4x as many cities and the timeline on to see how the server copes with something a little more strenuous?
Edit: As the server is about to be taken down and restarted with 9.7 and a larger map, some things that I learned by playing this game:
* it pays to keep waiting times down on local 'bus routes, especially when they feed into longer-distance coach or train routes (do this by having several different direct, linear routes in a town rather than a single circular route, and have at least a couple of 'buses on each);
* ensuring that stations/stops don't get too crowded and have enough capacity is important to prevent losing large amounts of money through refunds;
* the more routes served by a stop, the larger that its capacity will need to be;
* the convoy spacing feature is very effective for local 'bus routes with more than one 'bus if the cnv/month value is set appropriately - something around 60-70 is good for a small town 'bus route with two 'buses;
* connecting to a city containing another player's 'bus network will often cause that network to become overcrowded; if that other player is not around to fix it, be prepared to add capacity of your own; and
* watch out for 'bus loading times - the single door type of 'bus takes longer to load than the double door type, which can impede average speeds, especially in larger towns.
I have re-started the server with version 9.7.
There is a somewhat larger map and more cities / industries.
Also the public player is passworded this time and obey timeline is on, from 1830 (so could be a bit of a slower start than last time).
Again - all in the interest of testing so joining players be warned the server may be re-started for testing purposes before your empires have fulfilled all your dreams.....
Have fun.
dM
For those interested in the start and end savegames from the previous test server (v9.6) they can be downloaded here (http://www.box.net/shared/zc5lhki5y3).
Windows Client v 9.7 On-line Play Crash Report.
Created Coaching Stable
Clicked on single horse.
Popup:
FATAL_ERROR:
float32e8_t::operator *
(const float32e8_t & x)
const
Overflow in 1.#INF * 1.5
PRESS ANY KEY
Key pressed. Client Crashed.
Any subsequent login if the coaching stable is clicked above popup displays as before.
Also every time I reconnect after this crash the message stating the number of connected clients increments by one.
This happens whether I have previously entered my password or not.
I appear to be able to create and click on Staging Posts ok.
Server still appears stable.
dM
dM,
thank you for the bug report: this is related to the switch from fraction to synthetic floating point; I have reported this to Bernd, who wrote that code. I suspect that it is related to the fact that single horses have very little power. In the meantime, the double horse set does not have the same problem, so I suggest using that for the time being.
I have found a further bug with 9.7 - the maximum walking distance is incorrectly calculated when creating a saved game, resulting in passengers being able to walk to all destinations within 6,000 tiles (and thus not using the player's transport). I have fixed the bug in my 9.x branch, so it will be fixed for the next release, but, in the meantime, here (http://simutrans-germany.com/files/upload/dm-online.sve) is a saved game with a corrected value substituted manually.
Quote from: jamespetts on June 06, 2011, 12:06:16 PM
I have found a further bug with 9.7 - the maximum walking distance is incorrectly calculated when creating a saved game, resulting in passengers being able to walk to all destinations within 6,000 tiles (and thus not using the player's transport). I have fixed the bug in my 9.x branch, so it will be fixed for the next release, but, in the meantime, here (http://simutrans-germany.com/files/upload/dm-online.sve) is a saved game with a corrected value substituted manually.
I have re-started the server from the fixed savegame.
For some reason the server listing at http://simutrans-germany.com/serverlist_ex/ has begun showing zeropoint.cc as off-line quite often when it is really on-line, so try connecting anyway it may well be ok.
dM
I have found a number of critical errors in 9.7 (including one that gave rise to large negative revenues incorrectly, which stopped me from having enough money to buy trains for my railway line in this game, and one that made the maintenance costs of buildings far too low), so I have released a critical fix release in the form of 9.8. This also fixes the crashing issue with the single horse, although note that an erroneous speed may be displayed in the depot window when using the single horse. I strongly recommend that the server be upgraded to version 9.8. Apologies for the difficulties, and thank you for your help with testing.
Quote from: jamespetts on June 06, 2011, 01:18:46 AM
dM,
thank you for the bug report: this is related to the switch from fraction to synthetic floating point; I have reported this to Bernd, who wrote that code. I suspect that it is related to the fact that single horses have very little power. In the meantime, the double horse set does not have the same problem, so I suggest using that for the time being.
single horses no longer produce illegal numbers in my master branch ;)
Bernd,
tested - thank you very much! It's too small of a fix for an update in itself, but it will be in the next and subsequent versions.
Server has been restarted with a new map and version 9.8.
:)
Excellent! Probably shan't be able to do much until to-morrow evening, but this should be a rather more productive test than the false start that was 9.7. Thank you very much indeed for hosting this.
Edit: I notice that the towns and industries are rather few in number - a better game, I suspect, will be had with a somewhat denser map (and it will be a rather better test of the resource consumption, too). As it stands, whoever establishes a railway between Sackingport and Pondsand will make large quantities of money, whereas everyone else will be rather out in the cold.
Ok - restarted with more stuff (than ever before!!!)
It did look a bit empty.
Maybe we can push some limits. :)
dM
<edit>
After this instance had been running for 1 1/2 hours I noticed I could no longer log-in. I would get "server does not respond. Even after re-starting the server.
As far as resource usage goes the server appeared normal. No strange output to the console."
Re-starting the server without using the automatic save seems to work though.
I have now re-started the server with the same map at it's initial state to see if it repeats.
Before anyone asks... I don't have a save or the logs because I stupidly did not back them up the instant I noticed a problem, so they were overwritten. Ooops. Must remember to do that next time.
dM
Excellent! Should be an interesting test. I don't have time to log in myself until this evening, but should encourage others to do so to test and have fun! Thank you for your work on this.
Here is a screenshot of the map from 1867, after the game has been running since 1830, or 2 days 6 hours.
(http://i985.photobucket.com/albums/ae337/demangler/th_scr-dm-1867-.png) (http://i985.photobucket.com/albums/ae337/demangler/scr-dm-1867-.png)
Click to enlarge.
dM
Server Crashed at 09/06/11 22:18 UTC.
Fortunately - this time the latest save appears to be working fine, so back up again, for now....
Log and save here. (http://www.box.net/shared/6fl89b41dv)
dM
i think it went down with my client segfaulting. (sorry i don't have any debug information)
I sent a train to "withdraw" clicked on it when i expected it to be empty and gone was the client.
The server seg-faulted as well. luckily I am an insomniac computer freak so I am still awake at 0630 am. ;)
I may have to write a script to periodically check if the server has stopped running and bring it up after doing backups and reporting, kind of like the one that updates the on-line/off-line image in the top of this thread.
I don't know of a way to get the server to autosave regularly, the setting in conf doesn't seem to do anything with the server (works with the client). It only seems to save when someone logs in.
Hope not too much work was lost in the game....
dM
Server has segmentation-faulted again.
I suspect it is having memory problems. I will see what can be done, but I may have to try with a smaller map.
dM
Why do you think that this is a memory issue? How much memory is being consumed, and how much is free? A segfault means that the programme has tried to access a sector of memory that has not been allocated to that programme. That is almost invariably as a result of a bug in the code, which type of bug is common in C and C++ due to the manual memory management required in those languages. If the problem was insufficient memory, you would be more likley to get an out of memory error.
The difficulty with tracking down access violations/segmentation faults on server games is that it is harder to work out what triggered the crash and therefore find the fault. If people could record as best they can what it was that happened before the crash (and SDog's report above in that respect is useful; I shall have to look into issues with the replacer), that would be most helpful. I do not, however, recommend attempting a smaller map, as that would render less effective our ongoing test about resource utilisation, which test ought not be affected by unrelated crashes.
There was about 10MB of physical memory free when it was crashing. There was plenty of free swap though.
You can see the memory situation of the server live in the link in first post of this thread...... Or Here (http://zeropoint.cc/simutrans/statpause.php).
I agree it is too soon to try a smaller map, but I need to get a script written to backup the saves and logs and re-start the server automatically because it seems to be seg-faulting more often now and I will not be watching it.
It's nearly finished - then we will be all set.
Shouldn't be too long,
:)
dM
<edit> ok. Here is the script if anyone is interested. seems to work so far.
I have it on a cron job every minute.
#!/bin/bash
# By deMangler for Simutrans Experimental Server, but will work for other stuff.
# As-is. No licence.
# Detects if server is not running and backs up log and save and restarts server.
# Backups are dated and numbered.
#
# **! Define these variables correctly - these are examples only !**
SERVER_LOCATION="/home/simutrans/simutrans-server/simutrans" #directory containing Server
WEBSTUFF_LOCATION="/home/simutrans/www" # location of status icon if any
BACKUP_LOCATION="$SERVER_LOCATION/bak" # directory to save backups of log and save
SERVER_PROCESS_NAME="simutrans-experimental-server" # command to run server
SERVER_PORT="13353" # port
SERVER_ARGS=" -log 1 -debug 2 -server $SERVER_PORT -nomidi -lang en" # Server Args
MAX_RESTARTS=20 # Maximum number of times to restart server and backup files.
#########################################################
if [ -e $SERVER_LOCATION/server-restart-blocked ]; then
# Script will do nothing if a file called server-restart-blocked is in server directory
exit # Naughty but nice. Oldskool.
fi
if pidof $SERVER_PROCESS_NAME > 0; then
#update forum notification icon
cp $WEBSTUFF_LOCATION/online.png $WEBSTUFF_LOCATION/teststatusico.png
else
mkdir -p $BACKUP_LOCATION
#update forum notification icon
cp $WEBSTUFF_LOCATION/offline.png $WEBSTUFF_LOCATION/teststatusico.png
DATE=$(date +%Y-%m-%d)
# Make sure that we are using a unique filename for this backup.
NUM=1
while [ -e $BACKUP_LOCATION/savebackup-srv-$SERVER_PORT-$DATE-$NUM.sve ]; do
NUM=$(($NUM + 1))
done
if [ $NUM -le $MAX_RESTARTS ]; then
cp $SERVER_LOCATION/server$SERVER_PORT-network.sve $BACKUP_LOCATION/savebackup-srv-$SERVER_PORT-$DATE-$NUM.sve
cp $SERVER_LOCATION/simu-server$SERVER_PORT.log $BACKUP_LOCATION/logbackup-srv-$SERVER_PORT-$DATE-$NUM.log
$SERVER_LOCATION/$SERVER_PROCESS_NAME$SERVER_ARGS
else
touch $SERVER_LOCATION/server-restart-blocked
# Could mail yourself an alert here or something
# echo "Hello. Server Crashed lots by the way. I give up. *Sigh*"
:
fi
fi
Shall be interested to see how that gets on. Have you looked into using the official Net Tool?
Sometimes the server hangs (or something) without crashing - at these times it still reports as on-line but it is impossible to log in. I have yet to find a way of detecting this automatically, so if this occurs please feel free to pm me and I will try to get it up and running again as soon as possible.
dM
Quote from: jamespetts on June 10, 2011, 10:20:57 AM
Shall be interested to see how that gets on. Have you looked into using the official Net Tool?
I had no idea about an official net tool. Forum search brings up nothing. What am I looking for? What does it do?
See here (http://forum.simutrans.com/index.php?topic=7050.msg69412#msg69412) for the nettool.
Some observations on balance and gameplay.
1. Time passes too quickly, I think: I logged in last night, and it was 1879 - now, it is 1886. An online game needs to be slower paced than a single player game, as people are not logged in all the time. There is much to be said for the suggestion that I made earlier that the game should auto-pause when nobody is logged in (and even more to be said for the enhanced version of that suggestion that there should be a sophisticated system for setting three types of times: always off, always on and on only when players are logged in. This should help to give a sufficiently slow but also sufficiently consistent set of timings. I wonder also whether there needs to be some adjustment to bits per month for online play. I should be interested in people's thoughts on that topic.
2. It seems far too easy to make a profit. I set up a single unsophisticated point to point railway line with two stations and one train in the 1840s. I was then busy at work and did not come back to the game until the 1860s. My line was so profitable that I had over twelve million in the bank. Having never expanded my network since then, I now have 34 million. The richest player has 286 million, which is more than enough by itself to build a comprehensive network covering the whole map many times over and run it at a loss for many decades. I need to check whether there are any bugs causing excessive revenue, but, assuming that there are not, some serious re-balancing is needed, including some of the things already planned for version 10.x.
Edit: I have found a bug in setting the scale factor in 9.8 which could quite easily cause excess revenue. This is now fixed in the 9.x branch.
Edit
3. Another thing that I note is that tunnels are far too easily built. That might be because the tunnels themselves are too cheap, or because profit margins are too high - but there are many tunnels in places that, in reality, would be quite uneconomic to put tunnels.
James, infrastructure cost for stations is turned off. This usually is a major cost factor.
Furthermore boats are way to cheap to operate. (Thanks to The Hood for the paddle steamers with their mail capacity. Would be a good idea for the Clyde steamer too.)
Long block still don't seem to work. EDIT: It might be the road crossings, that count as signals. I'll try to eliminate them and see if long-block signals work. (Check at Radingley in my game)
Server seems to be down - status page reports that the server is not running.
Edit: To respond to sdog - I have found the bug in relation to building maintenance costs, and it will be fixed in the next version. Thank you for reporting that. The boats will need to be dealt with when the pakset is balanced, but thank you for pointing that out. As to the long block signals - I think that there is a fix for that in the latest Standard code, which I have yet to merge because of the major changes with industry that will take much time to integrate.
Sorry about the server being down.
I accidentally uploaded a half-edited script to the server. :-[
Fixed now. (it seems....)
dM
The server will now no longer restart with the latest save.
Here is the console output.
Warning: waggon_t::set_convoi(): convoi 360 had a too high route index! (10 of max 9)
Warning: waggon_t::set_convoi(): convoi 438 had a too high route index! (9 of max 8)
Warning: waggon_t::set_convoi(): convoi 512 had a too high route index! (12 of max 11)
Warning: waggon_t::set_convoi(): convoi 518 had a too high route index! (25 of max 24)
Warning: waggon_t::set_convoi(): convoi 564 had a too high route index! (7 of max 6)
Warning: waggon_t::set_convoi(): convoi 572 had a too high route index! (25 of max 24)
Warning: waggon_t::set_convoi(): convoi 586 had a too high route index! (54 of max 53)
Warning: karte_t::laden(): loaded savegame from 4/1918, next month=556269568, ticks=0 (per month=1<<556267336)
Running world, pause=0, fast forward=0 ...
Warning: nwc_routesearch_t::rdwr: rdwr limits=(2016, 8064, 7104, 2517536, 1763168) apply_limits=0
Warning: karte_t::interactive: nwc_routesearch_t object created and sent to server: sync_step=0 map_counter=109070465 limits=(2016, 8064, 7104, 2517536, 1763168)
Warning: nwc_routesearch_t::execute: append client_id=0 limits=(2016, 8064, 7104, 2517536, 1763168)
Warning: nwc_routesearch_t::execute: min_limit_set updated: last_update_sync_step=1 accumulated_updates=1
Warning: convoi_t::go_alte_richtung(): convoy with wrong vehicle directions (id 586) found => fixing!
Warning: convoi_t::go_alte_richtung(): convoy with wrong vehicle directions (id 586) found => fixing!
Warning: nwc_routesearch_t::rdwr: rdwr limits=(2016, 8064, 7104, 2517536, 1763168) apply_limits=1
Warning: nwc_routesearch_t::check_for_transmission: transmit sync_step=18 map_counter=109070465 limits=(2016, 8064, 7104, 2517536, 1763168)
Warning: nwc_routesearch_t::execute: to be applied: limits=(2016, 8064, 7104, 2517536, 1763168)
Warning: nwc_routesearch_t::execute: add to world command queue (sync step: command=18 world=17)
Warning: nwc_routesearch_t::do_command: apply limits=(2016, 8064, 7104, 2517536, 1763168)
Floating point exception
I will take suggestions from the players whether to roll back to a previous save or start a new map.
Or something else.... :)
dM
let's ask james first if he wants to pack the latest bug fixes into a new version, to start a new map with. Correct infrastructure cost might be interesting for a new game.
This session has been quite successfull, in finding crashes and having quite a large number of convoys and routes, which the server took quite well.
the best setting for server_announce_intervall is intervall>0 every x month
if an email address has been specified on serverlist-website, a message is sent when the server no longer reports ( beta function, too little tested )
I have begun trying to get another server up and running using the binary provided by dustNbone here: http://forum.simutrans.com/index.php?topic=7507.msg71988#msg71988 (http://forum.simutrans.com/index.php?topic=7507.msg71988#msg71988)
It appears to be up so please test away!
dM
Might I suggest restarting and using 9.11?
Quote from: jamespetts on July 02, 2011, 12:00:50 AM
Might I suggest restarting and using 9.11?
Re-started using the same map and version 9.11.
I will update the server to the latest version as soon as I can generally, especially while heavy testing is underway, like now. It may not always be instantaneous although I will try to stay up-to-date..
DeMangler,
that is most helpful - thank you!
I wanted to play but when I connect, I dont have access to any players. Is it possible for me create or join a player?
figured that out, now how can i password it???
as well, are there any rules on sharing lines and connecting to other players' stations or towns?
in the company list dialogue click on the green square right of the name, this should bring you to a dialogue where you can change your name and password.
sharing networks works at the moment mostly by making stations public and leaving room for others to connect. remember without a workaround/exploit it's not possible to share rail or railroad stations. after making a station public, the rail stays private.
I am hoping to improve features for co-operation between players without the involvement of the public service player at some time, but I have a rather long list (http://forum.simutrans.com/index.php?topic=6813) of features to implement first.
in the meantime, if you are an online player and like such things to be implemented, check for the feature requests for standard there should be some suggestions there already. you can tell devs there is actually a demand for such features.
Some game time may have been lost for some players in the current game.
The server exhibited it's "I am up but no-one can log in" behavior, the only cure for which is to re-start it.
The game date at restart was 1946.
The most recent save to re-start with was June 1916.
Sorry about that.
dM
Hmm - we need to consider an annual auto-save, I think.
There is an autosave every time a player joins. Just start the player without any savegame given will load the gamestate of last player joining. (The savegame is under simutrans/server13353-network.sve if the port is 13353.)
The difficulty with this is that, if a player logs in, plays for many hours, then logs out, then the server crashes before any other player has logged in, those hours of playing will be lost.
Any autosave need to be done also on the player computer or the games would run out of sync. Thus most easily, if you there for hours without desync just leave and join.
how about also saving if the only player leaves?
Sdog's idea is a good one, actually - that should be fairly easy to implement. Might I suggest that this feature goes into Standard?
Dwachs net tool may have some features I can use to force a save.
I have yet to have the time to experiment with it.
I have wondered why there is not more passworded RPC type server admin available.
In any case - All in the progress of testing/developing.
I continue to be impressed by how well it runs on such a low spec server. Maybe I'll try an even bigger map next time if it deals with the timeline up to say 2000 ok on this size map.
dM
I'd be very interested indeed to see how it works on a larger map with a goodly number more cities.
I think it was me who killed it :) And it was around 1916 so I don't think much was lost. I also believe I was the only one active at the time, but not sure. Seems to be running great for the most part. Thanks DeMangler :)
Dustin
dustNbone,
may I ask - what did you do, or what happened just before it went?
I was just setting up a tram (near Gorpool Colliery) to replace a stop I removed from a local train. I think i might have crossed an active rail line with tram tracks, as the last popup I got was telling me that a train couldn't find a route. The game's been quite stable thus far though. Also, I can't seem to change my company name, but others seem to have done so, so it's me doing something wrong?
Dustin
EDIT: No worries, figured out how to change my name :)
Well, the server made it to 1942 this time before becoming impossible to connect to.
Thanks for everyone who played, there were some pretty good setups developing. Unfortunately I didn't have time to play myself.
I will start again with a new map and new version as soon as I can.
dM
Binaries for 9.12:
http://www.megaupload.com/?d=P65ISOZ3
I haven't tested the server at all but compile looked clean. Thanks for running the server. Did it crash to the point where it couldn't load the save again or is this just some kind of networking glitch?
Dustin
Quote from: dustNbone on July 11, 2011, 06:55:23 PM
Binaries for 9.12:
http://www.megaupload.com/?d=P65ISOZ3
I haven't tested the server at all but compile looked clean. Thanks for running the server. Did it crash to the point where it couldn't load the save again or is this just some kind of networking glitch?
Dustin
It does not exactly crash, it just seems to stop talking. The network otherwise is fine.
I suspect my limited ram is an issue. But that is just a gut feeling at the moment, that does not really fit the facts.
Thanks for the binaries - I have started a new server with a bigger map / more stuff.
dM
It could be, looks like you're running it on 256MB? I have run the server but not in a constrained environment like that, it seems to use about 85MB itself, so 256 would be tight but it should use up all it's swap space before it has any failures. Odd. Doesn't seem like anything really serious anyhow. I wonder how the bigger map will affect footprint in RAM, we'll see I guess.
Dustin
EDIT: The server seems to be very slow to respond now, basically unresponsive once a couple of people are playing. The stats page only indicates a small amount (14MB) of swap in use, but it may just be "over the line", and swapping constantly. Is the server running in a VM or actually on a machine with only 256MB? Swapping in a VM disk can be pretty slow, something to avoid in my experience. Better to let the host OS swap and allocate more memory to the VM. Anyways, that's how it seems to me.
Dustin
seems to be losing sync very often now even with just 1 player...or is it just me?
A VM is not very strong in CPU. YOu could set the server to a lower frame rate (liek -fps 8 or so).
The server doesn't use much CPU at all from my experience, and modern CPU virtualization is pretty efficient anyway. Anyways, that's off topic, the server is running on a 256MB machine, virtual or otherwise, and this is pretty tight for a linux system, even a non graphical one. The simutrans server itself uses around 90MB I think.
Quote from: prissi on July 12, 2011, 08:39:29 AM
A VM is not very strong in CPU. YOu could set the server to a lower frame rate (liek -fps 8 or so).
Thanks for the advice, I may try something like this if it gets bad.
When I was setting up the server first of all I did some stress tests for the RAM, CPU and network.
I think CPU is ok on this server - Even running a bitcoin deamon, simutrans server, and compiling something (can't remember what), CPU use barely registered.
The service I have is not the shared resources type - I get a minimum guaranteed amount of CPU - the minimum does not depend on other users.
It is 8 cores, so I don't know how good simutrans is at ustilising that, or how good the VM is at making it available, but I saw no sign that was likely to be an issue.
As I increase the map size I expect to reach a RAM ceiling. I don't think that I will be able to push it much more - even if the RAM is not what is causing problems now.
Anyway - it will be fun finding out.
dM
im losing synchronization with the server in 1 - 2 min after joining, non-stop, all the time. I think you may want to consider reducing the map size so we can get some answers.
I question if it could it be a network issue? where is the server located? im near toronto with a pretty good connection but thats still 100-150 ping to european servers.
What is syncing here exactly? and does it need to check for it so often???
The server is located in the UK.
I am in another part of the UK, with a ping of a pretty consistent 31ms. Bandwidth is not going to be a factor. I will try to pin down or eliminate anythingn else with the server that may be causing this - however the only things that have changed since last time is the binary and the map size/number of cities/number or industries, and some player activity possibly. So I reckon it is one of those, probably map size or configuration.
I have had no desynchs, although I do notice other clients disconnecting and reconnecting a lot. Much more often with this map than before.
I am using the windows binary.
I will leave it up for now until I know if James or anyone would benefit from testing anything out with the current setup.
Then I will try again with a smaller map, just to see if it is an improvement.
Meanwhile - I apologize if it is unplayable. I aim to have a playable server eventually.
dM
<edit>I just had my first desynch. Possibly the rarity of this in my case may be because I am not actually playing, by that I mean engaging in any activity that would require the player password to be input. Just 'observing' </edit>
Elthore,
desyncs can be caused, for some reason, by changing the names of lines/convoys (especially if you press "return" after doing so). Desyncs are caused in the case of Simutrans by the client and server diverging in their execution of the code, as the game runs in parallel on both the server and the client, and there are frequent checks to make sure that the two are doing the same thing.
Elthore - are you using 9.12 or 9.11? You might be able to connect with 9.11, but it will desync regularly, as the code execution will differ due to the implementation of some changes as between 9.11 and 9.12.
Not sure what if anything is different, but today the desync thing seems alot better, and responsiveness is way up. I was alone on the server so that might have something to do with it. Is it difficult or even possible to up the RAM on the virtual server? Looking at the numbers, I'm thinking even another 64MB would make a huge difference. You either have enough ram for these tasks or don't in my experience, and right now it seems that the bigger map has just nudged it over the edge, and there's alot of swapping going on. As for having 8 cores available, simutrans doesn't seem particularly threaded in itself, but having more cores at hand is useful on a shared environment where you're doing other things with the server, as well as having spare cores to offload networking and file system maintenance tasks to, for example. Seems to be working pretty good though, and the gradient handling in 9.12 is definetly an interesting change, and I'll say so far that it seems far more realistic than the old system.
My $.02
Dustin
Server stopped talking. Restarted with latest save (Dec 1844).
The server seems to have gone down whilst I was setting up a 'bus network in Radmouth.
That is crappy, as Radmouth needed such a bus network :(
Desyncs cannot be caused by renaming. However, the error wether games are in sync or not is done only at the execution of a command. Thus the sync will most likely happened beforehand. The renaming tool is totally unneded for the game state. It was just added to have the same name for every player.
To avoid desync when renaming, you can try to press ESC instead of ENTER. It works for some, like convoy and station renaming. But it doesnt work for some other, like label.
it was my stupid mistake, i didnt update to 9.12 :D
???
all better now ;D
Server seems to have croaked again some time last (North American) night. Weird problem, i can't seem to replicate it at all locally. I wonder if using cron or something to have the server save and restart at specific intervals or something would be useful.
Dustin
You can restart the server by cron every five minutes. If running, it will detect that the port is in use and terminate. Otherwise it will restart with the last transferred game. I used to do this, when I had my server.
Quote from: prissi on July 15, 2011, 03:15:19 PM
You can restart the server by cron every five minutes. If running, it will detect that the port is in use and terminate. Otherwise it will restart with the last transferred game. I used to do this, when I had my server.
I already do this with a cron job running every minute.
The problem is that the server does not 'crash' exactly, it just stops responding to clients. The server is still running.
The best I can think of is to use Dwachs nettool to detect if any clients are connected every half hour or so and if not then restart the server anyway. Just in case.
Or maybe if the server is in this state it will not respond to the tool, in which case detecting that will do the job.
When I have time I will set this up.
dM
That seems reasonable, if the nettool can detect connected clients then it's probably the way to go. If you need any help shell scripting I have a little experience there.
Dustin
We had the problem, when server went onto pause mode. Thus pausing was removed. But if the server does not get any error message when connection to a client is lost, I am not sure how to detect this.
this map is getting really super busy and complicated, i sense a crash coming on. Is there any way to save the map serverside to prepare for the inevitable?
Server saves the map everytime someone logs in AFAIK. Should be fine.
Dustin
Server has just gone down. Another client was constantly joining and leaving (possible desyncs?) whilst I was setting up a 'bus network in Radmouth. The game is therefore saved at a very recent juncture.
The server crashed again, I was shuffling about 12 trains from one line to another. Whenever Im adjusting lines, i get desynced. I think the crash happens when i'm accessing the schedule screen when i desync.
...I noticed that the train was stuck in route finding when i continued after desynch. After saving and loading this game, the train had resolved its route but i didnt check which line it was in. When I tried to change the next train's line, fatal error:
minivec_tpl<T>::[]
index out of bounds: 9 not
in 0..5
Server's up again, for now :)
Ahh, this looks like an instance of this (http://forum.simutrans.com/index.php?topic=7626.0) bug, which I have fixed on my 9.x Github branch.
Server is down again - were people changing schedules when it went?
I will be out of network coverage for two weeks between 22/07/11 - 08/08/11, because I will be camping.
During this time I will be unable to visit the forums or do much with the server.
It is possible I may be able to go on-line or ssh in with my phone but I am not relying on this because the place I am going is a bit remote.
After this I will be back able to maintain the server, and hopefully have some time to play as well...
dM
its gone down once more, this time with the same error as before.
a few days rest wouldn't be a bad idea, heh
....perhaps next game should be slower so everything isnt outdated between sessions.
Elthore's suggestion is sensible - covering many years in a day or two is not ideal. Perhaps for the next map we could experiment with a higher bits per month setting to see whether that works better for an online game?
And, Elthore, "the same error as before": is that relating to the error that you get when changing schedules?
Apologies to Dustnbone - I was playing as public service, trying to sort out the situation with the abandoned Radmouth Central Railway Station and allow its use for a local line to Thursand along the existing tracks, but, because it is not possible to hide railway bridges or rotate the map in network mode, I had difficulties, and ended up deleting one of your station tiles, hoping that it could be re-instated after I had converted Radmouth Central to a public stop - unfortunately, I cannot re-instate it for reasons that I do not understand, and moreover, your trains on that line can no longer find a route. I am sorry to have caused trouble; this aspect of the game (the awkwardness of elevated rail) needs to be considered very carefully, I think.
You might also want to extend your Westerly elevated rail line to Milton Library stop.
Server seems to be down again.
Edit: Or perhaps not...?
No worries about the SkyTrain, fixed and extended west, added another train. I agree with maybe slowing things down a tad, but not too much as things like changing rolling stock on a long line like some of mine can be very time consuming, I think maybe slowing things down to 2/3 or so of what they are now would be effective. Off topic a little, is the point to point passenger calc patch going to be a part of 9.13? I tested it a little and it seems to clear up this issue a great deal. I think a change like this is important for multiplayer, making competition for a smaller company more practical, as well as making larger networks with local/express services work closer to reality. I'm glad to see things moving as quickly as they are, the gradient handling in 9.12 is much better, albeit a bunch more challenging. I like it.
Dustin
Glad that things are working out. As I said in online chat (and am repeating here for the benefit of anyone who may be reading): the routing patch will have to be part of 10.0, as it changes the save game format. 9.13 will likely be a few bug fixes. The feature set for 10.0 is not yet finalised, so watch this space!
Seems to be down again as of a few seconds ago.
Edit: Hmm - and seems to be back. Odd.
Ahh that was me, noticed that it wasn't responding and restarted it. Will be nice when we're playing with the fancy new version which is seemingly free of this bug.
Dustin
Its been fun, but unfortunately i must call it quits for now due to the high number of desynchs. I think its caused by my latency to the server which is around 120-130ms ping. On the last map I could leave the computer connected for a while and would remain synchronized, now it seems even without any input that I lose synch. The netcode for simutrans seems not so capable of dealing with high latency clients.
Hope my piles of rails and local city junk don't get in the way too much
and yes, it was again the same error as in the post you linked. I think its possible to assign that vehicle to a different line and put a new one on the problem line as a work-around to the crash?? forgot what i did... but you got it patched ! nice!
Elthore,
sorry that you are having trouble with synchronisation. Where in the world are you located, may I ask? I know that it can be very difficult playing networked Simutrans with a very slow client; the latency issue is not one with which I am so familiar.
let's see if the network here in the public library is stable enough to have a look on the server... :-)
Im in Toronto with a cable connection to the net. Was connecting through a slightly slower DSL connection with a **** router earlier this week and there were definitely more desynchs.
A good test would be for me to connect to some north american servers and see how it is there. I'll get to it sometime and report back.
Well, looks like we killed it. Date was October 2020. I managed to get on to do a local save before it stopped restarting and the savegame crashes my client as well, with the same errors that are in the server log. Here it is:
Simutrans version 110.6 Experimental 9.12 from Jul 11 2011
Warning: nwc_routesearch_t::reset: all static variables are reset
ERROR: obj_reader_t::read_file(): reading 'skin/ground.Outside.pak' failed!
Please report all errors to
team@64.simutrans.com
ERROR: obj_reader_t::load(): ground.Outside.pak not found, cannot guess tile size! (driving on left will not work!)
Please report all errors to
team@64.simutrans.com
ERROR: is_unicode_file(): file is UTF-8 but has no paragraph
Please report all errors to
team@64.simutrans.com
Warning: werkzeug_t::read_menu(): toolbar[10][5]: replaced way-builder(id=14) with default param=cityroad by cityroad builder(id=36)
Warning: karte_t::laden: Fileversion: 110006
Warning: waggon_t::set_convoi(): convoi 163 had a too high route index! (7 of max 6)
Warning: waggon_t::set_convoi(): convoi 166 had a too high route index! (8 of max 7)
Warning: waggon_t::set_convoi(): convoi 217 had a too high route index! (12 of max 11)
Warning: waggon_t::set_convoi(): convoi 227 had a too high route index! (7 of max 6)
Warning: waggon_t::set_convoi(): convoi 244 had a too high route index! (148 of max 147)
Warning: waggon_t::set_convoi(): convoi 298 had a too high route index! (7 of max 6)
Warning: waggon_t::set_convoi(): convoi 299 had a too high route index! (10 of max 9)
Warning: waggon_t::set_convoi(): convoi 302 had a too high route index! (9 of max 8)
Warning: waggon_t::set_convoi(): convoi 304 had a too high route index! (6 of max 5)
Warning: waggon_t::set_convoi(): convoi 307 had a too high route index! (10 of max 9)
Warning: waggon_t::set_convoi(): convoi 312 had a too high route index! (8 of max 7)
Warning: waggon_t::set_convoi(): convoi 358 had a too high route index! (9 of max 8)
Warning: waggon_t::set_convoi(): convoi 361 had a too high route index! (7 of max 6)
Warning: waggon_t::set_convoi(): convoi 379 had a too high route index! (8 of max 7)
Warning: waggon_t::set_convoi(): convoi 387 had a too high route index! (10 of max 9)
Warning: waggon_t::set_convoi(): convoi 421 had a too high route index! (27 of max 26)
Warning: waggon_t::set_convoi(): convoi 440 had a too high route index! (8 of max 7)
Warning: waggon_t::set_convoi(): convoi 444 had a too high route index! (26 of max 25)
Warning: waggon_t::set_convoi(): convoi 445 had a too high route index! (26 of max 25)
Warning: waggon_t::set_convoi(): convoi 450 had a too high route index! (8 of max 7)
Warning: waggon_t::set_convoi(): convoi 452 had a too high route index! (9 of max 8)
Warning: waggon_t::set_convoi(): convoi 454 had a too high route index! (8 of max 7)
Warning: waggon_t::set_convoi(): convoi 571 had a too high route index! (101 of max 100)
Warning: waggon_t::set_convoi(): convoi 573 had a too high route index! (13 of max 12)
Warning: waggon_t::set_convoi(): convoi 575 had a too high route index! (170 of max 169)
Warning: waggon_t::set_convoi(): convoi 636 had a too high route index! (170 of max 169)
Warning: waggon_t::set_convoi(): convoi 642 had a too high route index! (288 of max 287)
Warning: waggon_t::set_convoi(): convoi 692 had a too high route index! (85 of max 84)
Warning: convoi_t::laden_abschliessen(): convoi ((724) BR Class 20) is broken => realign
Warning: convoi_t::laden_abschliessen(): cnv 724 is currently too long.
Warning: convoi_t::laden_abschliessen(): convoi ((727) BR Class 20) is broken => realign
Warning: convoi_t::laden_abschliessen(): cnv 727 is currently too long.
Warning: waggon_t::set_convoi(): convoi 795 had a too high route index! (17 of max 16)
Warning: waggon_t::set_convoi(): convoi 797 had a too high route index! (20 of max 19)
Warning: waggon_t::set_convoi(): convoi 800 had a too high route index! (30 of max 29)
Warning: convoi_t::laden_abschliessen(): convoi ((810) BR Class 90) is broken => realign
Warning: convoi_t::laden_abschliessen(): cnv 810 is currently too long.
Warning: waggon_t::set_convoi(): convoi 881 had a too high route index! (174 of max 173)
Warning: waggon_t::set_convoi(): convoi 884 had a too high route index! (46 of max 45)
Warning: waggon_t::set_convoi(): convoi 892 had a too high route index! (43 of max 42)
Warning: convoi_t::laden_abschliessen(): convoi ((897) BR Class 180 "Adelante") is broken => realign
Warning: convoi_t::laden_abschliessen(): cnv 897 is currently too long.
Warning: waggon_t::set_convoi(): convoi 928 had a too high route index! (208 of max 207)
Warning: convoi_t::laden_abschliessen(): convoi ((946) SWT Class 444 "Desiro" EMU) is broken => realign
Warning: convoi_t::laden_abschliessen(): cnv 946 is currently too long.
Warning: waggon_t::set_convoi(): convoi 970 had a too high route index! (152 of max 151)
Warning: karte_t::laden(): loaded savegame from 9/2020, next month=1201143808, ticks=0 (per month=1<<1200963214)
Warning: nwc_routesearch_t::rdwr: rdwr limits=(1408, 14976, 13120, 2061504, 743308) apply_limits=0
Warning: karte_t::interactive: nwc_routesearch_t object created and sent to server: sync_step=0 map_counter=521884 limits=(1408, 14976, 13120, 2061504, 743308)
Warning: nwc_routesearch_t::execute: append client_id=0 limits=(1408, 14976, 13120, 2061504, 743308)
Warning: nwc_routesearch_t::execute: min_limit_set updated: last_update_sync_step=1 accumulated_updates=1
Warning: nwc_routesearch_t::rdwr: rdwr limits=(1408, 14976, 13120, 2061504, 743308) apply_limits=1
Warning: nwc_routesearch_t::check_for_transmission: transmit sync_step=18 map_counter=521884 limits=(1408, 14976, 13120, 2061504, 743308)
Warning: nwc_routesearch_t::execute: to be applied: limits=(1408, 14976, 13120, 2061504, 743308)
Warning: nwc_routesearch_t::execute: add to world command queue (sync step: command=18 world=18)
Warning: nwc_routesearch_t::do_command: apply limits=(1408, 14976, 13120, 2061504, 743308)
Anyways, it was a good game, noticed that it got quite hard to be profitable later in the game as passengers wanted more speed, and weren't willing to pay as much if they didn't get it. A while before it croaked, I built a bit of a maglev line from Steeplehampton, through Radmouth and Huntford to Middleborough and it seemed set to make some money. Also, once we got a larger number of convoys and stops going (over 1000 convoys I think, at least close) the delay at month end became quite long and both my client and the server were pegging near full CPU usage (on one core). Seems to get quite intensive, I wonder how threadable some of that work is. Anyways, that's what happened, seems to be unfixable at the moment, also tried the newest master branch build that I had around (July 21 Build) and same result.
Dustin
Dustin,
this is rather odd as it is claiming that it cannot find ground.Outside.pak, which suggests that something has gone rather generally wrong with the server, not necessarily a specific problem with Simutrans-Experimental. Can you upload the saved game as it was at 2020? That would be helpful for me in having a real game with which to test, as I am hoping to release a new version in a week or two and should like to test the impact of the changes on memory consumption.
I uploaded the savegame to http://www.megaupload.com/?d=IGU5Y2O6
I noticed in the logs that missing outside.pak seems to be common to all the logs on the server, at least through the last game played. Logs are available at http://zeropoint.cc/simutrans/logs/ Thanks for your interest, I'm rather late for work so I guess I should go there now. Thanks again James.
Dustin
I have found the cause of the crash - it was a bug relating to the closing down of industries which I have now fixed in my 9.x branch.
Edit: Also, the slow-downs at the end of the month seem to be related to industries. 9.12 has a known bug (fixed in the 9.x branch) causing far too many industries to be built - you will see this looking at the "serverkiller" map: the number of industries is really very large indeed. It is this, not the routing, that is causing the difficulty.
Yeah I did notice the industry thing, at one point we were down to 2 industries, and then it was over 1,000. I wrote it on a postit note and stuck it on my monitor, then forgot :) The savegame seems to load good now but I guess continuing the game would mean everyone including the server needs new binaries. I can make them up for Linux if we go that way but we might just as well wait for the new release. Quick work on the bug squishing :)
Dustin