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
