----- Original Message -----
From: "Curtis L. Olson" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
Sent: Friday, December 10, 2004 1:35 PM
Subject: Re: [Flightgear-devel] Broadcast Address

> RTLinux might give you some additional fine grained timing tools to throw
at the problem, but it's still a hard problem.  You still have to detect a
situation where you aren't going to finish drawing in time, reliably
identify the reason you aren't finishing in time (fill rate? too much
geometry?  texture thrashing?  running 3 other apps in the background on the
machine?) and come up with some way to resolve the problem ... are you going
to draw less geometry?  Pull in the far clip plane, go to a lower LOD on
some of your objects (which ones?)  Your solution needs to directly address
the cause of the problem our your fix might not help you.  In practice you
can probably find some trends and narrow the problem scope significantly,
but it's still not easy.
The motivation to try RTLinux is related more to the control/feedback
problem than any graphics issues.  What has been achieved running FG on
off-the-self commodity PCs is remarkable. The problems/issues with glass
displays are trivial by comparison.

ATM the FG data rate is set at 30Hz in both directions using sockets
configured for non-blocking udp datagrams. Since the nominal display rate is
around 100fps for each opengc machine, they have no problem "gobbling up"
all the packets. Conversely, the FMC is running as part of the display graph
and pumping out udp control packets at whatever rate the opengc code is
cycling. And the sim displays are simply exchanging data by sending out udp
packets in a similar manner.  All very simple, very messy, and very
unorganized. How that impacts the control loops, gains, and responses to
control commands is a big TBD.  What has been happening is as the FG data
rate is increased to say 45Hz, some latency has been creeping into the
displays resulting in CIOs (computer-induced-oscillations) with the flight
control system when the display rate drops due to increased number crunching
and/or symbol generation and a higher rate of data exchange across the sim

Thinking if I can broadcast a small timing packet or the data packet itself
from FG and use that as a sync pulse for each machine on the sim side. Now
each of those machines can begin processing for the current frame, exchange
whatever state data for the current frame, and return required control
commands before the start of the next frame or at least raise a flag if
there is any frame slippage. Result is a more deterministic system sync'd to
the FG cycle.

Of course, still need to understand how and when FG and JSBSim exchange data
across the property system(s).....

John W.

Flightgear-devel mailing list

Reply via email to