• Advertisement
Sign in to follow this  

Incompressible time

This topic is 2347 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How much time takes your data to make a round-trip ? (this is not a duplicate of http://www.gamedev.n...nably-expected/ )

I'm just making the math and on my game i've got at max:

Client
16ms : main loop
30ms : network loop
0ms : my actual latency

Server
30ms : server loop

Client
0ms : my latency
30ms : network loop
16ms : main loop

So it takes 122ms maximum to make a round-trip from event to displaying it on the screen. Let's split that in 61ms and that's for me (how can it be faster for others!?) basic latency on a local network without counting cpu time.

Am I understanding right ? To me this is incompressible time but something sounds really wrong and i don't know what it is.

Share this post


Link to post
Share on other sites
Advertisement
So your round trip times are 0.1 seconds? whats the problem? If you want to move faster, consider using the IO subsystem better - look into overlapped io and so on. Also consider the data you are sending, and how you might delta-compress it.

Share this post


Link to post
Share on other sites
My "problem" was more to check if what i just said was valid and also how people use to deal with it. Is it common to use overlapped io ? How quake handle this ?

Also i was deliberately avoiding the delta-compression since i'd like to focus on "raw" latencies before going higher.

Share this post


Link to post
Share on other sites

How much time takes your data to make a round-trip ? (this is not a duplicate of http://www.gamedev.n...nably-expected/ )




Suppose you run both server and client at the same step rate (say 16 ms to be nice and even).

The player enters some command during (wallclock) step X.

Now, if you send commands immediately, rather than queuing up at the end of the step, then that may make it to the server in time for step X+1.

If the command is executed on the server as soon as the next step is started, and results are sent back to you, then that may make it back to you in time for step X+2.

Thus, the minimum round-trip time for a step-based game with immediate packet send and fast execution, the minimum latency is two steps -- one step each way, for a total of 32 ms.

If you queue input one step for execution the next step, both from player and to network, then it will look more like:

Player input during step X
Travel to server during step X+1
Execute on server during step X+2
Travel to client during step X+3
Result back during step X+4.

So, in this case (which is more realistic), your minimum latency is 64 milliseconds.

Once the travel time from client to server goes above 16 ms, your latency will increase by two steps at a time -- if travel time is 17 ms each way, a message sent at step X will be available at step X+2 because of quantization.

Also, this is assuming the systems are 100% in sync. They may not be, and be off by half a step one way or the other, and thus the quanta each way might be 8ms / 24ms / 40ms etc.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement