Network latency

 “The time has come”, the Walrus said, “to talk of networking“…

The network game programmer has three mortal enemies:

  • Latency makes your data arrive late
  • Packet loss makes some data not arrive at all
  • Bandwidth limits how much data you can send

I shall write about all three, in that order.

Latency is caused by physics. Decades of science fiction notwithstanding, physicists have yet to figure out how to surpass the speed of light. Because of their failure (the fools! I mean really, how hard can this be?), we are unable to send any data faster than 186282 miles per second.

That’s still pretty fast, though, right?

I live in Seattle. My colleague Eli used to live in New York. That is 2413 miles away, which is 13 milliseconds at the speed of light.

I used to live in England. From Seattle to England is 4799 miles, which is 26 milliseconds.

In a 60 frames per second game, each frame gets 16 milliseconds. So I already have nearly two frames lag when I play with my friends in England.

But wait! This is not the whole story…

  • Network data does not travel through a vacuum. The speed of light is usually measured in a vacuum, but when data travels down fiber optic or copper cables, it slows to only 60%.
  • Also, network data does not only travel along cables. There will also be two modems, one at either end. Each modem adds around 10 milliseconds latency. If my friend does not use the same ISP and switchboard as me, there will also be several routers along the way. Each router adds between 5 and 50 milliseconds latency.

How bad can it get?

  • Xbox games are expected to work with latencies up to 200 milliseconds

How can you try this at home?

    NetworkSession.SimulatedLatency = TimeSpan.FromMilliseconds(200)

What can you do about it?

  • Design your game to be tolerant of laggy updates. For instance in a poker game, it doesn’t matter if you are 200 milliseconds late in learning what card was played.
  • Use prediction algorithms to hide the lag. Thanks to latency, you can never know the exact current state of a remotely controlled object, but if you know where they used to be 200 milliseconds ago, how fast they were moving, and whether they were speeding up, slowing down, or turning, you can make a good guess as to where they are likely to have ended up. Sometimes these guesses will later turn out to be wrong, in which case you should smoothly interpolate from the wrong guess toward the correct position, avoiding any sudden jerks. Even if you only guess right 90% of the time, that is enough to make the lag less objectionable. It is impossible to remove lag entirely: the goal is just to hide it enough that most players won’t notice.
  • Stay tuned: we have a network prediction sample in the works.

Comments (3)

  1. Ultrahead says:

    So, if each frame gets 16 milliseconds in a 60 fps game and Xbox games are expected to work with latencies up to 200 milliseconds, that is to say that it’s expected -in average- that every 12-13 frames a "jerk" could eventually happen, what in turn is the amount of frames that the human eye can perceive.

    Taking 200ms as the worst case scenario, we would be rendering 12 to 13 frames based on our predictions and assuming no changes in the oponents’ behaviors.

    Thus, the question is how much of those 12-13 frames we use to adjust the wrong values to the correct data by using interpolation in a smooth way.

    This is a very interesting topic, so cannot wait to get that sample!

  2. Anonymous says:

    Could you please tell me where to find the sample?