News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

bridgewater-brunel.me.uk - Simutrans-Experimental - Pak128.Britain-Ex 0.9.1

Started by jamespetts, January 26, 2014, 01:35:08 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

jamespetts

Quote from: TurfIt on March 09, 2014, 03:30:46 AM
Please try the attached patch. It appears to keep clients from falling way behind, and more smoothly adjusts the timing. Assuming neither server nor client is overloaded of course (which the actual server shows signs of at the moment - please check server log for 'server lagging by' messages after applying patch).

I am having a spot of bother merging this into the 112.5-merge branch, which is based on the latest Standard nightlies, as opposed to the 11.x branch, which is based on an older stable version of Simutrans-Standard. It seems that there are some significant architectural differences beyond changing the name of "umgebung_t" to "env_t". Any assistance in how this might best be merged into the latest version would be most welcome.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

TurfIt

Standard has for some bizarre reason split the interactive into several functions (each called once - what's the point...). But the code should still be the same (excepting the renaming), just moved around. I was planning to add it to standard once we see how well it works here.

And if you want a true spot of bother, try an execute in past desync on a server. Yup, my server desynced from itself! Something rather weird with that nwc_routesearch thingy...

prissi

Standard server has never ever (to my knowledge) been hitting a performance issue, even on virtual servers. Although way search certainly (especially with many ships and large maps) may  take longer than on a fast client.

By the way, you patch may create performance issues by printing a warning each step if diff is negative. Make this better a dbg->message (or change the text, if this really occurs rarely.)

ӔO

Setting the additional frames behind server from 4 to 9 seems to help connection stability quite a bit.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

wlindley

Since at least the start of the new game, all I can get is "Loading game... loading new map... [and then instantly] lost synchronization with server."  Most frustrating!

jamespetts

Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

TurfIt

Quote from: prissi on March 10, 2014, 12:11:30 PM
Standard server has never ever (to my knowledge) been hitting a performance issue, even on virtual servers. Although way search certainly (especially with many ships and large maps) may  take longer than on a fast client.
Standard is certainly susceptible to the same client timing issues. Experimental just does a good job making them a problem... Large maps, 4000 ships, and the extra load compared with standard.


Quote from: prissi on March 10, 2014, 12:11:30 PM
By the way, you patch may create performance issues by printing a warning each step if diff is negative. Make this better a dbg->message (or change the text, if this really occurs rarely.)
Which warning would be creating an issue?
Clients already print 2 warnings for every check command, and the 3rd relevant message containing the actual time diff was moved to a warning from a message to keep them together (also -debug 3 is all but useless with all the crap being spewed).
The added server lag message should be monitored IMHO. Otherwise servers run with no indication of overload. I doubt logging a single line every step would affect performance in any noticeable way. Ideally it'd occur never with a fast enough server for the game, but could be a message instead of warning (at risk of being buried though), or be changed to???

prissi

I just suggest to change the first dbg->warning in the patch to a dbg->message. There are two more debug level (5) which can print out timing informations on each frame. One might consider to change those client messages to those.

About the lagging warning for the server: I agree with you.

Sarlock

Getting more and more of these as the server gets slowly loaded up more:

Message: network_command_t::rdwr: read packet_id=9, client_id=0
Warning: network_check_activity(): received cmd id=9 nwc_check_t from socket[488]
Warning: NWC_CHECK: time difference to server -1909
Message: network_command_t::rdwr: read packet_id=8, client_id=0
Warning: nwc_tool_t::rdwr: rdwr id=8 client=2 plnr=3 pos=5686,519,-8 wkzid=8216 defpar=l,4325,743 init=1 flags=0
Warning: network_check_activity(): received cmd id=8 nwc_tool_t from socket[488]
Message: nwc_tool_t::pre_execute: append sync_step=456301 wkz=8216 init
Warning: network_world_command_t::execute: wanted to execute(8) in the past
Warning: karte_t::network_disconnect(): Lost synchronisation with server. Random flags: 0


Can additional frames be set beyond 9?  Going from 4 to 9, would the next step be 14 or 16? (+5 or squares)
Current projects: Pak128 Trees, blender graphics

TurfIt

You can set it to anything you want. Keeping total in multiple of 5 (for the specific other settings on this server, 6+4, 6+9, 6+14, etc.) helps the smoothness when running steady, but I just connected to take a look and wow, that is one horrid stutter. It's only running at 9-10 fps rather than the 12 set - server is not keeping up. So, there won't be much help keeping it to 5's.
Note you'd need to be 2 seconds behind, or 24 frames to have avoided that desync.


Quote from: prissi on March 10, 2014, 10:33:05 PM
I just suggest to change the first dbg->warning in the patch to a dbg->message. There are two more debug level (5) which can print out timing informations on each frame. One might consider to change those client messages to those.
Maybe you've misread the patch? It's not printing every frame, but every time a NWC_CHECK message is received. And receipt of that message (and indeed every command from the server) already triggers 2 warning messages. Likely all the network messages should be changed from level 2 to 3?

jamespetts

Quote from: TurfIt on March 11, 2014, 01:20:53 AM
You can set it to anything you want. Keeping total in multiple of 5 (for the specific other settings on this server, 6+4, 6+9, 6+14, etc.) helps the smoothness when running steady, but I just connected to take a look and wow, that is one horrid stutter. It's only running at 9-10 fps rather than the 12 set - server is not keeping up. So, there won't be much help keeping it to 5's.

Note that I have reverted to 4 on your advice, so multiples of 4 would be better here. Would there be any benefit to de-reverting to 5 again?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

TurfIt

What did you revert? If you set server_frames_per_step back to 4, that would explain the current apparent server overload. I'd suggest keeping that 5, and even dropping fps to 10 until all those ships go away... Are you getting the 'server lagging by' warnings in the log?
If you set server_frames_ahead back to 4 from 6, then everyone should just add the 2 back onto their additional_client_frames_behind settings.
The need to keep (frames_ahead + frames_behind) % frames_per_step == 0 should go away after my next trial patch which spreads the step() load out across the frames...

ӔO

If anyone is wondering what crashed the server, it's because I raised land and a ship ran aground.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

I did indeed set the server_frames_per_step back to 4 - do you think that I should change it to 5 again?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

TurfIt

Is the server not horribly lagging? I thinks it needs all the help you can gives.

jamespetts

Quote from: TurfIt on March 09, 2014, 10:31:28 PM
Standard has for some bizarre reason split the interactive into several functions (each called once - what's the point...). But the code should still be the same (excepting the renaming), just moved around. I was planning to add it to standard once we see how well it works here.

Hmm - I have tried twice and given up trying to merge this myself with the latest code. The method void karte_t::process_network_commands(sint32 *ms_difference) does not have frame_timediff or time_to_next defined in scope, so, in order to merge this, I should have to understand the intention of the code, which is well beyond my capability at the present. I shall have to wait for it to be merged with Standard, I think, and incorporate the merged version from that in order to incorporate it into the 112.5-merge branch.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

ӔO

the server is quite laggy right now with nearly 4700 convoys running. I can't stay connected for more than 5mins at a time.

While running a local copy, my CPU and RAM are at its limits. 2.4Ghz going full tilt and more than 1500mb RAM usage.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

VOLVO

Quote from: ӔO on March 16, 2014, 03:46:24 AM
the server is quite laggy right now with nearly 4700 convoys running. I can't stay connected for more than 5mins at a time.

While running a local copy, my CPU and RAM are at its limits. 2.4Ghz going full tilt and more than 1500mb RAM usage.
It takes me around 17.8% of CPU, but 1.2 GB of memory is needed to run it offline.. Also, fast-forward is not possible.

jamespetts

Hmm - too many ships (caused by too much demand for intercontinental freight traffic) and too much city growth I suspect is responsible. These things will have to be tamed for future versions.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Sarlock

I'm still able to get 6-8x fast forward on a local copy.  This is on a fast (4.4GHz) computer, however.

I've increased frames to 14 and this has helped a bit but I still can't remain online more than 10 minutes at most.  If there is anyone else on the server at the same time, disconnects are far more likely.  For the most part I am avoiding a login if someone else is already connected, and waiting for a time when no one is on.

I am gone for 10 days and won't be able to log in during this time (highly unlikely the hotel wireless will be stable enough to connect-if it even allows the port(s)).  We're only progressing at a rate of 1 year/day, so I should be fine while I am gone.

For the next map, I'd strongly suggest about half the size and more square.  It will probably require 5 times less convoys (or more) to connect the map together.  The 6000+ tile cross-map journeys require dozens of convoys to effectively service each line.  Significantly taming city growth will help as well.  Already there are huge areas that have become one big continuous urban zone.  When faster ships become available in a few decades, it will only make things worse as many more passengers will be willing to take longer journies.
Current projects: Pak128 Trees, blender graphics

AP

Quote from: Sarlock on March 16, 2014, 04:45:44 PMWhen faster ships become available in a few decades, it will only make things worse as many more passengers will be willing to take longer journies.
I rather hope some of them will be travelling by rail ;-)

jamespetts

Quote from: Sarlock on March 16, 2014, 04:45:44 PM
I'm still able to get 6-8x fast forward on a local copy.  This is on a fast (4.4GHz) computer, however.

I've increased frames to 14 and this has helped a bit but I still can't remain online more than 10 minutes at most.  If there is anyone else on the server at the same time, disconnects are far more likely.  For the most part I am avoiding a login if someone else is already connected, and waiting for a time when no one is on.

I am gone for 10 days and won't be able to log in during this time (highly unlikely the hotel wireless will be stable enough to connect-if it even allows the port(s)).  We're only progressing at a rate of 1 year/day, so I should be fine while I am gone.

For the next map, I'd strongly suggest about half the size and more square.  It will probably require 5 times less convoys (or more) to connect the map together.  The 6000+ tile cross-map journeys require dozens of convoys to effectively service each line.  Significantly taming city growth will help as well.  Already there are huge areas that have become one big continuous urban zone.  When faster ships become available in a few decades, it will only make things worse as many more passengers will be willing to take longer journies.

Reducing the size is a measure of last resort, I think. The next major release has a more efficient search algorithm for ships, which should help somewhat. It will be important to reduce the length of connexions between industries, as it is the humorously anachronistic intercontinental milk trade that is driving much of the ship activity that is causing such a slow-down. Certainly, reducing town growth will have an impact, too, especially as the number of industries is linked to the population size.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Sarlock

Quote from: jamespetts on March 16, 2014, 06:29:25 PM
as it is the humorously anachronistic intercontinental milk trade that is driving much of the ship activity that is causing such a slow-down. Certainly, reducing town growth will have an impact, too, especially as the number of industries is linked to the population size.

Agreed on both counts... and had a good laugh at your chosen wording for the absurd milk trade that is reaping 50% of the overall profits.  It is certainly excessive but also accounts for a relatively small percentage of cross-ocean traffic.  My cross-ocean routes currently include passengers, mail, milk, coal, grain, textiles, planks, beer, iron, hardware and wrought iron.  And of course milk earns more profits than the rest combined.  :)  Even with a more efficient ship routing system and slower population growth, the server might still be eventually bogged down as the years progress on such a map.  Reducing to 5000x2000 might make the game a lot more playable in later years.


