Howto:Multi-computing FlightGear

FlightGear has some very powerful functions which are (IMHO) quite disregarded yet: distributing the property tree via LAN (local area network). Thinking long about this feature I finally came to the conclusion to interconnect several computers in my LAN to react like one single FlightGear system.

Entrée

Advantages:

• Distributing the load of several calculations from one PC to multiple machines
• Attaching more screens for a more realistic simulation experience
• "Cleaning up your screen" to see scenery on the screen(s) of your (graphically) most powerful machine and instruments on more weakly computers
• Add more advantages here...

Disadvantages:

• Costs, as you need more computers, screens, network equipment
• Higher power consumption
• More space for placing all devices

Ergo: low WAF (wife acceptance factor)

Aperitif: What's in the box?

So what is needed for multi-computing FlightGear?

• Basic knowledge in networking (IP address, subnet mask, protocols, network sockets, firewall, etc.)
• At least two computers (use the Operating System of your choice; I prefer using Linux and/or Windows, Mac may work too, though I don't have any knowledge about Macs)
• Switch / Access Point / Hub (yikes!) for interconnecting all participating devices (think of enough network cables if you decide to use a Switch or Hub)

I advise to use a modern 8-port Gigabit Switch which is quite low in price nowadays and will not give you too much headache in solving weird issues in your LAN. Choose your favorite brand. The hardware differences in this price segment are only marginal.

Appetizer: Interconnecting your computers

Attach all devices to your LAN and configure the network devices so each of them is accessible via network (try a ping or similar to assure basic connectivity). In the following example I assume that your local network is 192.168.1.0 with a subnet mask of 255.255.255.0. Give all your devices individual (consecutive) addresses from this network and make triple sure not to create double IP address entries which will result in hard to resolve network conflicts. I'm not going to provide you detailed information on how to set up a network configuration for a certain operating system. This information is written down a million times in other places and should not be subject of this article.

Main Dish: The Master Machine

I decided to make my most powerful computer to become a master for FlightGear. It's name is "leader" with IP 192.168.1.10, it runs on Ubuntu Lucid x64 and comes with a neat NVidia GTX260 and 5.1 sound output. This will be my:

• Data-sending instance (more of this later)
• Scenery presenter
• Joystick / Yokes / Controller input
• Sound output

Install FlightGear just like you would do on any other system. Make sure to have the corresponding FlightGear data folder and some scenery data if you are not flying on-line using TerraSync, what I strongly suggest to do.

Now it's time to bring up your "leader". On the command line add the following two IO options to provide your FDM and your controls input to the first slave computer (assuming IP 192.168.1.11) Slave computers will be discussed in the next chapter:

Master-Settings using FGrun

--native-fdm=socket,out,60,192.168.1.11,5510,udp
--native-ctrls=socket,out,60,192.168.1.11,5511,udp

• "socket" tells FlightGear how to present the data (here: as a network socket)
• "out" defines that the data is outgoing from "leader" to the slave(s)
• "60" is the update frequency in Hz (= updates per second). This must be set identically on all machines or you will get weird jitter
• "192.168.1.11" is the destination machine(s) where you want to send your data to
• Regard the use of two different ports (5510 and 5511) for the two different UDP sockets we are creating here for sending data to 192.168.1.11

In case of adding a second slave (assuming IP 192.168.1.12):

--native-fdm=socket,out,60,192.168.1.12,5510,udp
--native-ctrls=socket,out,60,192.168.1.12,5511,udp

Regard the use of the IP 192.168.1.12 for sending the data to Slave #2. All further slaves follow the same principle.

Now it's time to fire up "leader" the first time with the new settings at your favorite airport with you favorite aircraft. Watch carefully if you see any errors in console output as this will give you precious hints if you made any mistakes in the IO configuration. Double check IP addresses, socket ports and protocol settings. If all works fine just let "leader" run idle for a while as we now set up the first slave and can test its connectivity right away.

Side Dish: The Slave Machine(s)

After setting up "leader" we will now configure "slave1" with IP 192.168.1.11 ("slave2" 192.168.1.12, etc.), connecting it to your LAN and installing FlightGear. It's time to take care of some startup parameters. I don't use FGRun on the slaves therefor I don't provide screenshots like I did for "leader":

--native-fdm=socket,in,60,,5510,udp
--native-ctrls=socket,in,60,,5511,udp
--fdm=null
--enable-panel
--disable-hud
--disable-sound
--prop:/sim/ai/enabled=false
--prop:/sim/ai-traffic/enabled=false
--prop:/sim/rendering/bump-mapping=false
--prop:/sim/rendering/draw-otw=false
--prop:/sim/rendering/draw-mask/terrain=false
--prop:/sim/rendering/draw-mask/aircraft=false
--prop:/sim/rendering/draw-mask/models=false
--prop:/sim/rendering/draw-mask/clouds=false

• "native-fdm" and "native-ctrls" are now sockets using the "in" parameter because they do listen on your network interface for incoming traffic.

!!! Make sure to configure your firewall to accept incoming traffic on the above mentioned protocols/ports/sender IPs !!!

• "update frequency, port and protocol" are identical to the settings of "leader". Regard two commas between frequency and port. This is where normally the IP is placed and two commas here are intended because now the socket "listens" on your configured IP (on "slave1" 192.168.1.11) and on localhost (which is always 127.0.0.1 and used for internal networking). You can verify this on the slave by opening a console window and use a socket monitor like "netstat" to verify that the sockets are running on the proper interface and correct ports. If you want that FlightGear is just listening on your external interface you may add the address instead so you write a line like:

--native-fdm=socket,in,60,192.168.1.11,5510,udp

• "fdm=null" tells FlightGear not to use any flightmodel as this is given and calculated by "leader"
• "enable-panel" does exactly what it says: it's enabling the instrument panel. That's what we want here
• "disable-hud" will remove the heads up display. We have this on "leader". Here it's just not needed
• "disable-sound" does also what it says. No need for it on the slave. You have sound on "leader", don't you?
• "prop:/..." deactivates parts in the rendering chain which we don't need here. These features are running on "leader" and there they do what they should do

Dessert: Performance

I came up with the idea of using multiple (old) computers I collected during the last years because I hated the idea of having PCs dusting around without using them. As I like the idea of giving them a new mission it's sometimes somewhat tricky to gain the necessary performance depending on the hardware; so I try to get as much performance out of the old machines as possible. I don't see any needs for fancy eye candy on a PC whose job it is just to bring an instrument panel to the screen.

So what can we do to gain more power?

• First: turn on "View -Display Options - Show Frame Rate" to get a feeling for settings that will help overall performance, and observe if the frame rate stalls, raises or drops after defining a new setting
• Step-by-step turn off all rendering options either in the main window or via command line options
• Set in the command line "--prop:/sim/rendering/camera-group/zfar=x", where x is a small value (e.g. 1 to 100)
• Don't provide the path to fg-scenery. Loading may take longer now and in the window you may only see water around you but this nothing to worry about

Coffee & Cheese: Conclusion

Now you have a fancy system interacting with each other. You may now proceed to configure multiple views and monitors so so can define side views, top windows, single instruments, glass cockpit avionics and and and...

Reflux: Dos, Don'ts and Despair

• Until now I was only able to use the 2D panel of the default aircraft Cessna 172 independent of what aircraft I start with. In times of 3D cockpits it seems not very easy to find fresh 2D panels.

Please write down your findings and personal experiences here...

Enjoy and have fun

--D-SKY1 22:57, 8 August 2010 (UTC)