Thread: Ping and Lag

Back in the day, if you had a ping of around 200 there was a good chance that you also experienced some lag. So a person with a ping around 200 is more likely to lag than someone at 34 or so. Often, this results in meaningful differences in performance ("skill") where the lower ping will get the "hit" before the person with the higher ping.

However, it seems to me that the correlation between ping and latency isn't as great in BF3. Am I wrong in this observation? Has something changed with the relationship between ping and lag? Have I misunderstood something in all of this?

How can FPS help?

I ask because I think I know, but there are folks much more knowledgeable about this on our forums that may help me understand the relationship better. I'd rather understand than continue to operate on only a piece of the entire picture.

It would be awful kind if someone could help an old dog better understand these three measurements, how they relate, and to what extent current technology has changed (if at all) their relationship.


Thank you!

Ping IS latency... or rather it's a very good indicator of latency. A 200 ping to a game server means your data arrives at the server 200-X milliseconds after your computer sends it. (X is usually roughly equal to half the ping rate). The actual number you receive from a ping is the round trip time. So you can equate it to playing ping pong. You hit the ball, and record the time it takes before the ball returns to you. In IRC (I know... old school) you would actually send a /ping and get a /pong in return.

So how can you have a 200 ping and play games if everything you are doing is at least 100ms behind what someone else is doing? Better yet, how can you, sending data 100ms behind, play with someone else who's also RECEIVING data from the server 100ms behind? All things being equal, two players with a 200ms ping to a server are going to be at least 2 tenths of a second out of sync. In board games, or turn based games that's nothing. But in an FPS where twich style gameplay is the norm, that can be an eternity.

The answer is extrapolation and interpolation. There's two types of this. Client side and server side. If its handled by the client, the client gets things like direction traveled and speed of a player and attempts to "guess" at what's going to be happening 100ms in the future. So if you fire and it hits the player based on that guess then it reports to the server that the other player is hit. However, these guesses aren't always perfect. So when you see someone "warp" in a game... guess what? Your client guessed wrong. The server sent new info and corrected the client's view of what was happening resulting in a small "glitch in the matrix" so-to-speak. Interpolation works a little differently and is based on two points where the object WILL move to that point. So there's no real guesswork. However if packets arrive out of order (which happens with UDP) or the interpolation buffer overflows with too much info then the client has no option but to "freeze" an object on screen until things can catch up. So when you see something FREEZE on screen... it's interpolation. Freezing = interpolation. Warping = extrapolation. The problem with interpolation is that it makes the rendering take longer. Which means that even on super-fast connections you still need some form of lag compensation regardless of how low your latency. The downside of client side compensation is that it's easier to hack if the server allows the client to do "soft changes" to the world state. Depending on how much the server allows, high amounts of fake data can be introduced into the stream such as headshots that might otherwise be near misses or body shots.


If the server side is implementing compensation, then that means more work for the server, and means that you can get serious stuttering or other issues. There are many types of server side compensation that can be implemented too. Time rewind is popular. Basically the server retains server-state awareness for a specific amount of time. So if a player's latency to the server is 100ms, the server will look at where the server-state was 100ms ago and react as if the player's action happened THEN instead of NOW. What happens in that case though is that players will think they are getting hit when they shouldn't be. So you could be running and taking fire and dive behind cover, only to still die because the other player was firing at where you were 100ms ago where you would see that you are under cover. This has the impression of hitboxes being laggy. It can also result in two players shooting at each other and killing each other when in "real time" only one would have died.

So... since all of this is "code"... If a game has better lag compensation than another game... It may appear that lag or latency doesn't affect it as much. Also, specific tricks can be taken to make it SEEM like lag compensation is better than it is. So... Mileage may vary is very much in effect, but BF3 may have awesome lag compensation code.

And that... is latency/lag compensation in a nutshell.

BF3 deals with bad pings better than previous games. It's the Frostbite engine in general because BC2 was the same way. We regularly had people connecting with 200ms ping and they were no harder/easier to kill than someone with a 10ms ping.

Thank you, that made sense and was helpful!

My recollection was that with BF2 a ping of 200 was bad news but doesn't seem to be the same issue with BF3. Understanding that the server & code can account for this make sense now and would seem to explain what I have seen in game.

Originally Posted by Amador +JP2+

It would be awful kind if someone could help an old dog better understand these three measurements, how they relate, and to what extent current technology has changed (if at all) their relationship.

One of the major differences between now and when multi-player FPS was coming to it's own (mid-late 90s) is the accessibility of broadband connectivity. Today the majority of connectivity latency you see is caused by route efficiency and distance between client and host. In the days where dial-up was more of a norm you had many players who experienced latency due to very low bandwidth. Their connections could not receive and/or deliver the payload at a rate needed of the environment. With a healthy broadband connection you may have an arrival time of 250ms but you are still receiving/delivering packets in single digit millisecond intervals. More data points means a smoother and more accurate environment (compensation/interp perform their jobs well). Fewer data points results in less accuracy and ultimately more 'lag'.

Kanati did well at explaining how interpolation/extrapolation though I don't think it was described very well (in fact sounds like Kanati just spewed out the wikipedia on this).

Extrapolation tends to be done by both client and server. The server does this as a form of latency compensation in an effort to provide the most accurate predicted state for the client receiving it. The client utilizes extrapolation as a fallback for gaps in communication.

The best example I can provide here is how games often behave when you lose connectivity. The players may continue to move in a strait line -- this is client extrapolation. Players may treadmill, client interpolation. Or they do both (interp falling back to an extrap)

Interpolation is mostly aesthetic. The client ensures the smoothest possible transition between positions. Without it the players will constantly stutter as the client catches up or falls back. You still observe it today as rubber-banding and is typically the result of packet-loss, server choke, or client rendering problems.

And that is where client resource utilization / FPS comes into play. Poor FPS is typically impacted by one of two things. Graphics rendering capacity of your GPU or processor utilization. GPU rendering is the most common, but only relates to how the user can react/interact with their game. 125 FPS (8ms) as baseline floor for FPS is where most users will observe few to no issues interacting with the game. Yes most of us can still see the difference between 125 and higher FPS but it does not hinder our observational cues and ability to react (unless you have some sort of physiological disorder).

The second common issue is with processor utilization (much more prevalent in the past). This is very different from GPU related problems. With a crappy frame-rate caused by the GPU you can still use your own brain's interpolation and will observe everything running at a normal pace. But once you start hindering your processor everything lags. At this point you begin to observe compounding latency. You see things slower, your actions are registered more slowly, and generally high action gaming becomes impossible.



When it comes to BF3, I cannot say. But I know from my experience in BF2 that latency was always much less of an issue than it is in more close quarter high pace games, such as Source.

Some pretty advanced answers in this topic
In a perfect gaming world, everyone would connect and play with nearly the same latency. However, in real world gaming (that just sounds wrong), you'll hear people bitching that "I shot him first! Why'd I die!". This is partly due to compensation.

I've been on and we've had people with over 250+ latency. Get a few of them on, and yeah, we've had weird issues. Rubberbanding increases and so on. What's interesting is that it seems to handle one or two OK but if you start increasing the number of people with high latency, it seems to start struggling to deal with it.