On Thu, Feb 25, 2010 at 3:26 PM, Grimes, John R Mr CTR USAF AFMC AFRL/RWGG <
john.grimes....@eglin.af.mil> wrote:
> I am currently running FlightGear 2.0.0 (snagged from the ibiblio ftp
> site) that I compiled on my Ubuntu 9.10 64 bit system. Compiled up no
> problem, but I have noticed that when I attempt to setup a master/slave
> scenario that I get some odd artifacts on slave display. The scene on the
> slave looks as if the position of the aircraft is lagged behind, and then it
> suddenly tries to jump to the correct location. These artifacts don’t seem
> to appear in cockpit view or tower view, but they make all the other views
> almost unusable. I have checked the developers lists, and I have seen
> people mention problems similar to this, but nobody seems to have a good
> solution. It could be a double precision problem, or it could be the FG is
> propagating the view forward by a certain amount of time and correcting the
> view when a new frame of data comes in.
>
>
>
> Here is the master system’s command line I am using.
>
> ./fgfs –aircraft=c172p –native-fdm=socket,out,30,192,168.1.9,5500,udp
>
>
>
> Here is the slave’s command line.
>
>
>
> ./fgfs –aircraft=c172p –native-fdm=socket,in,30,192.168.1.8,5500,udp
> –fdm=external
>
Hi John,
Sorry for the slow reply. Since you are using the --native-fdm protocol,
all the values you are sending are full precision binary doubles. There
shouldn't be any precision problems like is possible with the "generic"
protocol.
I've used this sane mechanism with up to 7 slaved displays from a single
master machine with pretty good results. I haven't tried with the v2.0.0
code. It's possible something slipped in and broke something, but I think
the chances of that are pretty low.
For the inbound socket command line, you shouldn't need to specify an ip
address, only the sending side needs to know where to send the data to.
You've specified an update rate of 30 hz in your command line options. You
might double check that your hardware is able to drive the displays at that
rate. There is a menu option to turn on a small frame rate counter (or you
can find the frame rate in the property tree under /sim/ I believe it is.)
It would be good to double check what frame rates you are really getting
and do that on both ends.
One possible reason the remote end is lagging would be if the sending end is
lagging. Data is only sent (or accepted) once per frame, so you can never
do better rates with your data transfers than the update rate of the visual
scene. In other words, if you requested an output rate of 60hz, but your
"master" machine is only able to draw the display at 10hz, then that will be
the rate of your data output.
Another thing to consider or look for is pauses due to loading scenery or
multiplayer aircraft. The multiplayer aircraft can generate a big frame
rate hit ... up to several seconds depending on particular aircraft that
needs to be loaded. If you have multiplayer turned on, that could be a
source of lags. (One small trick is to watch for the hard drive activity
light to be pegged on when you see a pause ... that could be an indication
the system is busy loading a new model.)
> I have played with the update rates of both the socket inputs and outputs
> and it did not make much difference. I have relatively a hot system and
> video card, so I have tried frame-rate-throttle-hz settings of 30 or 60 to
> see if would help (it did not). Am I missing something in the command lines
> or is this the expected operation of the views?
>
Sounds like you have covered most of the obvious things. Another possible
thing to check is your network. If it's highly loaded, that could affect
how fast packets get through ...
While I'm at it, let me put in a plug for some great work that Tim Moore did
about a year or so ago. He leveraged our OSG scene graph engine to support
multiple cameras and displays on a single machine. Many video cards (most
nvidia cards) support 2 monitor outputs, and with the PCI Express bus, it's
possible to install as many as 4 video cards in some PC's. I worked on a
system last summer that had 4 dual head video cards and drove 8 simultaneous
displays from a single PC with pretty good results. Depending on what you
are trying to accomplish, this might be another option to consider. When
the entire visual system is driven from a single PC, you don't have to worry
about synchronizing clouds, multiplayer traffic, AI traffic, random objects,
weather, and time of day across several PC's.
Best regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
