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
[Flightgear-devel] FlightGear at NMS Museum of Flight, Scotland
Hi All, A while back I posted a note about demoing FlightGear at my local Museum of Flight, part of the National Museums of Scotland ( http://www.nms.ac.uk/museumofflighthomepage.aspx ). This was part of a wider discussion that I'd been having with them over the last year or so about using FlightGear within the museum as the basis of interactive exhibits. Yesterday I finished installing a system that the museum will be running themselves. The system is very straightforward, consisting of a PC, joystick and projector to simulate landing a Vulcan bomber at the museum. The museum will be running it as a staffed exhibit most weekends, and using it to gauge demand for future simulators. While I don't think the exhibit will be of much interest to the hardened FG fanatic on this list, I thought it worth mentioning some of the benefits that the museum saw in FG, and some hints for others involved in similar projects. Some of the key advantages that FG provided which made this possible were: A) Local scenery. FG already had pretty detailed scenery for the local area, including local landmarks, thanks to the models I'd put into the FG Scenery DB. I then augmented this by using Terragear to generate an improved airfield layout. This was a key requirement from the museum. Getting equivalent work done for MSFS was quoted at tens of thousands of pounds. B) Aircraft. I had already created a FG Vulcan, modelled after the museum's own airframe, so visitors were flying the aircraft standing outside. Very cool. FG also already had a large number of aircraft they had in their collection (include less well-known models such as the Seahawk), for future simulations. C) Tutorial System. This made it very easy to create a specific scenario for the museum, complete with instructions. D) Nasal. The capability this provided was immense, from being able to mute the sound when the simulation was waiting for a new visitor, to displaying instructions on the screen. For those interested in doing a similar project for their local flight museum, here are some things I've leaned over the course of the project so far: A) Tie it to the museum. The museum were keen that the simulation should tie into the museums collection, and the museum itself. In this instance we simulated an actual historic event at the airfield - the delivery of the Vulcan XM597 to the museum. This provided an opportunity to show the airfield and the surrounding countryside from the air, and give the visitor a chance to see inside the cockpit of an aircraft they couldn't normally access. B) Make it short. The landing simulation takes about 1 minute to run. This allows high visitor throughput and stops people from being bored. C) Make it simple. Too many controls will confuse the visitor - target it at Joe Public rather than a flight sim buff. For the landing simulation the visitor only has a joystick for control - a scripted co-pilot handles throttles, air-brakes, drogue chute etc. D) Make it easy. We had around 70% of visitors land the Vulcan successfully first time. This means they get a positive experience, and keeps throughput high as they don't need to re-try! Regards, -Stuart ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - 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
[Flightgear-devel] compile error
Hello all , I just tried to recompile the PLIB version , and now Im getting ... In file included from environment_mgr.cxx:36: environment_ctrl.hxx:142:9: error: too many decimal points in number In file included from environment_mgr.cxx:36: environment_ctrl.hxx:137: error: expected unqualified-id before ‘’ token environment_ctrl.hxx:140: error: expected unqualified-id before ‘==’ token environment_ctrl.hxx:142: error: expected unqualified-id before ‘’ token which led me to this in environment_gtrl.hxx , though I don't know if its an error or intentional ... // LessThan predicate for bucket pointers. static bool lessThan(bucket *a, bucket *b); === static bool lessThan(bucket *a, bucket *b); 1.25.2.4 }; Anyone else getting errors like this ? -- SydSandy [EMAIL PROTECTED] - 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