Quote
I rather hope some of them will be travelling by rail

AP, did you verify that you can indeed run rails under the deepest ocean sections?  I had tried and wasn't able to go underneath the two deepest levels of the ocean.  If you know of a secret way, please share  ;)
Current projects: Pak128 Trees, blender graphics

jamespetts

Reducing the size closes of all possibility of very long routes; I should prefer just to have fewer towns. Indeed, the current map seems a little overcrowded of towns in some areas.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

ӔO

Quote from: Sarlock on March 17, 2014, 08:16:10 AM
AP, did you verify that you can indeed run rails under the deepest ocean sections?  I had tried and wasn't able to go underneath the two deepest levels of the ocean.  If you know of a secret way, please share  ;)

You should be able to lower track in shallow water, so do all the lowering there.

---

Since true capacity is "capacity & speed", the later years requires fewer convoys than what is used now from speed alone.
Add to that motorization and pax convoys are further reduced.
The reduced travelling times counteracts the motorization to an extent, but since freight and mail are not affected by motorization, the net effect is fewer convoys being used.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

AP

Quote from: ӔO on March 17, 2014, 09:23:13 AM
Quote from: Sarlock on March 17, 2014, 08:16:10 AM
AP, did you verify that you can indeed run rails under the deepest ocean sections?  I had tried and wasn't able to go underneath the two deepest levels of the ocean.  If you know of a secret way, please share  ;)
You should be able to lower track in shallow water, so do all the lowering there.
Correct. :D I did and it works. Just be careful not to cluster your gradients too close together or the locomotives will struggle. Looking forward to dual-heights :) .


