• Advertisement
Sign in to follow this  

How much UDP delay is normal or must be reasonably expected?

This topic is 2350 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 everone,




how much delay when using UDP do you consider "normal"?

How much would you reasonably expect?

And another question: Does delay (usually/always) mean roundtriptime, or does it (sometimes) mean one way time?




I just made some tests with a friend using lidgren library.

Over internet it displayed just 16ms delay, which I consider very low. Is this normal? Or is this maybe because of the low physical distance?

Before that I tested using with artificial delay (a feature of lidgren) and set it to 200ms and it had quite heavy impact on my game.

But with 16ms it runs perfectly well (ofcourse).




What do you think?

Share this post


Link to post
Share on other sites
Advertisement
In the same state/country with good internet connections, probably 15-50 and very seldom lost packets. Across the continent, maybe 50-200 for US/Canada or between western European countries. Overseas maybe 150-500, with some expected packet loss.

I live in Sweden and it's usually 10-20 within the country, but can be more with different ISPs. I would expect about 150-250 between Sweden and the US, depending on which coast, 300-350 to east Asia, and about 400 to Australia (if everyone has good connections). It can vary very much however. When using mobile internet I've seen up to 1000 within the country when the reception is bad, but about 150-300 when I've used it where there's good connectivity.

(Round-trip times)

Share this post


Link to post
Share on other sites
http://google.com/search?q=average+ping+times

It is the round trip time that you care about.

Your game requirements can be whatever you want them to be.


Know your audience. Know what they have available and plan for it.


Are your players going to mostly be in a single building directly connected on a LAN? If so, you can reasonably expect ping times <10ms for most cases.
Are your players going to mostly be in dense residential areas with fiber-to-the-curb? If so, then you can expect to see ping times around 20-100ms, sometimes hitting 200ms.
Are your players going to mostly be in nearby suburban neighborhoods, with DSL and cable? If so, expect ping times around 200ms to be common.
Are your players going to be crossing large distances, such as international games at far edges of a single continent? Anything more than 2000 miles? If so, expect 200-400ms to be common.
Are your players potentially going to be in less densely populated areas? If so, expect times of 400ms+ to be common.
Are your players potentially going to be routed through satellites for long-distance connections? If so, expect times of 800ms+ to be frequent.

Do you know your customer?


I've had many friends that lived just 20 miles from San Jose, but because of the mountains and forest nearby they could not get a typical low latency Internet connection. There are many people living in relatively dense population centers who have "bad" networking situations simply because they live in hills or forests. Are you intentionally removing them from your customer pool?

Do you really want to limit your audience mostly to people living in dense cities with high-bandwidth connections that hooks directly to fiber within a city block?




Your game should be able to function reasonably well even with high latency. You should expect consumer hardware to hit 200ms on a fairly regular basis.

Even if a family has a high speed connection, when you've got others in the house streaming movies it can leave your game with a rather small pipe. Consumers won't blame their own habits, they will claim they have a high speed connection and blame your game.


