Board index FlightGear Support Multiplayer

How do you cope with network lag?

Trouble getting online, setting up a server?
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- copy&paste your commandline.

Please, also see Requesting Technical Help.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

How do you cope with network lag?

Postby amue » Fri Apr 10, 2020 10:11 am

Split off from the topic Operation Red Flag (KSUU Crew).


I have some questions to you OPRF guys:

How do you cope with network lag?
Do you use the MP lag adjustment feature that extrapolates the aircraft position? I tried to use this feature but it caused annoying jumping of the aircraft position if the aircraft is maneuvering.
Or do you don't use the lag adjustment? But then the remote aircraft are displayed in the "past" and I think that's non-desirable with formation flying and dogfights.
I think you have your own MP server. With what actual lag values (ms) you have to cope with?

Andi
Last edited by Johan G on Tue Apr 21, 2020 7:10 pm, edited 1 time in total.
Reason: Split off from the topic "Operation Red Flag (KSUU Crew)".
amue
 
Posts: 38
Joined: Tue Apr 03, 2018 9:13 am

Re: Operation Red Flag (KSUU Crew)

Postby swampthing » Fri Apr 17, 2020 10:24 am

Can you tell me which aircraft you are experiencing lag problems with?
www.opredflag.com
I have sworn upon the altar of God, eternal hostility against every form of tyranny over the mind of man. -Thomas Jefferson-
swampthing
 
Posts: 565
Joined: Wed Oct 28, 2015 4:10 am
Location: Missouri
Callsign: swamp
Version: 2018.2
OS: multiple

Re: Operation Red Flag (KSUU Crew)

Postby amue » Fri Apr 17, 2020 8:47 pm

swampthing wrote in Fri Apr 17, 2020 10:24 am:Can you tell me which aircraft you are experiencing lag problems with?

Lag is not aircraft specific. Lag is network inherent.

With the current multiplayer implementation in FlightGear you have two choices:

1.) Display the multiplayer aircraft in the "past" by interpolating the position/orientation of the aircraft between already received network packages.
This gives you relatively smooth aircraft movements, but you see the aircraft where it was in the past and not where it is in the present time.

or

2.) Display the multiplayer aircraft in the "present" time by extrapolating (predicting) the position/orientation of the aircraft from the last received network package.
But in this case the aircraft gets jumpy when the aircraft is just put into the new position with each new received network package (because the prediction is not 100% correct especially with maneuvering aircrafts).

Since especially for military flight operations (e.g. formation flight or dogfights) I thought it's important to have the aircraft shown in the present time and not in the past. Therefore I assumed that the OPRF guys are using option 2.) And in this case I wanted to know how they cope with jumpy aircraft.
amue
 
Posts: 38
Joined: Tue Apr 03, 2018 9:13 am

Re: Operation Red Flag (KSUU Crew)

Postby swampthing » Fri Apr 17, 2020 10:43 pm

We had this problem in the it was more specific to certain aircraft but that has been fixed. One thing could be the mp server you are using, One thing I've done is adjust AI/MP interior to 0 or very far out in your LOD settings. Every time you load the cockpit of the other plane you are likely to get lag. Option 1 set it to 0 to try and keep other planes cockpits from loading or set it way out so they stay loaded if you have enough GPU power to handle it. For setting lag time I believe the answer was to ping your IP and set lag time according to that. I personally have not experienced planes jumping over MP in a long time unless the other person had a poor connection.
www.opredflag.com
I have sworn upon the altar of God, eternal hostility against every form of tyranny over the mind of man. -Thomas Jefferson-
swampthing
 
Posts: 565
Joined: Wed Oct 28, 2015 4:10 am
Location: Missouri
Callsign: swamp
Version: 2018.2
OS: multiple

Re: Operation Red Flag (KSUU Crew)

Postby Johan G » Sun Apr 19, 2020 10:28 am

amue wrote in Fri Apr 17, 2020 8:47 pm:2.) Display the multiplayer aircraft in the "present" time by extrapolating (predicting) the position/orientation of the aircraft from the last received network package.
But in this case the aircraft gets jumpy when the aircraft is just put into the new position with each new received network package (because the prediction is not 100% correct especially with maneuvering aircrafts).

I have not flown in FlightGear for years, but I often flew with others in multiplayer. Since we often flew high performance aircraft a bit of acceleration/deceleration together with some ping time jitter would lead to of "rubberbanding" for some of the pilots. In essence, someone in the group would suddenly zoom forward or back half a mile or more within a a couple of seconds and then jump back and forth for some seconds before stabilizing. It can easily be spotted in older YouTube videos, for example the FGUK Saturday night flights. I am not sure how often this happens these days.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5691
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Operation Red Flag (KSUU Crew)