Quote from: jamespetts on March 17, 2014, 08:36:18 AM
Reducing the size closes of all possibility of very long routes; I should prefer just to have fewer towns. Indeed, the current map seems a little overcrowded of towns in some areas.

I think partly the trouble is that this is a water map. If it were a land map, for a map of this size there would a lot more space. So the same number of towns could be much further apart.

I still think we're substantially short of industry for the population. Most large towns have one shop... which is presumably because nobody has any money due to chronic unemployment!

And of course, the city growth factor... :o

Quote from: Sarlock on March 17, 2014, 08:16:10 AM
Agreed on both counts... and had a good laugh at your chosen wording for the absurd milk trade that is reaping 50% of the overall profits.  It is certainly excessive but also accounts for a relatively small percentage of cross-ocean traffic.
Milk is the only one of my routes which reliably reports a profit, which is both because of this and because I used more small ships rather than few large ships when setting it up (reduces the peaks and troughs). Long routes and infrequent (but lucrative) arrivals seem to confuse the in-game accounting!

Milk routes only account for a handful of my ships also, there isn't the demand for any more.

I've found Bulk Goods to generate a reliable (and realistic) profit if you can make them work full both ways. The lack of industry is an issue here, because there are so few matching industry pairs (e.g. coal out, stone back). You can't haul the same cargo both ways unless you're very careful because of industry interlinking. The grain and wool bulk cargos seem to be more troublesome than coal/stone/clay.