We have limits that games must run well at 64Kbps and 200ms round trip, and must not disconnect or have other problems as long as the line stays above 40Kbps and under 400ms with <20% dropped packets. These are very similar to the minimums required by both Sony and Microsoft for all games. (They are possibly slightly stricter than their standards since we don't want to fail certification.)

It isn't that difficult to set up a network bridge to ensure your programs run well in real-world networking situations. You need a machine with a few network cards in it, but otherwise there are many packages (free and paid) to simulate all kinds of real-world networking conditions.

Share this post


Link to post
Share on other sites
Thanks for your answers.

The game is only programmed as a hobby, so I don't want put too hard restrictions on it.

The problem with ~200ms delay was that when the client starts a jump he starts it locally and sends a message to the server. The server then also starts the jump (short time later) and sends the client back position and velocity updates. I use interpolation for the position, so that's not a big problem, but so far I set the velocity directly without interpolation. When then the next update from the server arrives, the actor stands still in the air for a very short time, which is very annoying for the player. Short after that the next update arrives and the rest of the jump is performed without problems.

I tried to fix it using interpolation also for the velocity (although I read that that's not a good idea), but it didn't help that much and made other parts of movements worse...

I haven't found a good solution for it so far. Maybe I will just don't care and only play it with low latencies, but if you have any suggestions which could help me to fix it, it would be very nice :-)


Edit: Should I maybe start a new topic for that?

Share this post


Link to post
Share on other sites
You could make the client decide its own position instead of the server. That can introduce other problems with synchronization however, depending on your game.
Another option is to fake it, so the client displays its own version of the position while the server-provided position is the true one, and the client gradually corrects its version when needed, to be in line with the real position.
A third is to use lock-step synchronization so the server and client always run the exact same deterministic simulation, and start the jump at the exact same ingame-time. This usually involves delaying all actions by the round-trip time (or possibly just the one-way time), as you can't actually perform an action until you know the server has received information about it. When the player presses the jump button a message is sent to the server, and when a reply is received both the client and the server can do the jump independently with the exact same results.

Share this post


Link to post
Share on other sites

Another option is to fake it, so the client displays its own version of the position while the server-provided position is the true one, and the client gradually corrects its version when needed, to be in line with the real position.


That's what I'm already doing. That's what I meant with interpolation (maybe it's the wrong word for this?).


I'm correcting the position gradually (the difference between client-position and server-position is reduced by 10% each time a position update is received). But I'm not doing it with the velocity. Instead I set the velocity directly to the server's value (which will be out of date when it's received).

When I try the same with the velocity as with the position (10% ...) it only partially fixes the problem and makes all other movements appear much worse.



Do you have further suggestion, on how I can fix this?

Thanks for your help so far!

Share this post


Link to post
Share on other sites
Sounds like since the messages received from the server essentially holds the same information 200ms in the past, the interpolation will try to transport the client back in time in order to repeat the same action again that it just did 200ms ago. In order for the interpolation to work correctly you need to delay the actual jump on the client with 200ms.
You could try skipping the interpolation entirely instead, and expect the server and client to run the exact same simulation. Or turn it the other way around, and let the server interpolate to match the client instead. It's not as bad for a remote player to see some inexact movement of another player during lag as it is when your own character behaves strangely. Many games trust the clients to handle their own business, as it often gives a better experience for the player.
There are ups and downs to any method, and it's hard to say exactly which one is the best in each case. One of the extreme problems you can encounter is for example if you run a floating point simulation of a jump, with a small error between the server and client position, which could cause the server-side player to land on a platform and the client-side player to miss and fall to the ground. At this point obviously no 10% error-correction could fix the problem. If things like that can happen at all in your game it's probably easiest to let the client be authoritative on the player position and have the server interpolate, and force the server-side simulation to re-align 100% with the clients if the error becomes too large.

Share this post


Link to post
Share on other sites
I like this idea, but it probably will make things much more complicated.

Should then the client also be responsible for checking collisions between his actor and other actors or should this be done on the server? At the moment everything except for some movement extra/interpolation is done on the server.


Share this post


Link to post
Share on other sites
Yes, the client would be completely responsible for its own player actor. How many players does your game support?
Each client would at least run the physics simulation for its own actor, in a world where everything else is controlled by the server, like other player actors.
On the server-side, the simulation is run as normal, but with each of the player actors controlled by interpolation of the information received from the clients. This will make the remote player actor movements somewhat inexact, but without a very high delay it will often be an acceptable approximation.

It could cause some other issues, such as if two players block each other or hit each other in mid-air but there is a small difference in the simulation, so they move apart on one client but stay blocked on another. Since every client is responsible for its own player this will be auto-corrected once the position is updated the next time, but will result in a visible "glitch". Things like that are however almost unavoidable without forcing synchronization and delaying actions to occur at exactly the same time for everyone. Also with only 200ms this should be rare and only happen if a game lags from packet-loss or other network-problems, at which point a small glitch usually doesn't matter unless it breaks gameplay. Also, there will never be a glitch for your own player, just for remote players.

