Spring RTS Engine

Why are game ping times so high? I'm sure they used to be getting better but they just seem to be getting worse? It's not uncommon for most peoples' pings to be sitting at 766 ms. Teabag/D2 who owns DarkEnergy hosts has looked into this but he can't work it out, and it's starting to annoy me. Of course, I can learn to cope with it, and will if it's a non-resolvable issue, but it would be nice if it could be changed -- whichever party has the power to do so.

~MasterBel

Let's start with the basics.

1) Where in the world (which continent) is the host located?
2) Where in the world (which continent) are you located?
3) What does a traceroute from you to the host look like? How many network nodes are there? Which leg(s) of the path add the most latency?

Reminder: a ping of 766ms is roughly within a factor 5 of the lowest possible (20000km / 300000km/s)*2=0.133s=133ms signal roundtrip time between any two antipodal points on Earth, and network packets do not travel in a vacuum or free of overhead.

Okey, I'm in Australia, but I'm seeing these ping times for most people. Mine are generally a bit higher. The host I most commonly play on is DarkEnergy and that's hosted in the UK. Also, as a trial, we sent a ping from my computer to the host computer and back, and latency was significantly lower both ways:

D2 wrote:i pinged… at 360ms but ingame he receives between 600-800ms.

I'm in Australia

you're screwed mate

The player pings you see ingame are not a direct measure of latency but rather the difference between server and client simulation time. This difference is always biased upward because of buffering (needed to compensate for network fluctuations, and allows the game to continue for a bit when you temporarily lose connection to the server), by an amount which varies per player.

Roughly, a "Spring ping" breaks down as (p + n) / 30 where p is the actual ping (converted to simulation frames) and n is the buffer size (also expressed in simulation frames). The value of 'n' is not constant but the result of many dynamically adjusted factors and can not* be controlled by users.


* there is a client config parameter 'UseNetMessageSmoothingBuffer' (which trades latency for smoothness), set this to 0 if you think your connection is stable** enough
** ping by itself is not a good indicator of stability, as anyone with poor local wifi reception can tell you

This would be changed in springsettings.cfg? I'm interested to try it out, see whether I can cope with playing without the buffer :) Thanks Kloot

(Somewhat related) It appears there are two lines for Vsync: "VSync" and "Vsync", set to 0 and -1 respectively. In SpringLobby it shows the Vsync option ticked. I'm confused :)

Spring only cares about "VSync" (which can have values between -6 and 6 since 104.0), SL seems to be using the wrong capitalisation.

UseNetMessageSmoothingBuffer indeed goes into springsettings.cfg; you will also be able to issue /netmsgsmoothing in the console if and when BA switches to a more recent maintenance build.

FWIW:

I get a pingtime of 233 to my server that is sitting 20 feet away on a 10 gigabit internal network connection (actual realistic speeds are around 1gb with 0.003ms latency due to the hardware in use (switch and network cards). The external connection is 75/75 megabit fiber.

But normal "ping" times for everyone who plays in a spring game is usually around 500ish, including myself to my own server quite often.

It might be simpler if they were slightly renamed, to avoid users confusing Springs ingame "ping times" with the usual meaning of network pings.

Kloot wrote:The player pings you see ingame are not a direct measure of latency but rather the difference between server and client simulation time.

I thought spads usually doesn't run the simulation, but only a kind of proxy.
Does it have something like a "global clock", to which the users simulation syncs (and which they can adjust with +/-)?

I get a pingtime of 233 to my server that is sitting 20 feet away on a 10 gigabit internal network connection

Note that 233 is a multiple of 33.333... and frames are spaced 33.333... milliseconds apart at speed 1, which implies a zero-ping (p=0) buffer size of n=7.

It might be simpler if they were slightly renamed, to avoid users confusing Springs ingame "ping times" with the usual meaning of network pings.

That might need a crowdsourcing round, I already tried to come up with a name as catchy and unambiguous as 'elmo' for time once and failed badly.

I thought spads usually doesn't run the simulation, but only a kind of proxy.

Correct: Spring clients run the simulation *logic*, a Spring server runs the simulation *clock*.

Does it have something like a "global clock", to which the users simulation syncs (and which they can adjust with +/-)?

It's more like a central pacemaker keeping everyone at a steady tickrate, with connection loss being akin to a heart attack.

Kloot wrote:

I get a pingtime of 233 to my server that is sitting 20 feet away on a 10 gigabit internal network connection

Note that 233 is a multiple of 33.333... and frames are spaced 33.333... milliseconds apart at speed 1, which implies a zero-ping (p=0) buffer size of n=7.

Ahh, ok I get it, makes sense. And as I said elsewhere, it's a pretty awesome design. Nice!

So what kind of math could we do vs Spring.GetPlayerInfo pingtime in order to get the actual latency to the host? I understand that it is much less important overall due to the buffer, but I still feel as though latency to the host is important enough to warrant displaying it.

So what kind of math could we do vs Spring.GetPlayerInfo pingtime in order to get the actual latency to the host?

As said earlier:

The value of 'n' is not constant but the result of many dynamically adjusted factors and can not* be controlled by users.

Means you cannot learn the actual latency from the Spring.GetPlayerInfo value.

Earlier today Kloot added `Spring.Ping(x)` which you can use to ping the server and get a response in the form of `Pong(x, timeSent, timeRecv)` unsynced callout. X seems to be an identification number of your choice (limited to 0-255 ints) and the timestamps are in milliseconds. You can trigger this manually with `/netping x` as well. This measures the "real" ping.