Sarlock

Quote
I think partly the trouble is that this is a water map. If it were a land map, for a map of this size there would a lot more space. So the same number of towns could be much further apart.

Absolutely agreed.  The vast majority of the centre of the map is just a few islands and water.  We could easily remove 2000 tiles from this area by moving the islands around a bit and shrinking the size of the large sections of open ocean.  It would still be the same map effectively, just a bit shorter across the middle.


Quote
I've found Bulk Goods to generate a reliable (and realistic) profit if you can make them work full both ways. The lack of industry is an issue here, because there are so few matching industry pairs (e.g. coal out, stone back). You can't haul the same cargo both ways unless you're very careful because of industry interlinking. The grain and wool bulk cargos seem to be more troublesome than coal/stone/clay

I ran a test with this map in a local version and I had set up large freight collection yards for the two main islands and ran a series of mixed-hold ships back and forth.  Then I had feeder connections deliver all material to and from these collection yards.  This made things considerably more efficient as ships were travelling both ways with a significant load, and since freight isn't that sensitive to delivery times, it worked fairly well.  For pax delivery, however, it was more effective to directly connect the destinations.


Quote
Since true capacity is "capacity & speed", the later years requires fewer convoys than what is used now from speed alone.
Add to that motorization and pax convoys are further reduced.

There is also the 2 hour loading time for the East Indiaman which slows things down considerably as well.  With faster loading times, less convoys are required.
Current projects: Pak128 Trees, blender graphics

VOLVO

I suspect it will only get worse in the next century or so.. People will start doing railways and they are slow and unprofitable, which means more freight lines have to be connected to fund the railways. Slow moving trains doesn't help either. I would say the size of the map did exceed the limit of the program.

