lag Reduce Lag

[JuKu96]

Is there a plan to reduce lag in future version of 0 A.D.?
In my opinion lag has increased in last 3 version of 0 A.D. .

[Lion.Kanzen]

They are working in that.

https://code.wildfiregames.com/D956

[elexis]

Depends on what kind of lag youre talking about. Simulation lag not really. Network lag is a thing you have to discuss with your ISP. Less FPS can be a result of the FPS limiter which was implemented add the new models with more polygons, new maps with more actors.

There was the multi-selection patch and the visual aura thing which might have had an impact on the FPS when selecting hundreds of units. I didn't really notice a difference.

[JuKu96]

I mean network lag. Since alpha 18 or alpha 19 (my first version was alpha 16 / 17) game is lagging more and more.

My ping is surround about 55ms:

 

I think the IPS isnt the problem, the network engine (by design) of 0 A.D. is the problem, i think.

There are many data sended betwenn all clients.

Execuse me for my english, i am from Germany and my english isnt the best!

 

In newest version the game lags (often) in early game, in earlier versions of 0 A.D. the game lagged, if any, in late game (caused by too much units).

But currently it also lags in if you start the game (~15 units / player). So many players leaved 0 A.D.

 

In my opinion there are 3 solutions for this problem:

1. introduce seperate lobbies for different continents

It isn't an good idea, if an player from america plays with people in europe. Its also nice, but this causes more lag, because the route is very large. It will be an better idea, if americas plays with other americans and europe players with other players from europe. So we will prevent some lag and less bandwidth. Other games (like League of Legends or World of Warcraft) does also seperate regions to reduce lag.

 

2. 0 A.D. is hosting games itself

I think this option isnt possible, because of its financial price.

 

3. Redesign Architecture of Network Engine of 0 A.D.

Think about an new architecture of network engine, which will reduce neccessary bandwidth and uses more prediction. Also dont send all units and synchronize all units between all clients. Server is chief and sends only neccessary data to clients. So not every client is simulating every game anymore, server is only the big simulator and clients do only prediction.

This can maybe increase cheating, its possible, i think. But it will also reduce lagging in many times, because bandwidth usage is lesser.

Edited October 19, 2017 by JuKu96

[Dade]

I don't have such a problems, but maybe the experience differs from a connection to another.

1. Whenever we get the numbers of League or WoW we should do that for sure if we don't want to get crazy on lobby hah
2. Will be the same, but on the other hands I think devs are working on a standalone dedicated server executable
3. Won't this solution add bandwidth usage? Clients still need to be synchronized in order to play the game properly (I am not an RTS expert though)

[JuKu96]

@Dade  Thanks for your answer!

 

1. Yes, but maybe also yet to reduce lag.

 

2. A standalone dedicated server executable sounds nice!

 

3. No it dont will add bandwidth usage. Currently every 5 or 10 ticks all units are synchronized to detect OOS. But if server is chief there cannot be an out-off-sync anymore, so detection is redundant and traffic can be reduced.

Edited October 23, 2017 by JuKu96

[elexis]

A dedicated server won't really help with network lag, nor with clientside simulation or graphics bottlenecks. The feature was mostly needed when only few people could host. It would also play a role if Wildfire Games would host rated games - but then the wfg would also have to simulat the games and not only proxy the commands, as the clients could otherwise claim to not have lost without disconnecting, evading the rating reduction again.

[Dade]

@JuKu96  you can see the dedicated server feature being developed on trac.

[elexis]

being?

[JuKu96]

On 23.10.2017 at 10:11 PM, Dade said:

@JuKu96  you can see the dedicated server feature being developed on trac.

thanks!
But whats the state of this development? Is this dedicated server already under construction or doesnt develop anyone anymore on it?

[Stan`]

@JuKu96 the person just above you was working on it. He doesn't anymore, because that doesn't make much sense since STUN has been implemented. It wouldn't make the game any faster any way.

[JuKu96]

Ah! thanks for this information!
But i think an dedicated server is also an nice feature - independent from STUN.

In Germany most routers doesnt supports STUN by default.

[elexis]

Because it only allows someone to host who can already host, it defacto is a toy feature unless we rent a new server and host games ourselves.

Readers of the ticket might also notice that prior to implementing a dedicated server, it would also be required that players can setup the game (as currently the first player to join the server is considered the controller of the gamesetup, yet the first player can leave the session without closing the server.)

[av93]

There's some way for playing a game, that if the original hoster leave, allows you to continue to play? It would be very difficult to implement?

Edited October 28, 2017 by av93

[Stan`]

Would be a nice and quite unique feature.

[elexis]

If the game is hosted by a Wildfire Games server, then every player could leave.

Alternatively host migration, but that is also turning the code upside down I believe.

While we're requesting improvements to the networking code to reduce the lag, we really need #3700. :-/

[Stan`]

Too bad @andy5995 had to give up on this...

Edited October 28, 2017 by stanislas69

[elexis]

The last word wasn't spoken there and the patch will be needed sooner rather than later. I was just fed up with running in the review hamster wheel for more than a year without getting to code something on my own. Luckily the NetClient code isn't really coded at and if, is easy to rebase, so it should be considered postponed. (Also had some joys trying create a custom ScriptInterface for XmppClient, but I aborted because it only segfaulted )

[Lion.Kanzen]

On ‎17‎/‎10‎/‎2017 at 1:10 PM, JuKu96 said:

Is there a plan to reduce lag in future version of 0 A.D.?
In my opinion lag has increased in last 3 version of 0 A.D. .

In my opinion nope. and depends some things like maps.

[JuKu96]

12 hours ago, elexis said:

While we're requesting improvements to the networking code to reduce the lag, we really need #3700. :-/

Currently the net client isnt running in an seperate thread?

This means 0 A.D. is only single threaded?

 

12 hours ago, stanislas69 said:

Too bad @andy5995 had to give up on this...

Why? What do you mean?

 

11 hours ago, elexis said:

The last word wasn't spoken there and the patch will be needed sooner rather than later. I was just fed up with running in the review hamster wheel for more than a year without getting to code something on my own. Luckily the NetClient code isn't really coded at and if, is easy to rebase, so it should be considered postponed. (Also had some joys trying create a custom ScriptInterface for XmppClient, but I aborted because it only segfaulted )

If you want i can also help to make this single threaded game an little bit more multithreading. I have an little bit of experience in that.

But the engine isn't documentated really well (for me), so its very difficult to get started into 0 A.D. development.

[Stan`]

@JuKu96 It's not really single threaded. But some of the big stuff AI, Pathfinder and NetClient are running in the same thread.

Well life caught him back and he now has other priorities than to work on the best RTS to date.

@JuKu96 You could try starting off were Andy left the patch. See what he did analyse and then fix it and port it to code.wildfiregames.com. that would lift the task from elexis shoulders. As someone who has been here for 6 years trust me the hardest part is not contributing. It's starting to code. Once you breach that barrier things start to get easier. I didn't even know I could do big patches or C++ before then. About documentation. we are improving it slowly by enforcing jsdoc and doxygen.

Edited October 29, 2017 by stanislas69

[elexis]

Wasn't the AI is in a separate thread? At least it has its own ScriptInterface and can't interact with the simulation, thus has to copy half the gamestate around frequently.

The NetServer is running in a separate thread (which sometimes leads to funny situations like the host losing the connection to his own server while the others can observe and chat about that).

3 hours ago, stanislas69 said:

Well life caught him back and he now has other priorities than to work on the best RTS to date.

(Mostly because I didn't spent further time on trying to figure out why and where it segfaults.)

4 hours ago, JuKu96 said:

This means 0 A.D. is only single threaded?

As Stan said, the entire simulation and the entire renderer are in the same thread. These two should be split and the pathfinder should run in a separate thread ideally. Needs considerable rewriting though (the current pathfinder approach is to compute paths consecutively afaik).

4 hours ago, JuKu96 said:

If you want i can also help to make this single threaded game an little bit more multithreading. I have an little bit of experience in that.

The NetClient issue itself shouldn't be too hard to solve. One only needs to modify that one file to work the same wa as the NetServer (pushing things into a queue from the main thread, then letting the NetClient thread pull things from that queue and process the data just like before). andy created the queues already, so it just needs some testing and figuring out as to why this segfaults somewhere (probably some scriptinterface registration thing).

[leper]

No, the AI was designed to be threaded, however apart from the infrastructure for that being there nothing was done (somewhat to make debugging easier, somewhat because nobody got to that).

[wraitii]

Quote

As Stan said, the entire simulation and the entire renderer are in the same thread. These two should be split and the pathfinder should run in a separate thread ideally. Needs considerable rewriting though (the current pathfinder approach is to compute paths consecutively afaik).

Not that much actually pathfinder was designed to handle paths concurrently but that requires some changes. https://code.wildfiregames.com/D14 worked, but I needed to copy data for the short-range pathfinder too iirc.

[JuKu96]

thanks for all this answers!

Really interesting!

 

On 29.10.2017 at 12:02 PM, stanislas69 said:

@JuKu96 It's not really single threaded. But some of the big stuff AI, Pathfinder and NetClient are running in the same thread.

Well life caught him back and he now has other priorities than to work on the best RTS to date.

@JuKu96 You could try starting off were Andy left the patch. See what he did analyse and then fix it and port it to code.wildfiregames.com. that would lift the task from elexis shoulders. As someone who has been here for 6 years trust me the hardest part is not contributing. It's starting to code. Once you breach that barrier things start to get easier. I didn't even know I could do big patches or C++ before then. About documentation. we are improving it slowly by enforcing jsdoc and doxygen.

 

thanks! Where can i found his patch? I have seen you have migrated to Github? Or is current code already in SVN?

I will try this. The only problem is, that my c++ skills are currently an little bit rusty. But i think i can do it.

Do you use an networking library or does 0 A.D. use normal C++ networking?

And yes, the hardest part in 0 A.D. is to start coding...

 

On 29.10.2017 at 3:42 PM, elexis said:

Wasn't the AI is in a separate thread? At least it has its own ScriptInterface and can't interact with the simulation, thus has to copy half the gamestate around frequently.

The NetServer is running in a separate thread (which sometimes leads to funny situations like the host losing the connection to his own server while the others can observe and chat about that).

The NetClient issue itself shouldn't be too hard to solve. One only needs to modify that one file to work the same wa as the NetServer (pushing things into a queue from the main thread, then letting the NetClient thread pull things from that queue and process the data just like before). andy created the queues already, so it just needs some testing and figuring out as to why this segfaults somewhere (probably some scriptinterface registration thing).

 

"which sometimes leads to funny situations like the host losing the connection to his own server while the others can observe and chat about that"
I have also observed such situations. But why? If net server is only in another thread of same process, their isnt any connection between host and main client, or am i wrong?

I will look into code...

Edited October 30, 2017 by JuKu96