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.
Pages: 1
Topic closed
When blocks are sent to EE every t milliseconds, the server responds in about t milliseconds, therefore blocks can be theoretically sent every t/2 milliseconds, since the server doesn't require that the client recieve the block messages before sending them again (i.e round trip time.) However, this can be tricky as you don't know if all of your blocks are being sent, and sometimes t varies.
However, at some point, if t is too small the blocks will not appear, and will have to be resent. Resending costs time, but choosing something too large will ensure that 100% of the blocks are written, but will take too much time. For example, sending blocks every 50ms will have a success rate of 99%, therefore sending them at 100ms for 99.99% success is wasteful since resending that one block will only take 50ms, and sending all of them at 100ms would be too slow.
A loss function describes how increasing the block sending rate will reduce the amount of successful blocks. Here's an example: you send 100 blocks at 50ms, there's a 99% success rate, and one block has to be resent at 50ms cost, so you spend 5000ms + 50ms sending blocks. What if sending blocks at 25ms, there's a 50% success rate? So, you would spend 2500ms sending 100 blocks, but you'd need to send 50 more, so add on 1250ms, then 25 more, and so on... Here, resending the blocks is actually slightly faster.
Let b = number of blocks you need to send, r = loss function coefficient, tanh is the loss function. r has to be determined experimentally. If you minimize t (i.e how many blocks can be sent per second) such that the expression is also minimized, you can find out how quickly you can send blocks to maximize efficiency. I realize that you can add extra accounts to your world, but that's no fun. Usually the loss function doesn't perfectly model your internet, so there might be a few quirks.
Offline
If a bot was a proper Bayesian agent, it would never assign 100% probability to the possibility that it had achieved its goal of sending all of the blocks without missing any, and would therefore continue to send ad infinitum.
There must be a point (i.e. where the probability = 99.98%) where it stops sending blocks, so it could be better to calculate an acceptable probability for given values of t and b.
- An even more fussy Bayesian agent would never assign full probability to the possibility of reaching that 99.98% probability, and so we get nowhere. ^^
One bot to rule them all, one bot to find them. One bot to bring them all... and with this cliché blind them.
Offline
It would require you to use several different IP addresses.
There is a function that is called on GotMessage() in Everybody Edit's server code, that effectively rate limits packets.
Also, each PlayerIOClient instance has a queue for sending messages - which means even slower speeds.
*u stinky*
Offline
I just did some tests today, and for some reason I can send 850 blocks, 1ms each, and have 0% loss (i.e all of the blocks are sent.) When looking at the world as it is updating, it looks like I'm only getting a block every 13ms. Is EE doing some rate-limiting in the background?
Offline
I just did some tests today, and for some reason I can send 850 blocks, 1ms each, and have 0% loss (i.e all of the blocks are sent.) When looking at the world as it is updating, it looks like I'm only getting a block every 13ms. Is EE doing some rate-limiting in the background?
You clearly hadn't read my post directly above yours.
*u stinky*
Offline
Hexagon wrote:I just did some tests today, and for some reason I can send 850 blocks, 1ms each, and have 0% loss (i.e all of the blocks are sent.) When looking at the world as it is updating, it looks like I'm only getting a block every 13ms. Is EE doing some rate-limiting in the background?
You clearly hadn't read my post directly above yours.
Sorry, I thought that you meant that the queue was client-side and the rate limiting dropped packets to comply with the rate.
In that case, this equation is somewhat irrelevant.
Offline
Locked on request
aka towwl
Offline
Pages: 1
Topic closed
[ Started around 1732073280.3452 - Generated in 0.053 seconds, 12 queries executed - Memory usage: 1.5 MiB (Peak: 1.65 MiB) ]