On Sunday 30 September 2007 22:15, Tim Moore wrote: > > The majority of calls behave nicely finish executing > > within 10 ms. A few can actually take more than a second. > > This sounds like a page fault / thrashing problem, perhaps caused by memory > bloat elsewhere. Can you get some system statistics from vmstat or sar? > Also, it would be interesting to see if this problem happens while staying > in the same geographical region i.e., there isn't any disk I/O happening as > a result of scenery loading.
There are a few interesting observations to make in this respect. I do believe there is a memory leak in FlightGear. Probably a major one in the scenery tile loader. As reported previously, I routinely let FlightGear run for a few days on end, while testing AIModels / Traffic code. In these test runs, I usually let the UFO hang over a central location, and FlightGear continues to run properly. However, a few months ago, while playing with the mips camera tools, I noticed that FlightGear ran out of memory rather quickly, while chasing an AI jetliner. After a few hours the program aborted because it had ran out of memory. I don't really remember the stuttering occurring during these tests, but I also didn't pay that much attention to stuttering at the time. Likewise, I seem to notice in last week's Seneca tests that the stuttering seems to get worse a lot faster when flying than when I leave the aircraft cold on the ground. So far, I've only tested FlightGear either in flying or cold condition. A next logical test would be to put the aircraft on the runway and leave it there with the engines running and all systems turned on. That would give an estimate of how much the scenery pager contributes. Regardless, however, even in cold configuration, flightgear's performance is still degrading slowly. A few more random notes: - I usually see some swap space is in use (using KDE's system monitor applet). This typically fills up in the course of a few weeks until I restart KDE. I don't usually see this affecting FlightGear's performance though... - Adding a single integer member variable to the SGSubsystem class seems to crash FlightGear immediately while running the Seneca (haven't tested any other aircraft). Could this be indicative of a memory corruption somewhere down the line? I have to add that I need to go back to this test and replicate it in a slightly more controlled way. - I let flightGear run overnight after yesterday's session. When checking this morning, I found the harddisk was ticking like crazy, the amount of swapspace had increased quite a bit, and the KDE system monitor was showing that close to 100% of CPU activity was run in "IOWait" state. This lasted for seconds on end. However, swapspace wasn't filled nowhere near capacity (probably something like 50 - 60%). It seems like something is swapping, and it's occurring probably more on the Seneca than on other aircraft. What I don't understand is that Linux performance typically remains fairly stable, because the kernel is usually smart enough to swap out only the inactive bits of memory. These usually happen to be the lost memory fragments. That doesn't seem to be the case here though.... I will probably try running a valgrind session sometime this week (yohoo, 1 hour to just get past initialization, and 1 frame every 20 seconds. :-) ). And also try running vmstat > > Can you identify a known point in time when this wasn't happening? > Hard to tell. I think we had some reports on stutter showing up on fgfs devel late last year. Probably around December. I'd say that around October last year everything was still reasonably smooth. I Cheers, Durk ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