Share this post


Link to post
Share on other sites

Hi everone,




how much delay when using UDP do you consider "normal"?

How much would you reasonably expect?

And another question: Does delay (usually/always) mean roundtriptime, or does it (sometimes) mean one way time?




I just made some tests with a friend using lidgren library.

Over internet it displayed just 16ms delay, which I consider very low. Is this normal? Or is this maybe because of the low physical distance?

Before that I tested using with artificial delay (a feature of lidgren) and set it to 200ms and it had quite heavy impact on my game.

But with 16ms it runs perfectly well (ofcourse).




What do you think?



Normally frame rate is 60 for general games. 16ms is very similar as 1/60 second.

It is just small latency. I think an error range will be just 1 frame. You don’t even need to worry with 16ms.

For example between South Korea (where I live in[font="Arial"]J) to China latency is around 40~50ms but it’s still ok. [/font]

However 200ms is not ok. Say like FPS game, player can’t play game with 200ms latency. If players are located in nearby each other but server is located in far from those players, you may need P2P communication between players. (It’s ProudNet’s specialty!)

From my experience, I can say normally less than 20ms in local communication within same country. Also I experienced 40~100ms latency between two countries. If players are located more than 2,000km each other then you may see huge latency. This is why many online games are using separate server for each country.

Share this post


Link to post
Share on other sites

http://google.com/search?q=average+ping+times

It is the round trip time that you care about.

Your game requirements can be whatever you want them to be.


Know your audience. Know what they have available and plan for it.


Are your players going to mostly be in a single building directly connected on a LAN? If so, you can reasonably expect ping times <10ms for most cases.
Are your players going to mostly be in dense residential areas with fiber-to-the-curb? If so, then you can expect to see ping times around 20-100ms, sometimes hitting 200ms.
Are your players going to mostly be in nearby suburban neighborhoods, with DSL and cable? If so, expect ping times around 200ms to be common.
Are your players going to be crossing large distances, such as international games at far edges of a single continent? Anything more than 2000 miles? If so, expect 200-400ms to be common.
Are your players potentially going to be in less densely populated areas? If so, expect times of 400ms+ to be common.
Are your players potentially going to be routed through satellites for long-distance connections? If so, expect times of 800ms+ to be frequent.

Do you know your customer?


I've had many friends that lived just 20 miles from San Jose, but because of the mountains and forest nearby they could not get a typical low latency Internet connection. There are many people living in relatively dense population centers who have "bad" networking situations simply because they live in hills or forests. Are you intentionally removing them from your customer pool?

Do you really want to limit your audience mostly to people living in dense cities with high-bandwidth connections that hooks directly to fiber within a city block?




Your game should be able to function reasonably well even with high latency. You should expect consumer hardware to hit 200ms on a fairly regular basis.

Even if a family has a high speed connection, when you've got others in the house streaming movies it can leave your game with a rather small pipe. Consumers won't blame their own habits, they will claim they have a high speed connection and blame your game.


We have limits that games must run well at 64Kbps and 200ms round trip, and must not disconnect or have other problems as long as the line stays above 40Kbps and under 400ms with <20% dropped packets. These are very similar to the minimums required by both Sony and Microsoft for all games. (They are possibly slightly stricter than their standards since we don't want to fail certification.)

It isn't that difficult to set up a network bridge to ensure your programs run well in real-world networking situations. You need a machine with a few network cards in it, but otherwise there are many packages (free and paid) to simulate all kinds of real-world networking conditions.




You can also have different issues with cable connections being bursty (lumped packets for the connection) or saturated while the shared line is monopolized by mass downloads and in the old days also with the over the air long distance internet connections.
No doubt there are probably alot of lost packets if your computer is wirelessly connected and the channel is busy or has interference of various kinds.

Share this post


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

  • Advertisement