Official Everybody Edits Forums

Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?

You are not logged in.

Advertisement

Hello, visitor! These forums are run off of the revenue generated from these ads. If you'd like to support us, please whitelist us or consider donating:

#1 2017-03-17 20:45:30

Tomahawk
Forum Mod
From: BiH
Joined: 2015-02-18
Posts: 1,966

Stress-testing with 0 delay

One benefit of the removal of the block limit is the ability to place blocks quickly without any being missed. This removes the need for block-checking in a BAL, and permits many BAL features which were previously too unstable to be playable.

A more interesting benefit of this is the ability to place blocks with minimum or zero delay between them. Naturally, you reach the question "At what point do you or the bot start to DC when placing with 0 delay?"

I ran a stress-test in an empty ultra-wide world (636 x 50) with the following code:

The following code places a line of blocks with 0 delay whenever a grey basic block is placed. The number of blocks placed instantly is controlled by the variable STRESS_TEST.

case "b":
    if (m.GetInt(3) == 9)
    {
        for (int x = 0; x < STRESS_TEST; x++)
        {
            con.Send("b", 0, m.GetInt(1) + 2 + x, m.GetInt(2), 32);
        }
    }
    break;

For each value of STRESS_TEST (the number of block placed with no delay), 50 repeats were done. STRESS_TEST was increased by 1 and the process was repeated.

Results:
At STRESS_TEST = 202 I disconnected on the 25th repeat. I began the repeats again and the bot DCed on repeat 30. During the third set of repeats I DCed on repeat 41. At this point I got bored and wrote this thread.

Conclusions:
Pretty much no reliable general conclusions can be drawn from this test regarding the stability of an EE world, of the bot's connection to the world, or of the owner's connection to the world. The maximum rate at which blocks can be sent will vary entirely on the player, and other players in the world will probably begin to DC before you reach your own block-sending limit.

However, given that previously only 5 to 10 blocks could be placed with 0 delay before the bot DCed, BALs can now be created with greater animation fluidity and "framerate". For instance, each frame in the animation of a moving 3x3 square can be drawn instantly (i.e. all 9 blocks placed at once with no delay between them), and the overall effect is a lot more effective. Likewise, a platform or small area of blocks can be drawn instantly without any players disconnecting.

TL;DR: it's good.


One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.

Offline

#2 2017-03-17 22:16:58

LukeM
Dev Team
From: England
Joined: 2016-06-03
Posts: 2,757
Website

Re: Stress-testing with 0 delay

I performed a similar test but with speed, just thought I would post my results here:

I managed to get to 2000 blocks per second without disconecting, I tested this by placing a 50x50 square of blocks, but will test it with more later just to check that there isnt just a longer delay at these lower speeds

Ill post my code here in a bit, but im on a different computer, so dont have it atm

Offline

#3 2017-03-17 22:20:28

hummerz5
Member
From: wait I'm not a secret mod huh
Joined: 2015-08-10
Posts: 5,795

Re: Stress-testing with 0 delay

btw are we considering the whole threading aspect? I mean, how hogging the message handler thread locks things up and causes disconnect? perhaps that's an assumed "not a problem" but I feel like I haven't seen someone mention it so I would be that guy

otherwise, cool findings folks

Offline

#4 2017-03-17 22:33:18

LukeM
Dev Team
From: England
Joined: 2016-06-03
Posts: 2,757
Website

Re: Stress-testing with 0 delay

hummerz5 wrote:

btw are we considering the whole threading aspect? I mean, how hogging the message handler thread locks things up and causes disconnect? perhaps that's an assumed "not a problem" but I feel like I haven't seen someone mention it so I would be that guy

otherwise, cool findings folks

All of my tests have had the loop inside another thread, so I dont think this is a problem for me, although there could be internal locks inside PlayerIO that would prevent you from recieving messages I guess...
I guess this might be (probably is) a problem with most other peoples tests though... Ill try to redo some other peoples tests to see if this is the case

Ive tested it at above 2000 blocks per second though, and other players also started disconnecting at that point, so you do still disconnect when trying to place lots of blocks with little to no delay

Last edited by LukeM (2017-03-17 22:34:18)

Offline

#5 2017-03-17 22:58:46

Tomahawk
Forum Mod
From: BiH
Joined: 2015-02-18
Posts: 1,966

Re: Stress-testing with 0 delay

hummerz5 wrote:

btw are we considering the whole threading aspect? I mean, how hogging the message handler thread locks things up and causes disconnect?

Well, the code I used takes a few milliseconds at most to send off 200 blocks, so I don't think it's significant when there's no delay.


One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.

Offline

#6 2017-03-18 01:58:07

XxAtillaxX
Member
From: Canada
Joined: 2015-11-28
Posts: 3,942

Re: Stress-testing with 0 delay

I've heard that OpenPlayerIO has had better success at maintaining a connection compared to PlayerIOClient. I haven't bothered making any comparison myself, though.


atill.gif

Offline

XxAtillaxX1489798687651341

Board footer

Powered by FluxBB

[ Started around 1558430715.9529 - Generated in 0.031 seconds, 12 queries executed - Memory usage: 1.32 MiB (Peak: 1.44 MiB) ]