Sign in to follow this  

How to estimate latency in one direction only

This topic is 1115 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

Hi, I'm working on a realtime multiplayer game.

I want to do movement prediction to compensate for network latency.

 

In order to do that, I need to know how much latency there is between players.

 

For instance, player 1 sends a message to player 2. How much time did it take for the message to be transmitted?

Player 2 could send back a response to player 1, and player 1 could know an approximation of the latency by

taking the total time and dividing by 2. That could be a good approximation or maybe not. If it takes more time

in one direction compared to the other, then that approximation is not good enough.

 

Are there other more accurate ways to estimate latency between players?

Thank you.

 

edit:

The game I'm working on is peer-to-peer, and some movement predictions will be accurate because some movements will follow a predefined sequence.

My game is a fighting game. Example of "easy-to-predict" movements: parabolic jump, throwing fireballs, special moves. That's why movement prediction will work well in some cases.

Edited by Abrahman McGuyenski

Share this post


Link to post
Share on other sites
Why do you think you need uni-directional latency? Did you measure any actual problems with using bi-direction latency measurements, or are you just hypothesizing without any proof?

Just take half the average RTT.

Measuring uni-directional latency will otherwise require you to sychronize clocks. And periodically resynchronize them. There are protocols for this. Unsurprisingly, they rely on techniques like taking half the average RTT to estimate latency when doing the synchronization. smile.png

Share this post


Link to post
Share on other sites

I don't know yet. If there are simple ways to get unidirectional latency, I will use it because it's closer to what I need.

Maybe half bi-direction latency will be acceptable if uni-directional latency measurement is too complex.

Edited by Abrahman McGuyenski

Share this post


Link to post
Share on other sites


If there are simple ways to get unidirectional latency, I will use it because it's closer to what I need.

 

Simply, there are not.

 

There are complex methods to get it. There are expensive methods to get it.  For example, you could synchronize two atomic clocks and move them to the different locations and use those to compare the difference each direction, including accounting for dilation of time as you moved the clocks from one place to another.  Or you could determine the exact distances of fiber cable and distances of copper cable and the exact devices in the middle, then run though some complex equations.

 

 

Far easier is to just find the round trip and divide by two. This is close enough for most things.

Share this post


Link to post
Share on other sites
Short of shipping a precise GPS-based time source with each copy of your game, there's no good way to get one-way latency :-)

Note that what matters is that all players see the same events in the same sequence/order -- not the exact time at which they see the events. You need a monotonic clock for your simulation, but the clocks don't actually need to be exactly in sync, and trying to make them in sync is hard, and gives no extra value.

Share this post


Link to post
Share on other sites

Note that what matters is that all players see the same events in the same sequence/order -- not the exact time at which they see the events. You need a monotonic clock for your simulation, but the clocks don't actually need to be exactly in sync, and trying to make them in sync is hard, and gives no extra value.

 

It depends on what sort of game you're making and what exactly you're trying to do with it.  Motion prediction and other anti-lag features for fast-motion real-time gaming (which Abraham did say he was trying to do) do very much require knowing precise timestamps to do properly.  Just knowing the order of events usually does not work well for this at all.

 

As for the original question, however, do note that for these sorts of calculations, it seems at first like you would want to know one-way latency, but really when you do the math it all comes down to round-trip-time for almost all of it anyway.  The important point is not whether the client screen exactly matches the server's state at a given absolute time, but that the server's idea of when user input happens matches up with the same server state as what the the screen showed when the user made the action.  If you predict-forward just based on the one-way latency, then the client screen will (theoretically) match up with the server state (to some impartial third-party), but when the user does an action, you still have the latency to send the action back to the server, and when the server receives it, its state will be different than what the user thought it was based on the screen image when they pressed the button, etc.

 

So you actually would want to predict a full round-trip-time ahead, so that what the user sees on the screen matches (as best it can) what the server state will be when their action finally makes it back to the server.

 

Also note, however, that the further you try to predict ahead, the more error you will inevitably have in your prediction, which is why a lot of networked games attempt to handle this other ways (or do it only partially this way, with other compensating measures as well).  As just one example, you might want to take a look at the "Lag Compensation" section of https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking to see how the Source engine does it (which is basically to have the server look into the past instead of trying to have the client predict the future), etc..

Share this post


Link to post
Share on other sites

It depends on what sort of game you're making and what exactly you're trying to do with it. Motion prediction and other anti-lag features for fast-motion real-time gaming (which Abraham did say he was trying to do) do very much require knowing precise timestamps to do properly.


Yes -- you need high resolution in time stamps. The highest resolution for most fixed-step engines is the physics step/tick count. Some engines (like Unreal) use variable step size, which is bad for physics stability, and also makes ticks happen at different times on different clients, so those engines need high-resolution time stamps in fractional seconds instead. I much recommend fixed tick size!

Trying to get the wall-clock-time to be the same for the same simulation-step-time for all players at the same time, adds no value, and requires expensive hardware. Not to mention that "same time" literally becomes relative at a global scale -- speed of light becomes a factor even in defining what "same time" means! Who's reference frame? All the lag compensation techniques are basically just ways to deal with this, although the real-observed delay is an order of magnitude higher than the speed-of-light best case.

Share this post


Link to post
Share on other sites

The game I'm working on is peer-to-peer, and some movement predictions will be accurate because some movements will follow a predefined sequence.

My game is a fighting game. Example of "easy-to-predict" movements: parabolic jump, throwing fireballs, special moves. That's why movement prediction will work well in some cases.

Share this post


Link to post
Share on other sites

If you can get roughly the latency both ways, couldn't you then assume that the connection is asymetrical and using the average download/upload ratio for most ISP's calculate the latency due to distance alone and then calculate the distance between the client and server?

With this power, one could take over the world!

 

Although this could be used to tell your players about their real upload and download bandwidth. You could also gather stats about your players's network connections this way and make adjustments to your game.

Edited by Gl2eenDl2agon

Share this post


Link to post
Share on other sites

This topic is 1115 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this