Issues with PLAYER mode in multiplayer

[mihahauke]

https://groups.google.com/forum/#!topic/vizdoom/4NWF_xRKYfs

[glample]

Hey, any update on this?

We noticed that the more players in the game, the slower it is. When we make a match between 2 agents (+1 if we count the host), in SYNC mode we are able to play 10x faster than real time. But when 4 agents join, it's only 2x faster, and when 6 agents are in, it becomes slower than real time (and then it's just better to use ASYNC).

Could it be a problem with the communication between vizdoom processes?

[mwydmuch]

Hello,
sorry, I didn't have time to look into that. Eventually I will test SYNC mode extensively and will look for bugs, but I suspect that what you experience is correct behavior... Main focus of SYNC mode is to assure deterministic processing, so in SYNC every game waits for message from other games (Doom's multiplayer is p2p) that they also processed same number of tics and send their actions to everyone, then next tic is processed and waiting process repeats. So with large number of players with different processing time and different skip in worst case scenario processing X tics will take time that is sum of individual processing time of X agents.

Thank you for your feedback

[wjaskowski]

In SYNC mode the agents are asked for their actions sequentially, one by one, right? So the solution would be to ask them for the next action in parallel. Would that be possible?

…

-- Wojciech Jaśkowski, Ph.D. Laboratory of Intelligent Decision Support Systems Institute of Computing Science Poznan University of Technology, Poland http://www.cs.put.poznan.pl/wjaskowski

On 26 July 2017 at 10:21, Marek Wydmuch ***@***.***> wrote: Hello, sorry, I didn't have time to look into that. Eventually I will test SYNC mode extensively and will look for bugs, but I suspect that what you experience is correct behavior... Main focus of SYNC mode is to assure deterministic processing, so in SYNC every game waits for message from other games (Doom's multiplayer is p2p) that they also processed same number of tics and send their actions to everyone, then next tic is processed and waiting process repeats. So with large number of players with different processing time and different skip in worst case scenario processing X tics will take time that is sum of individual processing time of X agents. Thank you for your feedback — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#228 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEuSHQgzNCg2TUPrSyGcgT328tNJqF-Rks5sRvcggaJpZM4OgbFR> .

[mwydmuch]

There is parallelism, for example if two agents get next state in the same tic, then they can process it in parallel, but other agents who have already declared their actions (for example one tic ago with some skip) have to wait for them. So simply SYNC mode has 35 synchronization points per second. And right now waiting is active cause doom's multiplayer "api" can only send and check if there are new packages (or maybe I'm missing something + I was to lazy to touch os dependent code), so this probably generates some overheat.

[glample]

Wouldn't it be more efficient to have each agent communicating its actions to the host only, and let the host inform every agent about the other agent actions?
But still, there must be something else responsible for the speed. I would imagine communication at a localhost level should be fast enough to not be the bottleneck.

[mihahauke]

@glample Yes, that would be nice to have client-server, but in 1993 they hadn't figured it out yet for multiplayer fps.

[wjaskowski]

On 28 Jul 2017 03:16, "Marek Wydmuch" <[email protected]> wrote: There is parallelism, for example if two agents get next state in the same tic, then they can process it in parallel, but other agents who have already declared their actions (for example one tic ago with some skip) have to wait for them. This would mean that regardless of the number of players the performance should be roughly the same (as long as you have enough CPU cores)... simply SYNC mode has 35 synchronization points per second. If this is sync mode why do we still impose any constant number of sync points per second? (35)? right now waiting is active, cause doom's multiplayer "api" can only send and check if there are new packages (or maybe I'm missing something + I was to lazy to touch os dependent code), so this probably generates some overheat. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#228 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEuSHW5bI7pCiSqQoqeomR9quoK6cPdWks5sSTZ1gaJpZM4OgbFR> .

[mwydmuch]

@wjaskowski: I put it badly - I mean that there are 35 sync points per in-game second. Simply, there is sync point before every logic tic.

@glample, @ebonyclock: I think in this case (speed is priority, local network, only one thread per game) p2p approach is better (faster) solution. And as @ebonyclock said, original Doom supports only p2p, but in ZDoom sever-client multiplayer is also implemented ('-netmode 1' argument) and it's seems to be slower option (yes, right now it can be also used with sync mode).

I've introduce little patch that should boost performance for "large" number of players like 8 or 16, my little experiments indicate this, but @glample: Could you check this patch out?
And I will continue to work on this.

[glample]

Thank you. I prefer not to reinstall ViZDoom right now because I have some models currently running, but I'll try just after the deadline and keep you updated.

[mwydmuch]

Old issue that was partially solved, closing.