Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
C-like in many ways. Probably the biggest barrier for most people is going to be getting their development system setup properly so they can compile their new code additions or changes. I sort of disagree here. Setting up a development system is not a big deal (even I managed to do it, so anybody else should be able to) but its not that easy to get your changes into the system. I am not complaining about this and I acknowledge that changing the internal program is a thing that has to be carefully reviewed. Writing some Nasal code usually does not affect the whole system and can be maintained for a single aircraft. To make things easier for developers, can we think of a plug-in system for callbacks so a potential developer write a library that is linked in dynamically by the flightgear core? I think having a plug-in system for compiled/binary extensions whould give us great flexibility without touching the flightgear-core to heavily. Torsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Torsten Dreyer -- Thursday 25 October 2007: To make things easier for developers, can we think of a plug-in system for callbacks so a potential developer write a library that is linked in dynamically by the flightgear core? No. That would mean to add and maintain plug-in loader code for all supported platforms, as well as hundreds of lines of documentation, for people who are bright enough - to set up a development environment - to understand enough of fgfs internals to write a module - that follows an interface API specification but are too stupid - to add three lines to a Makefile.am - one line to fg_init.cxx and - one line to main.cxx Such a feature wouldn't make developing one bit easier or faster -- quite on the contrary. And it would lead in no time to Windows/Linux/Mac-*only*, binary *only* addons. Sure, the GPL would prohibit to run such modules with fgfs, and Curt would be happy to sue all infringers (because he has too much time and too much money. :-) This is not where we want to go. (As far as I'm concerned, but I don't speak for the project.) m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Sent: 25 October 2007 14:10 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes * Torsten Dreyer -- Thursday 25 October 2007: To make things easier for developers, can we think of a plug-in system for callbacks so a potential developer write a library that is linked in dynamically by the flightgear core? No. That would mean to add and maintain plug-in loader code for all supported platforms, as well as hundreds of lines of documentation, for people who are bright enough - to set up a development environment - to understand enough of fgfs internals to write a module - that follows an interface API specification but are too stupid - to add three lines to a Makefile.am - one line to fg_init.cxx and - one line to main.cxx Such a feature wouldn't make developing one bit easier or faster -- quite on the contrary. And it would lead in no time to Windows/Linux/Mac-*only*, binary *only* addons. Sure, the GPL would prohibit to run such modules with fgfs, and Curt would be happy to sue all infringers (because he has too much time and too much money. :-) This is not where we want to go. (As far as I'm concerned, but I don't speak for the project.) And to add my two pence worth, I have never had the slightest dificulty in getting new or amended code into fg, provided that it was: A. Justified B. Worked. There has been the odd difficulty over style, indents, and tabs. But let's not go there. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 00:15, Vivian Meazza wrote: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Hmmm, I didn't say that FlightGear is completely pause free now. I did say that the mysterious interval pauses are gone. These are the pauses that become increasingly longer and longer over time (up to the point of several seconds, or even minutes). The interval pauses are not affected by terrain type or whatever, and originate because the nasal memory footprint keeps growing and growing. From the sound of it, you're experiencing model loading pauses (either caused by Multiplayer / AI, of the tile loader). Most likely, the pauses you see correspond to pauses coming from the terrain loader (since they don't correspond to Subsystem activity). To verify, place a debug statement in simgear/scene/model/model.cxx, line 462, or thereabouts. Something like: SG_LOG(SG_GENERAL, SG_INFO, Requesting model path); and see if that message corresponds to the pauses you see. Its obvious that eventually we need to address these pauses too. This may take a bit longer, because it requires redesigning. In plib we're actually hitting a design limitation, but in OSG it should be possible. Having said that, addressing the model loading pauses isn't nearly as daunting, because the problem is well understood. This is stark contrast with the interval pausing, where none of us really had a good idea what was going on, until about a week ago or so. Cheers, Durk - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Georg Vollnhals Sent: 23 October 2007 23:34 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? I have tested with vsync on and off. On balance vsync on seems to make the situation worse. I have also tried throttling the frame rate: this definitely is counterproductive, noticeably increasing the frequency and magnitude of the hesitations. One significant difference is that the Buccaneer has no malformed listeners in its Nasal so the gain in correcting this bug would, I think, be marginal. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Durk Sent: 24 October 2007 07:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes On Wednesday 24 October 2007 00:15, Vivian Meazza wrote: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Hmmm, I didn't say that FlightGear is completely pause free now. I did say that the mysterious interval pauses are gone. These are the pauses that become increasingly longer and longer over time (up to the point of several seconds, or even minutes). The interval pauses are not affected by terrain type or whatever, and originate because the nasal memory footprint keeps growing and growing. From the sound of it, you're experiencing model loading pauses (either caused by Multiplayer / AI, of the tile loader). Most likely, the pauses you see correspond to pauses coming from the terrain loader (since they don't correspond to Subsystem activity). To verify, place a debug statement in simgear/scene/model/model.cxx, line 462, or thereabouts. Something like: SG_LOG(SG_GENERAL, SG_INFO, Requesting model path); and see if that message corresponds to the pauses you see. Its obvious that eventually we need to address these pauses too. This may take a bit longer, because it requires redesigning. In plib we're actually hitting a design limitation, but in OSG it should be possible. Having said that, addressing the model loading pauses isn't nearly as daunting, because the problem is well understood. This is stark contrast with the interval pausing, where none of us really had a good idea what was going on, until about a week ago or so. Thanks for clearing that up: yes, we do seem to have cleared a significant bug. Your analysis of the problem seems plausible. I'll try the debug statement later today. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Heiko Schulz Sent: 23 October 2007 23:55 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes Hi, Couldn't test it, waiting that someones will do a precompiled binary for windows. But it sounds good, very good though at least there are still some perfomance issues. I think of AI and the loading of the scenery tiles. What Vivian is writing sounds for me like the stutters of loading of objects. If I use Random Objects FGFS is hardly to use, even I decrease the count of objects. It would be good if Vivian could send his choosen settings for comparing. HHS --- Georg Vollnhals [EMAIL PROTECTED] schrieb: Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? This test was run with every option de-selected, including --prop:/sim/replay/disable=1 Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
The Seneca is special in that it attaches listeners to YASim internal properties, which are updated multiple times per frame, unlike most other listeners, which run *at most* once per frame, but actually very rarely. Oh - wasn't it using JSBSim as fdm!? I hope that the stuttering is fixed for all. And in any case should the Seneca fix its listener use. For example, by using on-change-only listeners, or using a simple loop which checks the interesting values once per frame. I'm available for consulting if necessary. :-) I am working on this and have removed most of the frequent-update listeners in my local copy. I will have it ready for cvs soon after some more testing here. At least my listener-loaded-code was not *that* bad: It helped Durk to track the stutter-bug. Now that I know it is found, I can safely remove this bug-showing-feature in the Seneca-code ;-) Thanks all for the great work! Torsten - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Torsten Dreyer -- Wednesday 24 October 2007: The Seneca is special in that it attaches listeners to YASim internal properties, which are updated multiple times per frame, unlike most other listeners, [...] Oh - wasn't it using JSBSim as fdm!? Indeed. I remembered that wrongly because the Seneca doesn't have a SenecaII-set.xml file, but only a SenecaII-jsbsim-set.xml, which is usually only done when there are more choices. (I have that shorter name as a line to the long one.) I [...] have removed most of the frequent-update listeners in my local copy. [...] At least my listener-loaded-code was not *that* bad: True, kind-of. But the reason why I found evidence for a bug in Nasal's garbage collector had nothing to do with the Seneca, or claims that listeners are slow. This was just because I worked on making FGBinding::fire() faster, as this was another point on Durk's blacklist. I use the node refcounter for the script cache's own garbage collector, so I printed it to the console, and the steadily increasing counter for the throttle binding property rang the alarm bell. :-) Although some of the listeners in the Seneca are used inefficiently, they were mostly bad because of that GC bug. Now that this is fixed, they are only unfortunate, but no longer evil. Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) For some of your listeners it may be enough to set the second optional argument to 0, so that the listener code is only triggered when the node value changes. Just turn on listener logging or put a print() message into it to see the costs. $ fgfs --log-level=debug 21|grep listener m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Heiko, I applied the patches to plib branch (I get runtime errors with FG link against OSG 2.2 that I haven't figured out): http://www.rato.us/flightgear/builds/plib/20071024plibexe.zip -Reagan On 10/23/07, Heiko Schulz [EMAIL PROTECTED] wrote: Hi, Couldn't test it, waiting that someones will do a precompiled binary for windows. But it sounds good, very good though at least there are still some perfomance issues. I think of AI and the loading of the scenery tiles. What Vivian is writing sounds for me like the stutters of loading of objects. If I use Random Objects FGFS is hardly to use, even I decrease the count of objects. It would be good if Vivian could send his choosen settings for comparing. HHS --- Georg Vollnhals [EMAIL PROTECTED] schrieb: Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? Regards Georg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 11:21, Melchior FRANZ wrote: [snip...] Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) This touches on the area that became a show-stopper for me and while it's good news to see some of the problems being chased down and cleared imho there are still some vital things that need to be addressed. The problem, as I see it, is that there are two different timing regimes in FG: the fixed rate FDM timing and the variable frame-rate timing. That is, the FDM operates at a fixed rate (I believe the default is 120 Hz) but nearly everything else, afaikt, operates at the frame rate, which varies. This means that if I'm trying to use Nasal (and the A/P PID controllers and filters) in a FBW framework not only do I need them to run at a specified fixed and non-varying rate but ideally I'd want them to run at the FDM fixed rate and in lock-step with it because if I just run these subsystems at the FDM fixed rate, but not locked to the FDM clock, they are likely to drift and I'd end up getting an effective rate that varied between the FDM rate and the FDM rate/2 as they drift into and out of synchronisation. Because 120 Hz isn't really that high, in the context of GHz processing speeds, I would have thought Nasal would be ok for this purpose but am I expecting too much of it? Perhaps the real problem is that nearly every other subsystem, apart from the FDM, get their turn on the CPU within the frame-rate loop and although this would seem to make obvious sense, because the graphics sub-system is by far the greatest user of resources, I'd suggest that if the other subsystems use so little of the available resources, giving them priority over the graphics would have a negligible impact on the frame rate, which is variable according to graphics load anyway. For example, if the graphics subsystem uses 95% of resources to produce 40 fps it's still likely to return 35 fps if it's only given 90% of resources (and anything much over 25-30 fps is wasted on human eyes anyway). Perhaps I'm just using the wrong approach but like I said, expecting 100-200 Hz rates doesn't seem too ambitious in the context of GHz processors. If, however, there are good reasons why Nasal can't run at these rates (and the A/P PID controllers and filters, being time based _need_ to run at fixed rates in any case), what would be the best solution? LeeE - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
This is starting to enter the realm of my own opinions so please keep that in mind. Nasal was never intended to do work at this low level. However, the fact that it can be used to successfully model an advanced flight control system [mostly successfully] says a lot about the capabilities of nasal and how tightly it's been integrated into FlightGear. Typically in a real time system you'd want to seriously consider coding stuff that runs often and at high rates of speed in native C/C++. If you did that, you would be able to tie your code into run at FDM rates. In my opinion, if someone can write advanced nasal code, it's only a small step beyond that to be able to write full fledged C code. Nasal is very C-like in many ways. Probably the biggest barrier for most people is going to be getting their development system setup properly so they can compile their new code additions or changes. Regards, Curt. On 10/24/07, leee wrote: On Wednesday 24 October 2007 11:21, Melchior FRANZ wrote: [snip...] Listeners should be used on properties to get notice about occasional changes. In cases where we *know* when the property changes -- once per loop or more often -- we can have the same result cheaper with a loop. (Listeners on YASim properties are special in that those can change several times per frame, and one may indeed want the listener triggered every time. But this should be a deliberate decision, not an accident.) This touches on the area that became a show-stopper for me and while it's good news to see some of the problems being chased down and cleared imho there are still some vital things that need to be addressed. The problem, as I see it, is that there are two different timing regimes in FG: the fixed rate FDM timing and the variable frame-rate timing. That is, the FDM operates at a fixed rate (I believe the default is 120 Hz) but nearly everything else, afaikt, operates at the frame rate, which varies. This means that if I'm trying to use Nasal (and the A/P PID controllers and filters) in a FBW framework not only do I need them to run at a specified fixed and non-varying rate but ideally I'd want them to run at the FDM fixed rate and in lock-step with it because if I just run these subsystems at the FDM fixed rate, but not locked to the FDM clock, they are likely to drift and I'd end up getting an effective rate that varied between the FDM rate and the FDM rate/2 as they drift into and out of synchronisation. Because 120 Hz isn't really that high, in the context of GHz processing speeds, I would have thought Nasal would be ok for this purpose but am I expecting too much of it? Perhaps the real problem is that nearly every other subsystem, apart from the FDM, get their turn on the CPU within the frame-rate loop and although this would seem to make obvious sense, because the graphics sub-system is by far the greatest user of resources, I'd suggest that if the other subsystems use so little of the available resources, giving them priority over the graphics would have a negligible impact on the frame rate, which is variable according to graphics load anyway. For example, if the graphics subsystem uses 95% of resources to produce 40 fps it's still likely to return 35 fps if it's only given 90% of resources (and anything much over 25-30 fps is wasted on human eyes anyway). Perhaps I'm just using the wrong approach but like I said, expecting 100-200 Hz rates doesn't seem too ambitious in the context of GHz processors. If, however, there are good reasons why Nasal can't run at these rates (and the A/P PID controllers and filters, being time based _need_ to run at fixed rates in any case), what would be the best solution? LeeE - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* leee -- Wednesday 24 October 2007:
the FDM operates at a fixed rate (I believe the default is 120 Hz)
but nearly everything else, afaikt, operates at the frame rate,
which varies.
Yes, but most Nasal code does things that influence visuals/sound
(like instrument stuff, view handling, etc.), so there's a natural
relationship with the frame rate. Tying Nasal to the frame rate
therefor makes sense. Otherwise we would probably see interference
artifacts ... good old jitter. :-)
Only FDM stuff would like to be tied to the FDM update rate, and
I think that's a desirable goal. What about a callback function
then? The FDM subsystem would set /sim/signals/fdm-update, and you
could attach a listener to that which does all the things that
should interact with the FDM, such as AP, FCS, etc. The rest of
Nasal would keep running with the frame rate.
There's just one (minor) problem at the moment. There's no generic
FDM update() function where one could put a sig.setDoubleValue(dt).
This would have to be done in all FDMs.
Interested aircraft would then do something like ...
setlistener(/sim/signals/fdm-update, func(n) {
var dt = n.getValue();
# ... and whatever needs to be done at fdm rate
});
m.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 18:30, Melchior FRANZ wrote:
* leee -- Wednesday 24 October 2007:
the FDM operates at a fixed rate (I believe the default is 120 Hz)
but nearly everything else, afaikt, operates at the frame rate,
which varies.
Yes, but most Nasal code does things that influence visuals/sound
(like instrument stuff, view handling, etc.), so there's a natural
relationship with the frame rate. Tying Nasal to the frame rate
therefor makes sense. Otherwise we would probably see interference
artifacts ... good old jitter. :-)
Only FDM stuff would like to be tied to the FDM update rate, and
I think that's a desirable goal. What about a callback function
then? The FDM subsystem would set /sim/signals/fdm-update, and you
could attach a listener to that which does all the things that
should interact with the FDM, such as AP, FCS, etc. The rest of
Nasal would keep running with the frame rate.
There's just one (minor) problem at the moment. There's no generic
FDM update() function where one could put a sig.setDoubleValue(dt).
This would have to be done in all FDMs.
Interested aircraft would then do something like ...
setlistener(/sim/signals/fdm-update, func(n) {
var dt = n.getValue();
# ... and whatever needs to be done at fdm rate
});
m.
The idea of an FDM callback function sounds as though it would work but
the A/P controllers and filters, which were the real problem, are
independent of Nasal and would remain a problem until they could
guarantee a fixed rate regardless of the frame rate. This is essential
for reliable operation because they are time based.
I think I really have to agree with Curt - a FBW subsystem would be
better written in C/C++ and perhaps Nasal isn't really suited to it,
although as I said in my reply to him, Nasal seemed ideal for trying
out untested ideas and developing a framework that could then be coded
in C/C++ and configured in xml.
LeeE
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* leee -- Wednesday 24 October 2007: the A/P controllers and filters, which were the real problem, are independent of Nasal and would remain a problem until they could guarantee a fixed rate regardless of the frame rate. The FDM doesn't run at a fixed rate, either, AFAIK. Yes, it runs 120 times per second (if so configured), but it runs all iterations for a frame one after the other, then waits until the next frame. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
FYI: this bug is now fixed in CVS, albeit in a different way, so it's a good idea to revert that last patch in your local copies. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 19:15, Melchior FRANZ wrote: * leee -- Wednesday 24 October 2007: the A/P controllers and filters, which were the real problem, are independent of Nasal and would remain a problem until they could guarantee a fixed rate regardless of the frame rate. The FDM doesn't run at a fixed rate, either, AFAIK. Yes, it runs 120 times per second (if so configured), but it runs all iterations for a frame one after the other, then waits until the next frame. m. Hmm... I always thought that it ran asynchronously from the rest of FG, at a steady rate. Surely this can't be a good thing? It really seems to me that the only subsystem in FG where variable timing won't cause a problem is the display, where it doesn't matter if you're seeing 25 fps or 60 fps, or anything in between. Heh - I am not a flight simulator scientist though ;) LeeE - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On 10/24/07, leee wrote: Hmm... I always thought that it ran asynchronously from the rest of FG, at a steady rate. Surely this can't be a good thing? It really seems to me that the only subsystem in FG where variable timing won't cause a problem is the display, where it doesn't matter if you're seeing 25 fps or 60 fps, or anything in between. Here's a quick explanation. The FDM runs at 120 hertz and with a fixed time step. However, we play one small trick to make that happen. We take the time that has elapsed since the last frame, compute how many whole iterations of the FDM will fit in that time slice (at 1/120th of a second per iteration.) Then we invoke the FDM that many times with a time step of 1/120th of a second. Finally we save out the remainder and add that into the next time slice. This can produce a small amount of temporal jitter between the graphics and the fdm if the graphics frame rates are not a diviser of 120. In the best case scenario, you've locked your graphics frame rate to 60 hz so the FDM runs exactly 2 iterations every time it is invoked and there is no temporal jitter at all, ever. One thing to keep in mind is that handing a different size time slice to the FDM every frame (and sometimes that time slice could be 1 second or more?) can lead to instabilities in the math. So our approach is intended to avoid that potential problem. As far as the FDM is concerned, it *is* running asyncronously, at a fixed time step. But, we are playing a little trick on the FDM (it doesn't care) in order to handle the unfortunate possibility of non-fixed and highly variable frame rates on PC hardware running consumer grade operating systems. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Wednesday 24 October 2007 19:41, Curtis Olson wrote: On 10/24/07, leee wrote: Hmm... I always thought that it ran asynchronously from the rest of FG, at a steady rate. Surely this can't be a good thing? It really seems to me that the only subsystem in FG where variable timing won't cause a problem is the display, where it doesn't matter if you're seeing 25 fps or 60 fps, or anything in between. Here's a quick explanation. The FDM runs at 120 hertz and with a fixed time step. However, we play one small trick to make that happen. We take the time that has elapsed since the last frame, compute how many whole iterations of the FDM will fit in that time slice (at 1/120th of a second per iteration.) Then we invoke the FDM that many times with a time step of 1/120th of a second. Finally we save out the remainder and add that into the next time slice. This can produce a small amount of temporal jitter between the graphics and the fdm if the graphics frame rates are not a diviser of 120. In the best case scenario, you've locked your graphics frame rate to 60 hz so the FDM runs exactly 2 iterations every time it is invoked and there is no temporal jitter at all, ever. One thing to keep in mind is that handing a different size time slice to the FDM every frame (and sometimes that time slice could be 1 second or more?) can lead to instabilities in the math. So our approach is intended to avoid that potential problem. As far as the FDM is concerned, it *is* running asyncronously, at a fixed time step. But, we are playing a little trick on the FDM (it doesn't care) in order to handle the unfortunate possibility of non-fixed and highly variable frame rates on PC hardware running consumer grade operating systems. Regards, Curt. Thanks for the explanation - I think I'll need a little while to get my head around the paradigm shift though:) I was under the impression that the FDMs got a constant/continuous 120Hz. Seems to work for the FDMs ok though:) On my 1.7 GHz Athlon XP+Nv6600 256MB based system I was getting anything between 45-20 fps, depending on the view I was using and what was in the background (I increased the visibility ranges over the default settings, so there was an additional performance hit there). Synching to vblank never made any difference here but with those frame rates I wasn't too surprised. LeeE - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Csaba Halász -- Tuesday 23 October 2007: In FGNasalListener::call the arguments are set up for the call. [...] These end up in naNewGhost, and finally [...] Umm, but the steady increase of refcounters also happens with simple Nasal bindings, where listeners aren't anywhere close. There's only NasalSys::handleCommand() and NasalSys::call() involved, but no naSave/naRelease/etc. (And in listeners the naSave is there to protect the callback function *code* from garbage collection, and this is necessary and can't be given up, as far as I understand. Or the listener function would just be removed, in which case it can, indeed, not cause any harm. But won't work, either. But again: this doesn't seem to be a listener problem, but a more generic one.) m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Sunday 21 October 2021:52, Melchior FRANZ wrote: Yes, but I think that the randomly appearing subsystems are only victims of other processes -- maybe the stuttering source (which would then have to be in another thread), but probably just other processes on the system, that just pull the CPU down. When the GUI only displays the frame rate in the lower right corner, then I don't see how this subsystem should vary its execution time. And he GUI is regularly in the Timing Alert list. Only without any pattern as far as I can see. The alerts just look like noise to me. m. I've been looking at this with the new timing code yesterday[1]. I still see the interval pausing, and it still seems to grow over time (although I didn't find the time yet to do a long enough flight to be certain). It does seem that GUI is one of those systems that shows increasing peaks in execution time, just like replay, and a few others that I don't recall by name right now. I fully agree that this is probably due to some other process, but I don't believe that it is random. Looking at the summary statistics, some subsystems continue to run very consistently, whereas other systems show this weird behavior. For that reason, we can exclude the possibility that it is caused by other processes on the system, because the source of the delay seems to be affecting very specific processes inside FlightGear. There is a pattern, as shown in these graphs, which I posted earlier: http://durktalsma.xs4all.nl/FlightGear/joystick-timing.png http://durktalsma.xs4all.nl/FlightGear/alloc-replaydata.png Execution time of these systems show gradually increasing peaks over time, interspersed by normal execution time. I suspect that this is a periodic halt as memory reallocation is taking place in another thread, but don't have firm evidence for that yet. The nasal / cmdarg () memory allocation problem could be the cause, but until we know for certain it might be worthwhile to study a few more cases. Such a memory reallocation might explain why a listenerless version[2] of the Seneca doesn't show the interval pause problem, whereas the version with listeners does[3]. Cheers, Durk [1] I hope to commit that sometime later this week / next weekend. [2] Downloadable from http://durktalsma.xs4all.n/SenecaNL.tar.gz (NL stands for No Listener). This is only a partionally functioning aircraft. I commented out all listeners in the Nasal code to see how that would affect performance. The aircraft is still flyable, but you need to switch on the magentos using the mouse, in order to get the engines started. [3] No offense to listeners intended. While researching the cause of the stutters, I've come across some very cool uses of them. Just trying to help to smooth out their performance. :-) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Csaba Halász -- Tuesday 23 October 2007: Attached patches to sg and fg seem to fix it if tested with Melchior's gctest.nas. BTW: In this script I used /input/joysticks/js/axis[3]/binding as an example for a binding that calls a Nasal function using cmdarg(). But if your axis[3] doesn't do that, then you may have misinterpreted the result of your patch. Not that I've tried it yet ... If I set /input/joysticks/js/axis[3]/binding/script to just 'print(x)', then the refcounter of the binding is not increased. When I set it to 'cmdarg()', then it is. (Normally, it's 'controls.throttleAxis()', which calls cmdarg(), too.) And again: that's only a binding, not a listener, so better don't focus too much on listeners. They trigger the problem as well, but the bug must IMHO be upstream. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi Casaba, On Tuesday 23 October 2007 04:53, Csaba Halász wrote: I am not familiar with the nasal system, so this might be completely wrong. Also, I am not sure this has anything to do with the stuttering. But it seems to be a memory leak, though. I just applied the two patches to my local source tree, and I am *very happy* to announce that the interval pauses are completely gone! I just finished one, about one hour long, test flight using the Seneca on a trajectory that would normally induce unbearable pausing after about 20 to 30 minutes. Not only did I not see any interval pauses, I also didn't see a single subsystem warning anymore (except for a few known cases). Like, Melchior, I believe that Andy should have a final look at your patch, but it seems like it is very close to fixing a very long standing bug. The important thing is that we've touched the very heart of the problem. This has been one of the tougher bugs to track down, but looking back, it's very rewarding to see it fixed. I'd really like to thank everybody who has contributed to the process. Cheers, Durk - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Tuesday 23 October 2007: The important thing is that we've touched the very heart of the problem. No, the important thing is that the bug was not in the listener code, as I said from the beginning. ;-) The Seneca is special in that it attaches listeners to YASim internal properties, which are updated multiple times per frame, unlike most other listeners, which run *at most* once per frame, but actually very rarely. I hope that the stuttering is fixed for all. And in any case should the Seneca fix its listener use. For example, by using on-change-only listeners, or using a simple loop which checks the interesting values once per frame. I'm available for consulting if necessary. :-) m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Csaba Halász schrieb: ... I am not familiar with the nasal system, so this might be completely wrong. Also, I am not sure this has anything to do with the stuttering. But it seems to be a memory leak, though. Hi Csaba, your patches did the trick, wonderful! Just as a feedback: after applying the diffs and compiling I made a long flight with the Seneca from EDDV (Hannover) to EDDW (Bremen) with two touch and go (to stress the system with many objects), along the river Weser and the coast to Cuxhaven, then landing at ETMN (Nordholz). There are really a lot (!) of objects placed at that route, mostly STATIC but also many SHARED ones due to the ongoing development. I started in EDDV with around 65 frames (due to a lot of objects from the nearly finished EDDV airport scenario), had a generally very smooth flight and landed after all that flighttime with 70 frames at Nordholz (only the scenery loading system caused some short framerate depressions, but that is another story). This is the practical proof for me that stuttering problem is solved!!! :-) Congratulations and thanks to you Csaba for finally solving it BUT ALSO to all the other developers who spent a lot of their time hunting after it. This is a nice day as not only a usable FlightGear for longer flights is reborn but it opens the door for the 0.9.11 release, many user are waiting for it as we have read over and over again the last months in the FG Forums. Georg EDDW - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? Regards Georg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi, Couldn't test it, waiting that someones will do a precompiled binary for windows. But it sounds good, very good though at least there are still some perfomance issues. I think of AI and the loading of the scenery tiles. What Vivian is writing sounds for me like the stutters of loading of objects. If I use Random Objects FGFS is hardly to use, even I decrease the count of objects. It would be good if Vivian could send his choosen settings for comparing. HHS --- Georg Vollnhals [EMAIL PROTECTED] schrieb: Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? Regards Georg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Melchior FRANZ -- Sunday 21 October 2007: Nasal's garbage collector (GC). It *has* a bug. That's not quite right. The GC might be OK, but it seems that it isn't invoked on cmdarg() nodes. I'll discuss that with Andy once he shows up on IRC again. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On 10/22/07, Melchior FRANZ [EMAIL PROTECTED] wrote:
That's not quite right. The GC might be OK, but it seems
that it isn't invoked on cmdarg() nodes. I'll discuss that
with Andy once he shows up on IRC again.
Don't know if Melchior and Andy have arrived at anything while I was
away, but here is what I found.
In FGNasalListener::call the arguments are set up for the call.
arg[0] = _nas-propNodeGhost(which);
arg[1] = _nas-propNodeGhost(_node);
These end up in naNewGhost, and finally in naNew where *the new object
gets stored in the temps list for the context*, prohibiting garbage
collection. Note that in FGNasalSys::call a new context is created for
executing the call, so while the comment for naTempSave says 'the
object is automatically released when the context next runs native
bytecode this actually never happens until the context is finally
freed. So new ghosts are created over and over again. Attached patches
to sg and fg seem to fix it if tested with Melchior's gctest.nas.
On second thought, a better fix would be to actually create the ghosts
in the context that will be executed. But I am not changing it now,
it's 5AM ;)
I am not familiar with the nasal system, so this might be completely wrong.
Also, I am not sure this has anything to do with the stuttering. But
it seems to be a memory leak, though.
--
Greets,
Csaba/Jester
Index: simgear/nasal/misc.c
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/nasal/misc.c,v
retrieving revision 1.9
diff -u -r1.9 misc.c
--- simgear/nasal/misc.c30 May 2007 22:49:41 - 1.9
+++ simgear/nasal/misc.c23 Oct 2007 02:46:24 -
@@ -26,6 +26,11 @@
c-temps[c-ntemps++] = PTR(r).obj;
}
+void naFreeTemps(naContext c)
+{
+c-ntemps = 0;
+}
+
naRef naObj(int type, struct naObj* o)
{
naRef r;
Index: simgear/nasal/nasal.h
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/nasal/nasal.h,v
retrieving revision 1.10
diff -u -r1.10 nasal.h
--- simgear/nasal/nasal.h 30 May 2007 22:49:41 - 1.10
+++ simgear/nasal/nasal.h 23 Oct 2007 02:46:25 -
@@ -46,6 +46,7 @@
// context next runs native bytecode. Useful for saving off C-space
// temporaries to protect them before passing back into a naCall.
void naTempSave(naContext c, naRef r);
+void naFreeTemps(naContext c);
// Parse a buffer in memory into a code object. The srcFile parameter
// is a Nasal string representing the file from which the code is
Index: src/Scripting/NasalSys.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Scripting/NasalSys.cxx,v
retrieving revision 1.95
diff -u -r1.95 NasalSys.cxx
--- src/Scripting/NasalSys.cxx 18 Oct 2007 11:43:38 - 1.95
+++ src/Scripting/NasalSys.cxx 23 Oct 2007 02:47:28 -
@@ -90,6 +90,7 @@
_callCount--;
if(_callCount) naModLock();
naFreeContext(ctx);
+naFreeTemps(_context);
return result;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Melchior FRANZ -- Thursday 18 October 2007:
The good news: I have a Nasal binding/script cache almost finished.
I don't know yet if it makes a huge difference, [...]
That's now finished and, as expected, makes firing of bindings between
20% and 90% faster. But I doubt that it will improve any stuttering
problem that some people have. (I still don't have *any* such problem.
I had in the past, and I've only changed the kernel version, libc, and
the nvidia driver since then. Same old crappy hardware.)
While working on the script cache, I noticed that Durk is right about
Nasal's garbage collector (GC). It *has* a bug. And Nasal listeners
trigger it just like keyboard/joystick bindings and possibly also
settimer() calls. I was quite surprised to see that the refcounter
of some SGSharedPtr nodes became bigger and bigger. Apparently Nasal
allocates them, but doesn't free them anymore.
Try the attached Nasal script. It prints every 5 seconds the number
of references to some nodes:
Right after startup:
5 /input/joysticks/js/axis[3]/binding # nasal js binding
24 /sim/current-view/view-number # some listeners attached
And after around hundred times moving the joystick's throttle lever
and a lot of switching the view, the number of node references is:
1067/input/joysticks/js/axis[3]/binding
1138/sim/current-view/view-number
So, Nasal has now over thousand unfreed references to the nodes.
And indeed, this matches a counter that I had added to nasal-props.cxx.
There are many more SGSharedPtr allocated than freed! Unfortunately,
Nasal internals aren't exactly my strong side, so I'll have to leave
that to Andy. :-)
m.
PS: the timing alerts are getting quite annoying. They pointed us to
some weak spots, but that's it. They will hardly help any further
to fix the stuttering problem. (And the warning code isn't exactly
written efficiently. It rather *contributes* to the problem. ;-)
var nodes = [
/input/joysticks/js/axis[3]/binding, # js throttle binding
/sim/current-view/view-number,# listener node
];
var loop = func {
foreach (var n; nodes)
print(n.getAttribute(refcount), \t, n.getPath());
print();
settimer(loop, 5);
}
settimer(func {
forindex (var i; nodes)
nodes[i] = props.globals.getNode(nodes[i], 1);
loop();
}, 0);
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hmmm That's now finished and, as expected, makes firing of bindings between 20% and 90% faster. But I doubt that it will improve any stuttering problem that some people have. (I still don't have *any* such problem. I had in the past, and I've only changed the kernel version, libc, and the nvidia driver since then. Same old crappy hardware.) So your FGFS runs totally smooth? When it is so easy, why have so much people problems with? And on different platforms? Some things I noticed this night working on the 737-300 in OSG: -the stutters gets more and worser, when starting in the air several times in a row. -approaching the ground increases the stutters too. Maybe a RAM-Problem, but I'm not sure. Just some notes HHS Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Heiko Schulz -- Sunday 21 October 2007: So your FGFS runs totally smooth? Basically, yes. Both branches. But of course, I get irregular stutters when some new object is to be loaded, because an MP-player joins in, or I approach KSFO and the Golden Gate bridge has to be loaded etc. But there's no interval freezing. (And I know the phenomenon very well. As I said, I had that myself a while ago. Funnily, nobody else could reproduce it back then. ;-) m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Melchior FRANZ wrote: * Melchior FRANZ -- Thursday 18 October 2007: The good news: I have a Nasal binding/script cache almost finished. I don't know yet if it makes a huge difference, [...] ..and the nvidia driver since then. Same old crappy hardware.) Just curious, what does old crappy hardware consist of? I ask because this seems more prevalent with people running high end systems (i.e. fancy graphics cards, dual core cpu's etc). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Laurence Vanek -- Sunday 21 October 2007: Just curious, what does old crappy hardware consist of? 2.4GHz P4, FX5500, 768 MB (I'd accept donations! ;-) m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Sunday 21 October 2007 11:10, Melchior FRANZ wrote: * Melchior FRANZ -- Thursday 18 October 2007: The good news: I have a Nasal binding/script cache almost finished. I don't know yet if it makes a huge difference, [...] That's now finished and, as expected, makes firing of bindings between 20% and 90% faster. But I doubt that it will improve any stuttering problem that some people have. (I still don't have *any* such problem. I had in the past, and I've only changed the kernel version, libc, and the nvidia driver since then. Same old crappy hardware.) Sounds good. As other people have commented, it seems like the better the hardware the worse the problem. While working on the script cache, I noticed that Durk is right about Nasal's garbage collector (GC). It *has* a bug. And Nasal listeners trigger it just like keyboard/joystick bindings and possibly also settimer() calls. I was quite surprised to see that the refcounter of some SGSharedPtr nodes became bigger and bigger. Apparently Nasal allocates them, but doesn't free them anymore. And after around hundred times moving the joystick's throttle lever and a lot of switching the view, the number of node references is: 1067/input/joysticks/js/axis[3]/binding 1138/sim/current-view/view-number So, Nasal has now over thousand unfreed references to the nodes. And indeed, this matches a counter that I had added to nasal-props.cxx. There are many more SGSharedPtr allocated than freed! Unfortunately, Nasal internals aren't exactly my strong side, so I'll have to leave that to Andy. :-) Okay, I'm at least glad we found something in that area. Hopefully Andy can shed some light on what might be going on. PS: the timing alerts are getting quite annoying. They pointed us to some weak spots, but that's it. They will hardly help any further to fix the stuttering problem. (And the warning code isn't exactly written efficiently. It rather *contributes* to the problem. ;-) Well, the idea was indeed to demote the alerts to a lower priority once we get the hang of what's going on. Once a few people can confirm that the growing interval pauses are gone, I believe we're ready for that. Until then, I would like to keep these warnings on alert status, however. While working on this, I do believe that having access to some sort of timing statistic is important for future program development. In an offlist discussion last week, Curt mentioned that once upon a time (probably preceding the subsystems manager, and the property tree) we had this possibility. I am working on reimplementing that idea for the subsystems manager, using a simple sample statistics class. The idea is to collect total execution time of each subsystem and keep track of mean / min / max execution time for each subsystem. I've been experimenting with that a bit this morning, and the results are interesting. Obviously, these statistics should only be collected and printed when explicitly requested (i.e. using an option / property). As for programming inefficiencies, time stamps are collected in a rather non-intrusive way, and printed after subsystem execution, so I don't see how that could contribute to the problem. Cheers, Durk - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Sunday 21 October 2007 13:37, Melchior FRANZ wrote: * Heiko Schulz -- Sunday 21 October 2007: So your FGFS runs totally smooth? Basically, yes. Both branches. But of course, I get irregular stutters when some new object is to be loaded, because an MP-player joins in, or I approach KSFO and the Golden Gate bridge has to be loaded etc. But there's no interval freezing. (And I know the phenomenon very well. As I said, I had that myself a while ago. Funnily, nobody else could reproduce it back then. ;-) FWIW, the plib branch has a cache that keeps track of already loaded AI models. Whenever a new model is needed (either by AI or by multiplayer), already loaded models are shared; otherwise a new model is loaded. The models are not persistent, however, so that once the model is no longer needed is gets unloaded. And of course, the next time somebody joins a multiplayer session with that aircraft, it has to be loaded again. ... Considering that we have many, many shared models, it might be an idea to add a similar model cache for non aircraft models. For AI Aircraft the model loading / unloading is very noticeable, and for some of the more complex buildings / structures / airports thats also the case. That would mitigate the loading strain for these models quite a bit. Making the cache persistent would be quite trivial, and probably further reduce the model loading stutters. The OSG branch doesn't have a caching mechanism, and if I understood Mathias correctly, that would also not be necessary. I've been experimenting with that a bit yesterday, and I'm not so sure anymore that is the case. I still need to double check my notes with Mathias. In the mean time, I've been working on adding an experimental model cache to the OSG branch for (AI/Multiplayer) aircraft, and it does seem to help reduce the model loading related stutters (at least on my laptop). Again, we could expand the same caching logic to the non aircraft models, and make the cache optionally persistent. Before going into that, however, I'd like to compare notes with Mathias. Cheers, Durk - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Sunday 21 October 2007: Well, the idea was indeed to demote the alerts to a lower priority once we get the hang of what's going on. Once a few people can confirm that the growing interval pauses are gone, I believe we're ready for that. I think they are now useless because they don't point anywhere that's related to the stuttering. They demonstrated that the replay system was slow. It's still slow, but better. And that firing bindings might have been slow. But I'm not convinced that these are causes for the stuttering. And the other subsystems get random appearances on the list, and it doesn't look like there's a pattern. As for programming inefficiencies, time stamps are collected in a rather non-intrusive way, and printed after subsystem execution, so I don't see how that could contribute to the problem. Heh, just my usual exaggerations, sorry. I just found it funny how the loop for iterating through the vector was written, in a function that deals with performance measuring. :-) But, alas, that's a general problem in fgfs. I guess we could save a frame per second or two, if we considered the usual dos and don'ts, like other projects do. (And I don't mean micro-optimization.) m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Sunday 21 October 2007: Considering that we have many, many shared models, it might be an idea to add a similar model cache for non aircraft models. We have that for shared models in plib: simgear/scene/models/modellib.cxx Those are never freed, though, so we don't do it for static models. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Sunday 21 October 2007 21:15, Melchior FRANZ wrote: I think they are now useless because they don't point anywhere that's related to the stuttering. They demonstrated that the replay system was slow. It's still slow, but better. And that firing bindings might have been slow. But I'm not convinced that these are causes for the stuttering. And the other subsystems get random appearances on the list, and it doesn't look like there's a pattern. FWIW, the new statistics based function is a bit more adaptive in that it only reports timing errors when subsystem execution time deviates a lot from the mean. I'm still fine tuning, but that way it should only trigger the warning in cases of exceptionally long pauses. As for programming inefficiencies, time stamps are collected in a rather non-intrusive way, and printed after subsystem execution, so I don't see how that could contribute to the problem. Heh, just my usual exaggerations, sorry. I just found it funny how the loop for iterating through the vector was written, in a function that deals with performance measuring. :-) But, alas, that's a general problem in fgfs. I guess we could save a frame per second or two, if we considered the usual dos and don'ts, like other projects do. (And I don't mean micro-optimization.) Haha, I sorta got that, let's just say I forgot to put a smiley behind my reply. :-) Admittedly, the vector loop is a bit of a make shift solution, but was actually done so that performance statistics could be collected and printed without interrupting the update function itself. Cheers, Durk - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Sunday 21 October 2007 21:21, Melchior FRANZ wrote: * Durk Talsma -- Sunday 21 October 2007: Considering that we have many, many shared models, it might be an idea to add a similar model cache for non aircraft models. We have that for shared models in plib: simgear/scene/models/modellib.cxx Those are never freed, though, so we don't do it for static models. Okay thanks. That's good to know. Cheers, Durk - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Sunday 21 October 2007: On Sunday 21 October 2007 21:15, Melchior FRANZ wrote: And the other subsystems get random appearances on the list, and it doesn't look like there's a pattern. FWIW, the new statistics based function is a bit more adaptive in that it only reports timing errors when subsystem execution time deviates a lot from the mean. Yes, but I think that the randomly appearing subsystems are only victims of other processes -- maybe the stuttering source (which would then have to be in another thread), but probably just other processes on the system, that just pull the CPU down. When the GUI only displays the frame rate in the lower right corner, then I don't see how this subsystem should vary its execution time. And he GUI is regularly in the Timing Alert list. Only without any pattern as far as I can see. The alerts just look like noise to me. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Melchior FRANZ -- Sunday 21 October 2007: Try the attached Nasal script. But before you do, change refcount to references. I just committed that to CVS to confuse everybody. :-) props.globals.getNode(/sim/aircraft).getAttribute(references) does now return the reference counter -- the number of co-owners of the shared pointer. This is really only useful for debugging. And here's again a summary of all the attribute names: children... returns number of children (faster than size(n.getChildren()!) listeners ... return number of attached listeners references ... returns number of co-owners (+ 2 for own consumption) tied... returns whether a node is tied (in which case listeners might not get triggered) alias ... whether the node is an alias to another node read... whether the node is read-protected write ... whether the node is write-protected archive ... whether the archive flag is set, which makes the node saved with Save Flight in the menu trace-read ... whether the node is being traced for read operations trace-write ... whether the node is being traced for write operations userarchive ... whether the node will be saved to ~/.fgfs/autosave.xml on exit m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Durk Talsma wrote: On Sunday 21 October 2007 13:37, Melchior FRANZ wrote: ... The OSG branch doesn't have a caching mechanism, and if I understood Mathias correctly, that would also not be necessary. I've been experimenting with that a bit yesterday, and I'm not so sure anymore that is the case. I still need to double check my notes with Mathias. In the mean time, I've been working on adding an experimental model cache to the OSG branch for (AI/Multiplayer) aircraft, and it does seem to help reduce the model loading related stutters (at least on my laptop). Again, we could expand the same caching logic to the non aircraft models, and make the cache optionally persistent. Before going into that, however, I'd like to compare notes with Mathias. The OSG branch does have a caching mechanism, although until recently not very much of the model structure was being cached. We do have to copy the scene graph nodes of an OSG model in order to support animation, and there is lots of room for optimization in deciding what parts of a model can be safely shared, but the geometry (and associated display lists), textures and graphics state are mostly being shared now. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHG7kJeDhWHdXrDRURAgJ8AJ94evGh1e2QlVj7Oy8ZEBOO6lj51ACeOkhj PhWnB7jx3RC4MIXH6WlhsaM= =xkz6 -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Sunday 30 September 2007: Secondly, there are a selected number of processes that take disproportionally long to execute. The most significant one I found sofar is a call in src/Input/input.cxx (around line 911). I have surrounded this statement by debug timestamp information: stamp(update_joystick_fire_prep ); a.bindings[modifiers][k]-fire(axis_values[j]); stamp(update_joystick_fire_end); Although the Nasal code in bindings is mostly simple and rather quick to parse, it should be noted that this is done again for every single fire() call. And in some joystick drivers there's some more sophisticated code, which could explain your results. If you look around with a digital hat and operate the throttle, there are oodles of Nasal recipes read in, parsed, and executed. The good news: I have a Nasal binding/script cache almost finished. I don't know yet if it makes a huge difference, but I guess it's desirable in any case. After all, there's a tendency to use more Nasal everywhere (which is a good thing!), and it's asked too much of users to know where Nasal code is cheap and where not. The Nasal cache re-parses the script when it was changed in the property tree, so we don't lose any flexibility. m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi Olaf, On Tuesday 02 October 2007 21:52, Olaf Flebbe wrote: Hi Durk, 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 I did some investigations in the past about memory consumption and found some small holes, where fixes may be only commited into the OSG branch. Okay. Are these fixed already? If not, I'd be happy to commit those. The tile data are never released if I remember correctly. I discussed releasing these data structures with Mathias but he warned me about having subtile negative side effects... I don't remember the details. I remember having a conversation about memory usage with Mathias, but I'm a bit fuzzy about the details. Earlier versions of FlightGear did delete tile related memory, but that could come at the cost of occasional Catching up on Tile delete cue alerts and very poor performance. If I'm correct, that error would be specific to plib though. I'd be interested to hear Mathias' arguments. Let me ask a stupid question: Is the stuttering a plib-only effect for you? What about stuttering in OSG? Apparently it's in both, but I've become more aware of it since I started a more specific investigation, which is plib based, due to the release preparation. Cheers, Durk - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Monday 01 October 2007 22:20, Durk Talsma wrote: 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 FWIW, I did run a short valgrind session. Execution time wasn't nearly as bad as I feared it would be. Couldn't get the seneca engines to start while running under valgrind though. I did a few international teleports, and closed FlightGear after about one hours. Valgrind reported over 800 cases of memory loss. I will probably try and fix some. Probably in random order, driven by whatever seems doable at the time. I just committed a fix for a tiny leak in multiplayer. Nothing significant, in terms of memory leakage, but at least it's one off the list. :-) Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi, It is in in OSG too - my first report was for OSG! Greetings HHS --- Olaf Flebbe [EMAIL PROTECTED] schrieb: Hi Durk, 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 I did some investigations in the past about memory consumption and found some small holes, where fixes may be only commited into the OSG branch. The tile data are never released if I remember correctly. I discussed releasing these data structures with Mathias but he warned me about having subtile negative side effects... I don't remember the details. Let me ask a stupid question: Is the stuttering a plib-only effect for you? What about stuttering in OSG? Cheers Olaf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
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/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Monday 01 October 2007: 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 wrote this on 2006/2/25 to fgfs-devel with subject Re: AI problems in CVS: | but if I fly in the bay area with AI turned on, then | fgfs starts to freeze in regular intervals after a few minutes | (intervals ~8 seconds, freeze time increases from ~0.1 to ~0.5 | seconds over time). ... and I assume that was shortly after I first encountered it. Of course, it could have been a different problem, but this has never disappeared. Well, except for the last few days where I couldn't reproduce it. :-) I do no longer claim that it's necessarily an AI traffic thing, but all the time there seemed to be a connection. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi,
It looks like I'm beginning to get a bit of a handle on the periodic hang-ups
appearing in FlightGear/Plib.
All tests ran on an AMD Athlon XP 2400+, 1024 MB ram, with a GeForce FX 5700
(256 mb texture ram IIRC) video card (AGP based). Suse Linux 10.2 is
installed, and FlightGear, SimGear, and plib were compiled using
gcc 4.1.2 20061115 (prerelease) (SUSE Linux)
Tests were conducted using the following settings in my .fgfsrc file:
--airport=EHAM
--time-match-local
--prop:/environment/params/real-world-weather-fetch=true
--fg-scenery=/home/durk/FlightGear-Scenery-0.9.10/
--fg-root=/home/durk/src/FlightGear-0.9/data-cvs
#--atlas=socket,out,1,localhost,5500,udp
#--nmea=socket,out,1,42.0.1.4,5501,udp
--verbose
--visibility-miles=25
--geometry=1280x1024
Using the SenecaII-jsbsim as aircraft, specified on the command line. Here are
some results.
Firstly, yesterday I managed to speed-up the replay system, by using dynamic
allocation instead of pushing copies of rather large objects into the STL
lists. Using the timestamping code I mentioned yesterday, and committed to
CVS earler today, I found that memory allocation was very slow on my machine.
By preallocating a significant number of replay objects, and recycling used
ones instead of reallocating them I managed to get minimize the amount of
replay timing errors considerably.
Secondly, there are a selected number of processes that take disproportionally
long to execute. The most significant one I found sofar is a call in
src/Input/input.cxx (around line 911). I have surrounded this statement by
debug timestamp information:
stamp(update_joystick_fire_prep );
a.bindings[modifiers][k]-fire(axis_values[j]);
stamp(update_joystick_fire_end);
and plotted the time it takes between the update_joystick_fire_prep
and update_joystick_fire_end stamps. The result is rather dramatic:
http://durktalsma.xs4all.nl/FlightGear/joystick-timing.png
X-axis displays the rank number of all FGInput calls with a timing Alert.
Y-axis shows the executiontime of the
a.bindings[modifiers][k]-fire(axis_values[j]);
line.
Thirdly, there is a relation between execution time and listeners, as proven
by the following experiment:
The heading indicator is one instrument showing frequent timing warnings. So I
also booby trapped the FGHeadingIndicator::update() function. Timing
information shows that it consistently takes about 4 usec to get from the
start of this function to the
_heading_out_node-setDoubleValue(heading);
line and than can take up to several ms or more to execute this statement.
That would be rather bizarre, because the update function also contains a
call to _offset_node-setDoubleValue(offset), which is executed within the
total of 4 useconds to execute the first function. That is, until I found
that the SenecaII has a listener attached to the property that
_heading_out_node refers to.
So I decided to do a little experiment: I copied the listener in
data/Aircraft/SenecaII/Nasal/hsi.nas, but set it to listen to offset-deg, the
property updated by _offset_node:
setlistener( /instrumentation/heading-indicator/offset-deg, func {
h = cmdarg().getValue();
v = h - aphb.getValue();
if( v 0.0 ) {
v = v + 360.0;
}
hsihb.setDoubleValue( v );
v = h - rad.getValue();
if( v 0.0 ) {
v = v + 360.0;
}
hsics.setDoubleValue( v );
});
Of course, the function as such doesn't make sense, but it would serve to
verify my hypothesis that if attaching a listener to a property slows its
execution, I would now expect to see that running the first half of the
function would take a lot longer. And this is indeed what happened:
Subsystem Timing Alert : 16032 instrument-8-heading-indicator
Getting to timestamp : HDG_06 takes 15936 usec.
Getting to timestamp : HDG_07 takes 91 usec.
Subsystem Timing Alert : 19071 instrumentation
Subsystem Timing Alert : 17724 instrument-8-heading-indicator
Getting to timestamp : HDG_06 takes 58 usec.
Getting to timestamp : HDG_07 takes 17655 usec.
When we remove the fake listener, _heading_out_node updating is consistently
fast again. One interesting observation from the above test, though, is that
the setDoubleValue() call is not consistently slow. So it's probably not the
listener itself, but probably an unexpected side effect we're dealing with.
I'm still hoping to find a common cause that can explain all of the stutters.
B.t.w., if you're interested, you can find the logfile of an about one hour
session here.
http://durktalsma.xs4all.nl/FlightGear/logfile
Cheers,
Durk
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Sunday 30 September 2007: Thirdly, there is a relation between execution time and listeners, Err ... Nasal listeners trigger Nasal code when the listened-to property is written to. Executed code costs cpu cycles. Anyone surprised? If listeners are used badly and trigger bad code, then this will, of course, hurt the framerate. But that's not because listeners are bad. The problem that I see in the Seneca is that several listeners are used on properties that are written to in every frame, which make no sense. That's a slow replacement for a simple Nasal loop. If you turn on listener logging, then you see a continuous flood of triggered listener code: $ fgfs --aircraft=SenecaII --log-level=debug 21|grep listener ... setting listener #50 in $FG_ROOT/Aircraft/SenecaII/Nasal/SenecaII.nas, line 269 setting listener #51 in $FG_ROOT/Nasal/aircraft.nas, line 216 setting listener #52 in $FG_ROOT/Nasal/aircraft.nas, line 216 setting listener #62 in $FG_ROOT/Aircraft/SenecaII/Nasal/SenecaII.nas, line 437 setting listener #63 in $FG_ROOT/Aircraft/SenecaII/Nasal/SenecaII.nas, line 438 setting listener #69 in $FG_ROOT/Aircraft/SenecaII/Nasal/hsi.nas, line 16 setting listener #79 in $FG_ROOT/Aircraft/SenecaII/Nasal/NLG.nas, line 66 setting listener #80 in $FG_ROOT/Aircraft/SenecaII/Nasal/NLG.nas, line 67 ... trigger listener #50 trigger listener #51 trigger listener #52 trigger listener #62 trigger listener #63 trigger listener #79 trigger listener #80 trigger listener #69 ... That's bad and the reason why I added listener logging. Listener should only be used on nodes that only change occasionally, as I've said numerous times. But I can't *force* people to use them correctly. :-} If you run the bo105 with turned on logging, you won't see a flood of triggered listeners (unless you move the mouse, #21 and #22). You'll only see them if some special event happens. Try that. It can't cause any stuttering. m. BTW: the two listener #51 and #52 are attached to light switches, and those aren't usually written to in every frame. In the Seneca they are, though ... :-) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Melchior FRANZ -- Sunday 30 September 2007: If listeners are used badly and trigger bad code, then this will, of course, hurt the framerate. But that's not because listeners are bad. I have to add, though, that the listener code in hsi.nas doesn't look particularly slow, so it shouldn't cause any problems. I checked if the properties that it writes to have listeners attached themselves, but that's not the case. There must be some other cause. /me scratching head m. :-/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi Durk,
Firstly, yesterday I managed to speed-up the replay system, by using
dynamic allocation instead of pushing copies of rather large objects into
the STL lists. Using the timestamping code I mentioned yesterday, and
committed to CVS earler today, I found that memory allocation was very slow
on my machine. By preallocating a significant number of replay objects, and
recycling used ones instead of reallocating them I managed to get minimize
the amount of replay timing errors considerably.
Concerning the replay subsystem, I also found what appears to be a c'n'p error
in FGReplay::init(), which results in the long term queue not being cleared.
Probably not significant in this case, though...
Index: replay.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Aircraft/replay.cxx,v
retrieving revision 1.5
diff -u -r1.5 replay.cxx
--- replay.cxx 21 Mar 2006 18:52:19 - 1.5
+++ replay.cxx 30 Sep 2007 16:30:50 -
@@ -76,8 +76,8 @@
while ( !medium_term.empty() ) {
medium_term.pop_front();
}
-while ( !medium_term.empty() ) {
-medium_term.pop_front();
+while ( !long_term.empty() ) {
+long_term.pop_front();
}
}
bye,
Manuel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Sunday 30 September 2007 17:14, Melchior FRANZ wrote: * Durk Talsma -- Sunday 30 September 2007: Thirdly, there is a relation between execution time and listeners, Err ... Nasal listeners trigger Nasal code when the listened-to property is written to. Executed code costs cpu cycles. Anyone surprised? Although most people will have a global idea as to what listeners are, I don't think that *that* many people are aware of the fact that the actual setValue function is the very same code that calls these Nasal functions. If you are not aware of this, it can be very puzzling why a seemingly simple function can take so long to execute. That was actually the triggering question for my little experiment, and this statement. On Sunday 30 September 2007 17:33, Melchior FRANZ wrote: * Melchior FRANZ -- Sunday 30 September 2007: If listeners are used badly and trigger bad code, then this will, of course, hurt the framerate. But that's not because listeners are bad. I have to add, though, that the listener code in hsi.nas doesn't look particularly slow, so it shouldn't cause any problems. I checked if the properties that it writes to have listeners attached themselves, but that's not the case. There must be some other cause. /me scratching head I'm still hoping that there is a common root cause for all this. I'm currenty investigating on the basis of a working theory that memory management is somehow involved. Yesterday, I noted that a simple new FGReplay statement was also showing intermittently long execution times, which seemed to grow over time. I didn't make plots, like I did for the joystick fire code, but will try to do that in a minute. If we see similar increases in execution time in a function like that, we know for sure it can't just be a single badly written piece of code. I actually wish it was that simple, so I could stop watching my hair turn grey. :-) Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Sunday 30 September 2007 18:43, Manuel Massing wrote: Concerning the replay subsystem, I also found what appears to be a c'n'p error in FGReplay::init(), which results in the long term queue not being cleared. Probably not significant in this case, though... Hi Manuel, Yes, I saw that too. It's actually fixed in CVS. Currently PLIB branch only, but I will port everything over to the OSG branch later. Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
* Durk Talsma -- Sunday 30 September 2007: Although most people will have a global idea as to what listeners are, I don't think that *that* many people are aware of the fact that the actual setValue function is the very same code that calls these Nasal functions. Ah, ok. Indeed, things can quickly get mysterious if you don't know that. :-) I'm still hoping that there is a common root cause for all this. Sigh. Yes, that would be nice. While I could cause the stutter problem reliably by activating AI traffic in the past, this is no longer the case. The only way to reproduce it now is to run MP, and I'm not sure if that's the same problem. Gahh ... I'm currenty investigating on the basis of a working theory that [...] I was so busy to defend my listeners, that I forgot to say: thanks for investigating all that. It's a lot of work and quite hard to do. All my attempts to find the cause failed so far. Unfortunately, we have lots of places where CPU cycles are wasted needlessly. One area is handling of STL containers. Other projects are much more careful with them and have strict policies. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
