Re: [Flightgear-devel] Stuttering at 1 Hz rate
Since I don't follow the 'rule' by coding 10.000+ lines in Nasal, I suppose that is partially thrown into my direction. From where I stand, there are good reasons to use Nasal - first of all the userbase which regularly compiles their own code is small, whereas people do install addon packages - so I get a lot more feedback and test results. Second that one usually can't really crash the whole system from Nasal. Third, it's very easy to quickly try something and very maintenance-friendly. Fourth, you can actually start developing something without knowing how the core code ties together - which I suppose takes a lot of time to learn. And so on. Replace coding 10.000+ lines in Nasal by inventing a custom set of traffic laws. The justification would match almost in the same way, but nevertheless it's obstructive in both cases Huh? You seriously think that 'inventing a custom set of traffic laws' could be justified because doing so you can't crash the whole system? Where did you get your driver's license? :-) And where would the large userbase of that new set of traffic laws come from? One of your weaker jibes... :-) Best, * Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
FYI I'm currently looking at adding support for creating a 3D shader cloud using Nasal, to bypass the need to have XML wrappers etc. I'm hoping that this can off-load some of the low level quad-tree work you currently have to do. That's absolutely splendid news! If there's a hard-coded subsystem that can create, destroy and move clouds around, it would not only be useful for performance, but also conceptually: Essentially the quadtree forces you to move all clouds with the same speed (if they're allowed to drift within the quadtree and have to be resorted, then all goes to hell...) - but if that isn't needed, one can move clouds with the actual windfield and for example move high-altitude clouds faster than low-altitude clouds. So, let me think a bit what set of properties I'd think useful, and then I get back to you with that. Cheers, * Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
For the time being, we'll have to live with this. We should just be aware, that introducing too complex data structures and too heavy/complex computations in Nasal isn't a good idea. Even when their average execution time looks ok, they will eventually trigger noticeable frame rate jitters. The larger the data structures get, the longer the jitter. The more heavy the computation gets, the more often the garbage collector has to run, the more often the jitter happens... That seems to be very system dependent. I am running extensive Nasal computations, but I get the hardest framerate hits from the shaders - I can't use the terrain effect at all since it cuts my framerate from 70 to 10 if I fly over the wrong terrain type - way more troublesome than a short drop from 70 to ~55 when Nasal cleans up. So, it's still good to implement heavy stuff and common instruments in our FG core (C++), and use Nasal mainly for aircraft-specific animations etc. Though that may not be the direction our project is heading to right now... Since I don't follow the 'rule' by coding 10.000+ lines in Nasal, I suppose that is partially thrown into my direction. From where I stand, there are good reasons to use Nasal - first of all the userbase which regularly compiles their own code is small, whereas people do install addon packages - so I get a lot more feedback and test results. Second that one usually can't really crash the whole system from Nasal. Third, it's very easy to quickly try something and very maintenance-friendly. Fourth, you can actually start developing something without knowing how the core code ties together - which I suppose takes a lot of time to learn. And so on. The argument against that is essentially that C++ is faster than Nasal - which, everything else being equal, is certainly correct. But highly specialized Nasal code written for a particular problem outperforms general purpose C++ code - I've given several examples in the past. If someone were e.g. to add movement to Nasal spawned models by adding a velocity property, I'm not sure it would outperform my Nasal quadtree-sorted adaptive range code which priorizes movement for things actually inside the field of view. Of course, if you'd hard-code that specialized algorithm, it would be faster than the Nasal version - but then you couldn't apply it to other problems any more. But if people feel that things inside e.g. the Local Weather package (or somewhere else) should be ported from Nasal to C++ - by all means do so, don't just complain :-) You have the Nasal code available, I for one am entirely willing to explain to anyone who wants to hard-code something what certain things do and how things tie together - I'm just not going to do it myself. Cheers, * Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Sun, Mar 27, 2011 at 1:17 PM, Thorsten Renk wrote: But if people feel that things inside e.g. the Local Weather package (or somewhere else) should be ported from Nasal to C++ - by all means do so, don't just complain :-) You have the Nasal code available, I for one am entirely willing to explain to anyone who wants to hard-code something what certain things do and how things tie together - I'm just not going to do it myself. FYI I'm currently looking at adding support for creating a 3D shader cloud using Nasal, to bypass the need to have XML wrappers etc. I'm hoping that this can off-load some of the low level quad-tree work you currently have to do. This might allow us to either conver the Local Weather package to C code, or alternatively (and more likely?) move all Global Weather management code into Nasal so we can integrate them together properly. We should discuss exactly what API makes most sense for this. -Stuart -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
Hi,
here's a few more comments/hints/warnings on Nasal and simulation
performance in general.
First of all: it's not meant _against_ anybody. It's great to have a
tiny scripting engine in FG. It's great to have an option for custom
extensions. And we're certainly seeing very nice examples (absolutely
including ThorstenIR's local weather, since he brought that up).
I'm just making a point here that the Nasal engine does have
performance issues, which we should be aware of and care about.
When evaluating simulation performance, don't get fooled by the frame
rate. What's really important to us is the worst case frame latency.
Even if the system is producing a huge average of 100 frames per
second, it can still look absolutely crappy, if only a single frame
took more than 20-30ms, since that's immediately visible to the human
eye (note to self: add a worst case latency indicator). So, we're
building a real-time system here, and 20-30ms is our timing
constraint.
Nasal needs to run a garbage collection every now and then. This means
an extra delay, and may become noticeable, if it causes a frame to
violate the timing constraint. _When_ and _where_ in the Nasal code
the g/c triggers, is almost random, so you cannot attribute the g/c
delay to the point where it happened.
The effect depends on two properties: (1) how long does it take, and
(2) how often does it happen. These issues are triggered by different
properties of the code. If we can keep the delay below the limit,
everything is perfect. If we cannot, than we should at least reduce
its frequency. One stutter per minute may be acceptable. Once every
second looks absolutely intolerable (though you may still get a funky
100fps indication!).
1. The length of the delay depends on the number of references the
garbage collector needs to traverse: variables (data), but also
functions, which are just like variables in Nasal, e.g.
var myVariable = 42;
var myFunction = func()...
It doesn't depend on the size of a particular function or basic
variable though. The garbage collector needs to look and follow every
single reference to find out what's still in use. The delay is
proportional to the number of elements which were
loaded/initialized/created in Nasal. It hardly depends on the
length/complexity/frequency of Nasal computation though, since the
average number of references usually won't change too much.
I have instrumented the Nasal g/c to show the number of references
caused by generic Nasal scripts and by different aircraft (subtracting
the references caused by generic scripts) with current GIT:
39128 all generic stuff (i.e. fgdata/Nasal...)
3475 UFO
4788 c172p
6007 SenecaII
8283 B777-200ER
19270 F14
86122 Concorde
So, for most aircraft, the a/c specific Nasal is negligible. Time
consumed by garbage collection almost depends on generic stuff alone
(40K of references traversed in each run). Only some complex aircraft
significantly influence the g/c performance themselves, e.g. the
Concorde. It's ok if advanced models require advanced CPUs. But it's
not so nice with generic stuff, since it affects everyone and every
aircraft.
Currently, we load all fgdata/Nasal/*.nas at startup. Whether the code
is ever used or not, or a particular feature is disabled, doesn't
matter much. It's loaded and initialized, increases the number of
references, thus delays the g/c.
For the test above, I had _disabled_ multiplayer/wildfire/target
tracking/local weather/redout. The numbers hardly change when enabling
features though.
Since the local weather topic was mentioned: yes, it's large, but only
responsible for about 11K of references, so about 1/4 of current
generic Nasal stuff (when disabled).
2) The g/c frequency mainly depends on how much stuff is done in
Nasal, including the number of timers and the timer frequencies. So,
in contrast to (1), this very much depends on enabled features, and
strongly on specific aircraft (see Robert's email on frequency).
I also added instrumentation here to see how our generic stuff is
doing. There's several timers which run at full frame rate, even when
the related feature is disabled:
fgdata/Nasal/mp_broadcast.nas:146
fgdata/Nasal/redout.nas:93
fgdata/Nasal/wildfire.nas:506
fgdata/Nasal/track_target.nas:194
Even when they're almost doing nothing, it'd still help if they were
stopped or at least slowed down, when the related feature was
disabled. They affect garbage collection since a lot of (useless)
contexts are created and need to be cleared at some point - hence
triggering the g/c more often than necessary.
Typically many of our Nasal timer handlers look like this:
myTimer = func() {
if (getprop(/foo/feature/enabled))
{
...
}
settimer(myTimer, 0.0); // run again in next update loop
}
This would already improve things (20-100 times fewer contexts being
created/removed):
myTimer = func() {
if (getprop(/foo/feature/enabled))
{
...
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Sat, Mar 26, 2011 at 6:27 AM, Robert dogg...@googlemail.com wrote: Indeed the jitter is caused by Nasal's garbageCollect method. Simple test: add a printf (apply attached patch to simgear) and you should see the stutter is synchronized with it. True! The text is printfed with every jitter. Well, there is a workaround! Use a faster CPU :). I see a jitter of about 7ms with most aircraft. Wow 7 ms is very good. I hardly notice a 10 ms jitter, at full 75 fps. But something around 20 ms gets very prominent. However, the garbage collector does a complete scan of all Nasal objects to detect and remove unreachable elements. So, the more Nasal data elements we have, the worse the jitter gets. Large Nasal data structures will eventually break every CPU. And since it's done in the context of normal Nasal calls, and not in a separate background thread, it directly affects the duration of our main update loop - hence frame rate. Not so nice. Hmm. Other script languages rely on reference counting for garbage collection, which means much more stable performance. Python does that for example. But, well... GSoC anyone? ;-) Reference counting doesn't provide a strong performance advantage over conventional garbage collection, and a reference-counting scheme can take an unbounded amount of time. Reference counting schemes that do have real-time or bounded behavior are very complicated. I don't know much about our Nasal implementation, but I suspect that the garbage collector could be changed to trace only a portion of Nasal's heap at each invocation, at the risk of increased memory use. Python support would be a great feature I think. It is used in many products (e.g. in Blender) and that is a plus. However it's not guaranteed that it is free of such problems until you port all current Nasal scripts to Python and test it. What I am thinking about is a possibility to convert Nasal scripts to C or C++ and compile them as shared objects (.so .dll). Then we could load them dynamically at fgfs runtime. So in the end we get raw C/C++ performance to our modules. Is this possible or am I dreaming of something impossible here? What do you think? Why not write the modules in C++ to begin with? Tim -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 26.03.2011 06:27, Robert wrote: However, the garbage collector does a complete scan of all Nasal objects to detect and remove unreachable elements. So, the more Nasal data elements we have, the worse the jitter gets. Large Nasal data structures will eventually break every CPU. And since it's done in the context of normal Nasal calls, and not in a separate background thread, it directly affects the duration of our main update loop - hence frame rate. Not so nice. Hmm. Other script languages rely on reference counting for garbage collection, which means much more stable performance. Python does that for example. But, well... GSoC anyone? ;-) Python support would be a great feature I think. Well, yes. But changing current scripts would be a huge, huge project. And it'd would require much more maintenance than our tiny Nasal engine. It's a better option to improve the existing garbage collector (i.e. use reference counting, improve its speed, or make it happen less often). But that would also be a very complex change in a very sensitive area of our sources. What I am thinking about is a possibility to convert Nasal scripts to C or C++ and compile them as shared objects (.so .dll). Then we could load them dynamically at fgfs runtime. So in the end we get raw C/C++ performance to our modules. Is this possible or am I dreaming of something impossible here? Mainly dreaming. Such things may look simple at first. Easy to convert a simple hello world. But it's very complex when supporting all the features of an interpreted script language. And the funny thing is: you'd still need to worry about automatic garbage collection and count references (though that'd be a lesser issue compared to many others then). So, time wake up... For the time being, we'll have to live with this. We should just be aware, that introducing too complex data structures and too heavy/complex computations in Nasal isn't a good idea. Even when their average execution time looks ok, they will eventually trigger noticeable frame rate jitters. The larger the data structures get, the longer the jitter. The more heavy the computation gets, the more often the garbage collector has to run, the more often the jitter happens... So, it's still good to implement heavy stuff and common instruments in our FG core (C++), and use Nasal mainly for aircraft-specific animations etc. Though that may not be the direction our project is heading to right now... cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 26.03.2011 10:03, Tim Moore wrote: Reference counting doesn't provide a strong performance advantage over conventional garbage collection, and a reference-counting scheme can take an unbounded amount of time. Reference counting schemes that do have real-time or bounded behavior are very complicated. Well, the issue with scanning for unreachable objects is that it scales with the number of data elements in memory. Even when you aren't touching the data structures, they still affect performance. Reference counting itself doesn't guarantee real-time behavior, since removing any reference may result in deleting large data structures. But it's much more predictable and can be influence in the code. When certain code doesn't touch anything large, then it isn't affected. There are real-time systems which have successfully integrated a Python engine because of this. Though it doesn't guarantee hard real-time by the book, it still works very, very well, and only require few limitations (i.e. you have to avoid cyclic data structures, or accept that they are leaking). I don't know much about our Nasal implementation, but I suspect that the garbage collector could be changed to trace only a portion of Nasal's heap at each invocation, at the risk of increased memory use. Hm, not sure. The garbage collector uses mark sweep. It locks out any concurrent Nasal execution, marks all reachable elements, then removes everything unreachable, finally unlocks the engine. The expensive bit is the marking of all elements. It's hard to split such a task. You could abort the operation, but then later have to start all over again, to be sure that you've really traced all references. cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Sat, Mar 26, 2011 at 6:27 AM, Robert dogg...@googlemail.com wrote: Indeed the jitter is caused by Nasal's garbageCollect method. Simple test: add a printf (apply attached patch to simgear) and you should see the stutter is synchronized with it. True! The text is printfed with every jitter. Well, there is a workaround! Use a faster CPU :). I see a jitter of about 7ms with most aircraft. Wow 7 ms is very good. I hardly notice a 10 ms jitter, at full 75 fps. But something around 20 ms gets very prominent. However, the garbage collector does a complete scan of all Nasal objects to detect and remove unreachable elements. So, the more Nasal data elements we have, the worse the jitter gets. Large Nasal data structures will eventually break every CPU. And since it's done in the context of normal Nasal calls, and not in a separate background thread, it directly affects the duration of our main update loop - hence frame rate. Not so nice. Hmm. Other script languages rely on reference counting for garbage collection, which means much more stable performance. Python does that for example. But, well... GSoC anyone? ;-) Reference counting doesn't provide a strong performance advantage over conventional garbage collection, and a reference-counting scheme can take an unbounded amount of time. Reference counting schemes that do have real-time or bounded behavior are very complicated. I don't know much about our Nasal implementation, but I suspect that the garbage collector could be changed to trace only a portion of Nasal's heap at each invocation, at the risk of increased memory use. Python support would be a great feature I think. It is used in many products (e.g. in Blender) and that is a plus. However it's not guaranteed that it is free of such problems until you port all current Nasal scripts to Python and test it. What I am thinking about is a possibility to convert Nasal scripts to C or C++ and compile them as shared objects (.so .dll). Then we could load them dynamically at fgfs runtime. So in the end we get raw C/C++ performance to our modules. Is this possible or am I dreaming of something impossible here? What do you think? Why not write the modules in C++ to begin with? Tim AMEN!! JW -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Thu, 24 Mar 2011 14:33:45 +0100, Robert wrote in message AANLkTi=ev_fsxjcvn8jj7+aiav6hzj6pq6spbyrnn...@mail.gmail.com: --prop:/sim/rendering/multi-sample-buffers=true ..this segfaulted on my 3 day old git, will retest with todays. This maybe a problem with your graphics drivers. This option turns on Antialiasing. As I can see you use the R300 graphics drivers. Have you tried AMD's/ATI's proprietary driver? ..no, dependency conflicts last time I tried, they also require rebooting, and I've got a boot-up problem I'll need to fix next time, the last times, I had bios lock-ups for about 5 hours before it would boot up. Warm reboots with kexec works ok, but they require an ok working kernel to keep me from those 5 hour boots. ..once I have that bios fixed, there's also r300g and radeonhd. On hold until I have my other machines handy, I have new bios batteries if that's what's wrong, but I'm stuck in midair moving and need it open 24/7 for relocation offers and ideas. --enable-real-weather-fetch(will test without this one and report) ..pls do, I got a wee WTF moment with 12fps on start-up and 44fps airborne in replay, with --disable-real-weather-fetch and --fov=90. Tested without --enable-real-weather-fetch and there is no change. ..weird, but there was wind, some stratus and what looked like drizzle way SW of KSFO, on my last real weather try. Timing summary fornasal. - mean time: 0.04 ms. - min time : 0.00 ms. - max time : 2.05 ms. - stddev : 0.24 ms. I don't think we have to dig into nasal code like Franz suggested (please correct me if I'm wrong) because as you can see there is no significant amount of time spent in comparison to this: Timing summary for events. - mean time: 1.09 ms. - min time : 0.30 ms. - max time : 37.14 ms. - stddev : 4.24 ms. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
Indeed the jitter is caused by Nasal's garbageCollect method. Simple test: add a printf (apply attached patch to simgear) and you should see the stutter is synchronized with it. True! The text is printfed with every jitter. Well, there is a workaround! Use a faster CPU :). I see a jitter of about 7ms with most aircraft. Wow 7 ms is very good. I hardly notice a 10 ms jitter, at full 75 fps. But something around 20 ms gets very prominent. However, the garbage collector does a complete scan of all Nasal objects to detect and remove unreachable elements. So, the more Nasal data elements we have, the worse the jitter gets. Large Nasal data structures will eventually break every CPU. And since it's done in the context of normal Nasal calls, and not in a separate background thread, it directly affects the duration of our main update loop - hence frame rate. Not so nice. Hmm. Other script languages rely on reference counting for garbage collection, which means much more stable performance. Python does that for example. But, well... GSoC anyone? ;-) Python support would be a great feature I think. It is used in many products (e.g. in Blender) and that is a plus. However it's not guaranteed that it is free of such problems until you port all current Nasal scripts to Python and test it. What I am thinking about is a possibility to convert Nasal scripts to C or C++ and compile them as shared objects (.so .dll). Then we could load them dynamically at fgfs runtime. So in the end we get raw C/C++ performance to our modules. Is this possible or am I dreaming of something impossible here? What do you think? -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
With Thorstens patch I have identified the subsystem that causes that prob. It comes up at exactly the same rates that I posted earlier. It's the EVENTS subsystem. Timing summary for events. - mean time: 0.15 ms. - min time : 0.08 ms. - max time : 18.21 ms. - stddev : 0.81 ms. Thanks everybody for your help. So now we have to dig further. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
Is event_mgr.cxx the right place to look at? -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
* Robert -- Thursday 24 March 2011:
Is event_mgr.cxx the right place to look at?
Well, the main purpose of the event manager is to handle
Nasal's settimer() code. So you better look for slow recurring
Nasal code. You can redefine settimer() and let it output the
time spent. I can't test that at the moment, but it will be
something like this:
var orig_settimer = globals.settimer;
var globals.settimer = func(fn, interval, mode = 0) {
var start = systime();
var where = caller(1);
orig_settimer(fn, interval, mode);
printf((%.6f) settimer in %s:%s took %.6f s,
start, where[2], where[3], systime() - start);
}
This should show you lines like:
(10.345678) settimer in .../debug.nas:17 took 0.000290 s
(11.345670) settimer in .../screen.nas:68 took 0.004989 s
Then you search for particularly slow execution time and check
if it's in one-second intervals.
m.
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
Argh, no. Of course you want to know how much time the execution of
the function took, not the settimer call itself. So it'll be more
like this:
var orig_settimer = globals.settimer;
var globals.settimer = func(fn, interval, mode = 0) {
var where = caller(1);
orig_settimer(func {
var start = systime();
fn();
printf((%.6f) settimer in %s:%s took %.6f s,
start, where[2], where[3], systime() - start);
}), interval, mode);
}
m.
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Thu, 24 Mar 2011 03:05:28 +0100, Arnt wrote in message 20110324030528.55839966@celsius.local: On Wed, 23 Mar 2011 05:56:49 +0100, robert...@web.de wrote in message AANLkTimUGMjCn2y=FWw4Avt6tx_5d3M=ywxsetz6w...@mail.gmail.com: ..maybe Robert can tell us the FG command line etc recipe he uses to provoke the 1Hz stuttering? My machine specs are: Athlon64 X2 5200+ Samsung HDD Radeon HD 6850 (Had nvidia 8800 GTS before with the same stuttering issues) Debian unstable/experimental Kernels tested: 2.6.32 to 2.6.38 (no difference with stuttering issues) An old SoundBlaster 16 card ( i will try the --disable-sound parameter and report results later) I use GNOME as my desktop. (same here: will try to minimize autostart-programs in gnome-session-properties and report results later ) parameters I use: --enable-fullscreen --fov=60 ..I use --fov=90 and fullscreen routinely, usually 7 to 20fps, ..now 3 on start-up to 6 fps airborne, exiting kills X, so I'll have to play with bashist error redirections. An idea is offer error file options down the Debug menu tree. no stutter that I can see. --prop:/sim/rendering/multi-sample-buffers=true ..this segfaulted on my 3 day old git, will retest with todays. ..no change. --prop:/sim/rendering/multi-samples=4 ..no change, removing this keeps X alive. --enable-real-weather-fetch(will test without this one and report) ..pls do, I got a wee WTF moment with 12fps on start-up and 44fps airborne in replay, with --disable-real-weather-fetch and --fov=90. --timeofday=noon --callsign=Robert --disable-ai-traffic ..no change on these. Hardware is ATI Mobility FireGL V5200 on x.org's radeon, display is 1920x1200x32bpp@60Hz, full list: https://github.com/gasguru/flightgearthings/blob/master/lshw @ThorstenB Thanks, I will try the UFO and maybe alter some XML files later. What system configuration do you use? @Csaba It seems it doesn't matter what CPU or GPU one uses. So it could be the OS or some i/o stuff inside flightgear or OSG. What OS do you use? ..Debian Sid + Experimental ..xterm buffer tail with landing replay: The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. Subsystem Timing Alert, subsystem xml-autopilot: 10.6792ms Subsystem Timing Alert, subsystem events: 37.1354ms r300: ERROR: FS input generic 17 unassigned, not enough hardware slots. r300: ERROR: FS input generic 17 unassigned, not enough hardware slots. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. r300: ERROR: FS input generic 17 unassigned, not enough hardware slots. r300: ERROR: FS input generic 17 unassigned, not enough hardware slots. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. The climb rate cannot be higher than the true speed. Timing summary fornasal. - mean time: 0.04 ms. - min time : 0.00 ms. - max time : 2.05 ms. - stddev : 0.24 ms. Timing summary for gui. - mean time: 0.06 ms. - min time : 0.01 ms. - max time : 2.94 ms. - stddev : 0.33 ms. Timing summary for interpolator. - mean time: 0.01 ms. - min time : 0.00 ms. - max time : 0.23 ms. - stddev : 0.03 ms. Timing summary for time. - mean time: 0.04 ms. - min time : 0.01 ms. - max time : 0.90 ms. - stddev : 0.12 ms. Timing summary for replay. - mean time: 0.90 ms. - min time : 0.46 ms. - max time : 12.92 ms. - stddev : 1.72 ms. Timing summary for
Re: [Flightgear-devel] Stuttering at 1 Hz rate
--prop:/sim/rendering/multi-sample-buffers=true ..this segfaulted on my 3 day old git, will retest with todays. This maybe a problem with your graphics drivers. This option turns on Antialiasing. As I can see you use the R300 graphics drivers. Have you tried AMD's/ATI's proprietary driver? --enable-real-weather-fetch(will test without this one and report) ..pls do, I got a wee WTF moment with 12fps on start-up and 44fps airborne in replay, with --disable-real-weather-fetch and --fov=90. Tested without --enable-real-weather-fetch and there is no change. Timing summary fornasal. - mean time: 0.04 ms. - min time : 0.00 ms. - max time : 2.05 ms. - stddev : 0.24 ms. I don't think we have to dig into nasal code like Franz suggested (please correct me if I'm wrong) because as you can see there is no significant amount of time spent in comparison to this: Timing summary for events. - mean time: 1.09 ms. - min time : 0.30 ms. - max time : 37.14 ms. - stddev : 4.24 ms. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 24.03.2011 14:33, Robert wrote: Timing summary fornasal. - mean time: 0.04 ms. - min time : 0.00 ms. - max time : 2.05 ms. - stddev : 0.24 ms. I don't think we have to dig into nasal code like Franz suggested (please correct me if I'm wrong) because as you can see there is no significant amount of time spent in comparison to this: Timing summary for events. - mean time: 1.09 ms. - min time : 0.30 ms. - max time : 37.14 ms. - stddev : 4.24 ms. Robert, you should still look at Nasal. The event manager handles timers, and that's almost exclusively used by Nasal. Almost all the Nasal code runs in timers (except for property listeners). So read events as the total execution time for Nasal (timers). The timing data shown for the subsystem nasal only refers to the execution time of Nasal internal house keeping (i.e. some garbage collection), but not to the execution of actual Nasal code. Indeed misleading. The events subsystem is also showing a jitter on my machine (but not as bad). cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
you should still look at Nasal. The event manager handles timers, and that's almost exclusively used by Nasal. Almost all the Nasal code runs in timers (except for property listeners). So read events as the total execution time for Nasal (timers). The timing data shown for the subsystem nasal only refers to the execution time of Nasal internal house keeping (i.e. some garbage collection), but not to the execution of actual Nasal code. Indeed misleading. The events subsystem is also showing a jitter on my machine (but not as bad) Thanks for clarification. So I got my hands on the C172p and ripped it apart until there were only 2 files left with minimal jsb configuration: c172p-set.xml: # ?xml version=1.0? PropertyList sim descriptionCessna 172P Skyhawk (1981 model)/description authorDavid Megginson/author statusproduction/status flight-model archive=yjsb/flight-model aero archive=yc172p/aero model path archive=yAircraft/c172p/Models/c172p.xml/path /model /sim /PropertyList c172p.xml: ## ?xml version=1.0? fdm_config name=c172 version=2.0 release=BETA metrics /metrics mass_balance ixx unit=SLUG*FT2 948 /ixx iyy unit=SLUG*FT2 1346 /iyy izz unit=SLUG*FT2 1967 /izz ixy unit=SLUG*FT2 -0 /ixy ixz unit=SLUG*FT2 -0 /ixz iyz unit=SLUG*FT2 -0 /iyz emptywt unit=LBS 1500 /emptywt location name=CG unit=IN x 41 /x y 0 /y z 36.5 /z /location /mass_balance ground_reactions contact type=BOGEY name=NOSE location unit=IN x -6.8 /x y 0 /y z -19.5/z /location static_friction 0.8 /static_friction dynamic_friction 0.5 /dynamic_friction rolling_friction 0.02 /rolling_friction spring_coeff unit=LBS/FT 1800 /spring_coeff damping_coeff unit=LBS/FT/SEC 600 /damping_coeff max_steer unit=DEG 10 /max_steer brake_group NONE /brake_group retractable0/retractable /contact contact type=BOGEY name=LEFT_MAIN location unit=IN x 58.2 /x y -43 /y z -15.5 /z /location static_friction 0.8 /static_friction dynamic_friction 0.5 /dynamic_friction rolling_friction 0.02 /rolling_friction spring_coeff unit=LBS/FT 5400 /spring_coeff damping_coeff unit=LBS/FT/SEC 1600 /damping_coeff max_steer unit=DEG 0.0 /max_steer brake_group LEFT /brake_group retractable0/retractable /contact contact type=BOGEY name=RIGHT_MAIN location unit=IN x 58.2 /x y 43 /y z -15.5 /z /location static_friction 0.8 /static_friction dynamic_friction 0.5 /dynamic_friction rolling_friction 0.02 /rolling_friction spring_coeff unit=LBS/FT 5400 /spring_coeff damping_coeff unit=LBS/FT/SEC 1600 /damping_coeff max_steer unit=DEG 0.0 /max_steer brake_group RIGHT /brake_group retractable0/retractable /contact /ground_reactions aerodynamics /aerodynamics /fdm_config ## As you can see Nasal scripts aren't used at all. But still the following message is displayed in the console every 7 seconds or so: Subsystem Timing Alert, subsystem events: 28.2467ms Subsystem Timing Alert, subsystem events: 30.4909ms As I said earlier the jitter is dependent on the flight model. With jsbsim jitters are 6-8 seconds apart. Jitters are more frequent with yasim (1 - 4 seconds). With the UFO 21 seconds. (I was incorrect about the 41 seconds) But why does it show up in the events subsystem? Are flight-models interconnected with it somehow? -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 24.03.2011 23:54, Robert wrote: As you can see Nasal scripts aren't used at all. No, there are several generic Nasal scripts loaded independently of any aircraft configuration files. I checked my system and saw timers from the mp_broadcast.nas (which is also active when MP is disabled), wildfire.nas and several others. You also need to disable all scripts in fgdata/Nasal to get rid of all Nasal timers. Also, I had a brief look at exactly which Nasal timers caused a jitter. And the winner is... ... well, any. Any Nasal timer, even if it's almost empty, will every now and then consume a much larger amount of time than normal. Seems to be a general issue with the Nasal execution engine: could be triggered by Nasal's garbage collector, which every now and then needs to do extra work - and runs within the context of a normal Nasal call. It could also be a result of Nasal's critical sections: other threads may acquire a temporary lock to alter Nasal data structures - which may block the execution of Nasal timers at certain points. Hmm... Best practices for debugging a multi-threaded program anyone? :) Concerning the frequency of the jitter: I guess it isn't related to the FDM at all. It's probably just a result of Nasal complexity. The more Nasal code is running, the more often/likely garbage collection / blocking may occur. Frame rate may also influce it: many Nasal timers run at delay 0 (in every update loop). cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
I investigated further into the stuttering issue. I tried the UFO like ThorstenB suggested. Then I tried some other planes and found something interesting. There is regular stuttering with every plane I tested. But the interval between the stutters differs with every plane. See my results: C172p ~6.000 secjsbsim 747-400 ~5.100 secjsbsim 767-300 ~2.900 secyasim 777-200 ~4.000 secyasim Bravo ~1.300 secyasim ufo~41.000 sec All planes are from the git repositiry. What I can say is that yasim-planes seem to stutter more frequently than jsbsim-planes. With the ufo it's almost not noticeable unless you wait 41 seconds for the next stutter. @Csaba and others If you have time, could you please compare it with your numbers? I tested at LFML (Marseille) because I get good fps there. But any other place with good fps should be fine. The best thing to make the stutters more noticeable is to fly in the cockpit, fly a continuous steep turn in one direction (so you get a circle) and look to the ground. Use a stopwatch or use the clock on the panels of some planes. I wonder what may be the cause for these stutters. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
Hi, I've pushed an update to sg/fg/fgdata which enables a (so far well hidden) feature of our subsystem manager to capture timing statistics. It''s now configurable at run-time. Use Debug - Toggle Subsystem Statistics to enable/disable. It prints min/max/average and std-deviation for each of FG's subsystems to the console. The statistics interval is configurable via /sim/timing-statistics/interval-s Since there are a lot of submodules in FG (most of them are very friendly and don't consume much time), you can restrict the output to modules exceeding a certain minimum execution time - or a certain jitter (hey!). Use /sim/timing-statistics/min-time-ms and /sim/timing-statistics/jitter-ms to configure the filters (in milliseconds, obviously). Should help finding performance and jitter issues if they were caused by one of our internal subsystems. cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Wed, Mar 23, 2011 at 11:38 PM, ThorstenB bre...@gmail.com wrote: I've pushed an update to sg/fg/fgdata which enables a (so far well hidden) feature of our subsystem manager to capture timing statistics. I have found that feature earlier :) Also I have actually removed some subsystems, but to no avail. Let's see if somebody can produce other results. -- Csaba/Jester -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 23.03.2011 23:42, Csaba Halász wrote: I have found that feature earlier:) Also I have actually removed some subsystems, but to no avail. Let's see if somebody can produce other results. Yes, let's see what people come up with :). I actually see one submodule which produces some jitter. But I'm not a squealer. And my new machine is *very* fast... :) cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Wed, 23 Mar 2011 05:56:49 +0100, robert...@web.de wrote in message AANLkTimUGMjCn2y=FWw4Avt6tx_5d3M=ywxsetz6w...@mail.gmail.com: ..maybe Robert can tell us the FG command line etc recipe he uses to provoke the 1Hz stuttering? My machine specs are: Athlon64 X2 5200+ Samsung HDD Radeon HD 6850 (Had nvidia 8800 GTS before with the same stuttering issues) Debian unstable/experimental Kernels tested: 2.6.32 to 2.6.38 (no difference with stuttering issues) An old SoundBlaster 16 card ( i will try the --disable-sound parameter and report results later) I use GNOME as my desktop. (same here: will try to minimize autostart-programs in gnome-session-properties and report results later ) parameters I use: --enable-fullscreen --fov=60 ..I use --fov=90 and fullscreen routinely, usually 7 to 20fps, no stutter that I can see. --prop:/sim/rendering/multi-sample-buffers=true ..this segfaulted on my 3 day old git, will retest with todays. --prop:/sim/rendering/multi-samples=4 --enable-real-weather-fetch(will test without this one and report) --timeofday=noon --callsign=Robert --disable-ai-traffic ..no change on these. Hardware is ATI Mobility FireGL V5200 on x.org's radeon, display is 1920x1200x32bpp@60Hz, full list: https://github.com/gasguru/flightgearthings/blob/master/lshw @ThorstenB Thanks, I will try the UFO and maybe alter some XML files later. What system configuration do you use? @Csaba It seems it doesn't matter what CPU or GPU one uses. So it could be the OS or some i/o stuff inside flightgear or OSG. What OS do you use? ..Debian Sid + Experimental -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 22.03.2011 05:24, Robert wrote: Ingame (insim) I notice a small stutter that happens once every second. Did anybody of you guys notice the same thing? What can we do about it? I thought it might be something like a timed task. (reading from hard disc + malloc)? Please, could someone tell me where I can find this function in the source files? I don't see this issue here. Are you sure this isn't caused by another software on your machine? Some background service (indexing, virus scanner)? I don't think you'd be successful just by looking at the code. You could test if the effect happens with different planes, i.e. try the ufo. If it depends on the plane, try disabling specific instruments (modify the XML files), until you found the instrument causing the effect. Also check the plane's specific Nasal code: try to disable timer related tasks there, and see if this changes the effect. cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Tue, Mar 22, 2011 at 5:24 AM, Robert dogg...@googlemail.com wrote: Ingame (insim) I notice a small stutter that happens once every second. Did anybody of you guys notice the same thing? Yes I also see it on both of my machines (amd+ati, intel+nvidia) I have AI local traffic, traffic manager and replay disabled, too. What can we do about it? Don't know, I have so far failed to pinpoint the source of the problem. -- Csaba/Jester -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On Tue, 22 Mar 2011 16:54:52 +0100, Csaba wrote in message aanlktiksitdwffpudx_vjnuk+8npwhemwbfofoik7...@mail.gmail.com: On Tue, Mar 22, 2011 at 5:24 AM, Robert dogg...@googlemail.com wrote: Ingame (insim) I notice a small stutter that happens once every second. Did anybody of you guys notice the same thing? Yes I also see it on both of my machines (amd+ati, intel+nvidia) I have AI local traffic, traffic manager and replay disabled, too. What can we do about it? Don't know, I have so far failed to pinpoint the source of the problem. ..maybe Robert can tell us the FG command line etc recipe he uses to provoke the 1Hz stuttering? -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
..maybe Robert can tell us the FG command line etc recipe he uses to provoke the 1Hz stuttering? My machine specs are: Athlon64 X2 5200+ Samsung HDD Radeon HD 6850 (Had nvidia 8800 GTS before with the same stuttering issues) Debian unstable/experimental Kernels tested: 2.6.32 to 2.6.38 (no difference with stuttering issues) An old SoundBlaster 16 card ( i will try the --disable-sound parameter and report results later) I use GNOME as my desktop. (same here: will try to minimize autostart-programs in gnome-session-properties and report results later ) parameters I use: --enable-fullscreen --fov=60 --prop:/sim/rendering/multi-sample-buffers=true --prop:/sim/rendering/multi-samples=4 --enable-real-weather-fetch(will test without this one and report) --timeofday=noon --callsign=Robert --disable-ai-traffic @ThorstenB Thanks, I will try the UFO and maybe alter some XML files later. What system configuration do you use? @Csaba It seems it doesn't matter what CPU or GPU one uses. So it could be the OS or some i/o stuff inside flightgear or OSG. What OS do you use? -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