Postby Richard » Mon Apr 20, 2020 2:39 pm

amue wrote in Fri Apr 17, 2020 8:47 pm:Lag is not aircraft specific. Lag is network inherent.

With the current multiplayer implementation in FlightGear you have two choices:

Since especially for military flight operations (e.g. formation flight or dogfights)....


For me it's the FGUK Saturday night flights that truly can stress MP and show problems with variable latency because there can often be more than 10 players in close formation; OPRF is not often as much about formations; except for tanking and variable latency isn't something that I've often had a problem with probably because mostly ORPF events use a dedicated single MP server.

I've measured roundtrip time as upto 2000ms; typically ~1700ms on my system running two FG instances. This is with a 60ms ping to the FGMS - using the same server on different (incoming) ports.

The best option to mitigate network lag is firstly to all use the same server (as this removes server->server lag) and then to adjust the lag settings in the Multiplayer menu (see http://wiki.flightgear.org/Real_Time_manual)

I did some brief testing and analysis of flights with pilots from UK, Europe and USA with two cases, firstly all using the same server (located in either USA or Europe) and secondly using the Geographically closest server. Typical USA->Europe transmit times are around 90ms, but did peak higher. All pilots using the same server works out at Pilot Ping[1] -> Server -> Remote Pilot Ping[3]. So for a USA based server this works out as

* USA -> Europe : [1] 30ms -> [3] 150ms
* USA -> USA: [1] 30ms -> [3] 45ms
* Europe -> Europe: 40ms -> 60ms

With multiple servers the local performance is better - but what I observed to be happening is that the times became very much more variable because Pilot Ping[1] -> Local Server -> remote server [2] -> Remote Pilot Ping[3] - overall the transmission time can be lower because [2] is often higher due to improved bandwidth but overall this appears to work out a lot more variable because there are more network connections and server processing.

This worked out as

* USA -> Europe : [1] 30ms -> [2] 95ms -> [3] 50ms
* USA -> USA: [1] 30ms -> [2] 18ms -> [3] 45ms
* Europe -> Europe: [1]40ms -> [2] 12ms -> [3] 60ms

So pretty much all comms will have a higher latency when pilots flying together are on different servers because these servers have to transmit data between themselves; so really the star topology is more about federating data rather than performance.

So generally my advice is for group flights to pick a single server and use it; then you can adjust your lag settings to that server and it can work out well without too much fluctuations - but obviously the whole MP comms could benefit from a total rewrite but that's unlikely anytime soon.
Richard
 
Posts: 765
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Operation Red Flag (KSUU Crew)

Postby jano » Tue Apr 21, 2020 3:17 pm

I'll add that being on different server give most of the time a very bad pps (packet per second) because the interconnexion are not done in full and the 1 packet/s is common. It's the lazy relay but depending the server, the "full" relay never happens.
You can see this in the"lag" page in pilot list in next, where i have 1, or even 0.5 pps for some planes on other mpserver, but 10 pps for those on the same server.
having planes with 1 pps give big jumps in mp with lag compensation :)
jano
 
Posts: 184
Joined: Thu Nov 29, 2007 11:32 pm
Location: france
Callsign: jano
Version: git
OS: debian SID

Re: How do you cope with network lag?

Postby drR0ckso » Tue May 05, 2020 8:40 pm

Essentially, all MPServers connect to the central hub server, MPSERVER01 located in Germany. There is one exception:

mpserver51 is connected to mpserver19. mpserver19 is operating in hub-mode and connected to mpserver01.

Generally speaking, there is some tiny amount of lag since the tunnel between the two has compression on it (XMLRPC is verbose) so it's not perfect, but shouldn't be any worse than connecting to an MPServer around the globe. The path from Atlanta goes through London to Germany anyway. All the other mpservers are connected directly to mpserver01, but that does not mean that all routes are the same or that paths are equal to the expected time delay of a given distance. Due to the proximity to Miami where the NAP of the Americas is, MPSERVER51 located in Atlanta, GA, USA is the closest server to South America via some cables.

As long as two users are closest to the same server, it's possible to minimize lag between users, just in case someone wants to practice in-flight refueling while another pilot flies a KC-135. The way the protocol works, the traffic goes up between servers when two aircraft are in proximity, and drops off after that.

http://wiki.flightgear.org/Multiplayer_protocol
I speak only for myself.
drR0ckso
 
Posts: 35
Joined: Fri May 12, 2017 3:14 am


Return to Multiplayer

Who is online

Users browsing this forum: No registered users and 3 guests