----- 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 machines 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)..... Regards John W. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
