Thorsten wrote in Thu Jan 16, 2020 7:58 pm:FPS decay is problem of the many models in the sim.
Funny - the simple ufo kills you off after 16 hours and people manage to do missions of a few days with the waaay more complex Shuttle? Fancy that.
Maybe you can help a little with the problem I'm trying to resolve.
The issue is that the sim works fine the first hour or so, as (sim) time passes there is one frame every two seconds that takes longer and longer. I monitor "max-frame-latency" and it starts at 30/60ms (depending on plane) and keeps rising to 150-200ms and more, which is not such a big deal when flying on the A/P but makes really annoying to fly a manual approach after a long flight because the sim "sticks" for this fraction of a second every 2 secs.
Originally I though it was a 737-800YV problem (is nasal-heavy and the code is pretty convoluted in some areas, also a WIP). But then I tested two more planes, the 707 which I had flown for hours many times in the past, and the aero-commander (Yasim).
The commander doesn't seem to exhibit this problem, not at least at a noticeable rate (I used time-compression and refill tanks to keep in the air for 8h.
The 707 does show the same problem but at a slower rate (it takes longer for this latency to increase to a noticeable rate). It's a less nasal-heavy aircraft and better optimised.
I have the feeling that it's related to some leak in nasal, I have gone through all the diagnostics here and in the wiki to no avail. I have reviewed the nasal code plenty of times but didn't find anything that could account for a leak. All timers and listeners are created in the global scope, I didn't find a function that could be spawning more timers or listeners by mistake.
Also in the 737 I tried to selectively disable nasal scripts. With a minimal subset of them, the problem doesn't appear or is not noticeable after 5h (also the avg fps is much better). But then as I slowly re-add the disabled nasal scripts, the problem appears and there is no individual script that could be blamed.
Now I want to build fgfs with some added debug info, mainly # of listeners installed and # of timers, but this is going to take a while.
Also the perf monitor shows plenty of hits for the events subsys, and it was running coupled with model-hz(120). I altered some listeners so that now it acts just once a frame but that didn't make the problem disappear. One thing to note is that the std.dev. column shows a high deviation value for events, 30ms or so, while others are sub-millisecond.