At the moment the server is keen to "instant synchronise"..
But less city(both number an growth) and industry will probably help, but it's still doubtfully enough.

AP

Quote from: VOLVO on March 17, 2014, 07:56:23 PMPeople will start doing railways and they are slow and unprofitable, which means more freight lines have to be connected to fund the railways

Are they still unprofitable?  :-[ I remember them being a total pain in the last online map, really difficult to make money, but was hoping that had been fixed.

As for slow, they are at least faster than sailing ships and post bikes  ;)

jamespetts

The issue raised about the number of towns and the size of the ocean is an interesting one. What really drives computational and memory load is transport infrastructure, and what, in turn, drives that are towns and industries. We could afford to have a larger map with larger land areas (and therefore the potential for longer journeys) if we had the same number of towns with much slower growth, and possibly even more industries, although care would have to be taken not to have too large an area of land based wilderness, which is not very realistic for the UK.

(Forgive the code box - this prevents a misinterpretation of my symbols as BBCode.

Perhaps, in a future map, have an equivalent of the Scottish highlands in the [i]middle[/i] of the map. In the following diagrams, take [L] to be lowlands, [H] to be highlands, [I] to be small islands and [S] to be sea. Something like this might work:

[L][L][L][H][H][H][L][L]

Or possibly

[L][H][H][H][L][L][L][L][L]

Or even

[L][L][L][H][H][L][L][L][L][/s][/i]
[code]
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

ӔO

Quote from: VOLVO on March 17, 2014, 07:56:23 PM
At the moment the server is keen to "instant synchronise"..
But less city(both number an growth) and industry will probably help, but it's still doubtfully enough.

go into the main config directory and open up simuconf.tab with notepad or a similar word editing program.
In simuconf.tab, change "additional_client_frames_behind" to 19, this should help reduce desync considerably.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

TurfIt

The computation problem at the moment is due to ships stacking at docks, and the 'hold' concept that was added to the pak. 35% of the CPU time is currently being spent loading convois, and 38% moving them around. The normal CPU hogs of vehicle pathfinding and pax/goods routing are at 20% and 3%.

Ships have the problem of infinite stacking which results in the loading calculations being performed on more convois than would fit into a station otherwise. This is exacerbated by the 'holds' that were added multiplying the number of vehicles to be checked greatly. A snapshot from yesterday shows 4610 convois comprised of 28520 vehicles, and 10% of them loading at any one time.

Stacking and/or 'holds' need to go if you want to run 4000+ ships around...

Sarlock

A highlands style map would certainly be interesting.  We'd end up criss-crossing it with canals in short order and likely run in to the same situation as we have currently with thousands of convoys zipping around.  It might be lessened, however, if the map isn't as wide and the distance between most industry connections on the island isn't as great as those that we encounter in the current game.  The wider the map, the more convoys are required for each industry and pax/mail connection.

Interesting results, TurfIt: I didn't realize that each ship hold was treated as a separate vehicle.  That certainly adds significantly to the load on the system.  It could be worth considering making a distinct East Indiaman and brig for pax/mail transport (600 pax, 1000 mail/150 pax, 250 mail) to reduce the number of vehicles used for this purpose by a factor of 8.  I probably have 1500+ pax/mail convoys serving the eastern island and my stations are still filling up with demand so fast that I can barely keep up... and so I am faced with the tough choice between continuing to bog down the system with exponential convoy growth or leave it be and suffer the consequences of having hundreds of thousands of unhappy passengers.
Current projects: Pak128 Trees, blender graphics

ӔO

changing the max pieces from 8 to 4 also offers a theoretical 50% decrease.

The very small barges and horse carriages could also be combined into one convoy.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

The ultimate thing that will, on any map of any type, drive computational effort is transport infrastructure, and the thing that sustains that is urban population and industry. The size and style of the map determine play style: the density determines computational load.

TurfIt - thank you for the interesting analysis apropos the number of vehicles loading at any one time. I wonder whether there is a means of reducing the computational load in respect of vehicles which are loading for a very long time? Edit - and it would also be interesting to know which specific functions are the ones that are shown in your analyses to generate the most load.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.