FMC constraints causes severe FPS issue

[Muchimi]

Disclaimer: This is under XP11 RC2 and I know the Ixeg 737 is not yet officially supported in that environment, which may be the reason I am having the issue below.

I've experienced a few times now and consistently a major frame rate issue only in the IXEG plane when I start placing altitude or speed constraints on legs in the FMC after reaching cruising altitude.  I do this fairly often to comply with ATC vectors or flight levels which may deviate from the default approach initially programmed into the FMC on the ground.

Taking a simple example, a flight from Salt Lake to Denver.  Here's the coroute:

KSLC CHE DIRECT FRNCH DIRECT BOENG KDEN

During pre-flight, I add the departure SID from KSLC for runway 16R, and add the arrival STAR at KDEN for 16R as well (via TOMS/KAILE3).

In this case, approaching TOMS from FRNCH and being directed to FL210, I set an altitude constraint on the waypoint via the entry of /210 on BOENG.  The moment the constraint is displayed, my FPS totally tanks from 35-40 to 4-8 almost immediately.

The buttons on the FMC become unresponsive the moment the entry is input, and it takes it a very long time (30 seconds or more) to execute (even for the light on the button to come up). The cursor on the EXEC button takes several seconds to change to the hand. Clearly, something's happening as the whole simulation is now a slideshow.

What's very odd is when I look at my CPU and GPU graph is my CPU utilization falls to about 10% and my GPU utilization falls to 6%.  It looks like nothing is happening at all and I have plenty of horsepower completely unused (which explains the FPS) but not why.  Normally I see 100% utilization on the XP thread, and between 60% to 99% utilization on the GPU for a FPS at my QHD resolution of about 35-45.  This happens in an outside view or inside view and I've now duplicated this with either an altitude constraint on any waypoint, or a speed constraint, or both, when apply to any portion of the flight plan, when in the air.   Works fine on the ground (as far as I can tell) - so changing that before a flight is not causing the issue.  Only in-flight.

I saw a post on antivirus software having to be disabled on the XP folder (which as an IT professional I find very strange as in this day and age, security should never be relaxed to fix a software or performance issue because of the risks it entails) but this had to do with adding or changing waypoints - which I'm not doing here - I'm only placing a constraint which only impacts the VNAV component.  I haven't tried disabling A/V on XP but will (very reluctantly).

I've also been able to reproduce on other flight plans and the performance issue is almost instant when a speed or vertical constraint is added in flight on any existing waypoint although I've only attempted to set speed and altitude constraints on the approach, so slower speed or lower altitudes.

This may be just my setup, the fact I'm running this plane in XP11 RC2, but it's done that before the RC2 update and I've been able to reproduce consistently to the point I now stay away from any VNAV changes and just don't use VNAV for approach descent control.   There's nothing I can do when the FMC starts to act up until I quit the flight.  Restarting the flight returns the normal FPS.

Hopefully one of the gurus here can help me explain what I'm doing wrong.

My addons are X-Enviro and World Traffic, I also have flywithLua and xassign, and ezpushback.  Disabling those does not fix the issue (looks to be completely unrelated).

I also have the EADT 738 and the add-on FMC for that and it doesn't cause that issue, only the IXEG FMC so far. 

Running Windows 10 x64, 16Gb memory @3.2GHz, Ryzen 1800X @4GHz, and a 1080 TI 11Gb card with a slight overclock, current Nvidia drivers, current WIndows patches and current XP RC2 as published on Steam.

Thanks!

 

 

Edited June 30, 2017 by Muchimi

[Tom Stian]

12 minutes ago, Muchimi said:

Disclaimer: This is under XP11 RC2 and I know the Ixeg 737 is not yet officially supported in that environment, which may be the reason I am having the issue below.

I've experienced a few times now and consistently a major frame rate issues only in the IXEG plane when I start placing altitude or speed constraints on legs in the FMC after reaching cruising altitude.  I do this fairly often to comply with ATC vectors or flight levels which may deviate from the default approach initially programmed into the FMC on the ground.

Taking a simple example, a flight from Salt Lake to Denver.  Here's the coroute:

KSLC CHE DIRECT FRNCH DIRECT BOENG KDEN

During pre-flight, I add the departure SID from KSLC for runway 16R, and add the arrival STAR at KDEN for 16R as well (via TOMS/KAILE3).

In this case, approaching TOMS from FRNCH and being directed to FL210, I set an altitude constraint on the waypoint via the entry of /210 on BOENG.  The moment the constraint is displayed, my FPS totally tanks from 35-40 to 4-8 almost immediately.

The buttons on the FMC become unresponsive the moment the entry is input, and it takes it a very long time (30 seconds or more) to execute (even for the light on the button to come up). The cursor on the EXEC button takes several seconds to change to the hand. Clearly, something's happening as the whole simulation is now a slideshow.

What's very odd is when I look at my CPU and GPU graph is my CPU utilization falls to about 10% and my GPU utilization falls to 6%.  It looks like nothing is happening at all and I have plenty of horsepower completely unused (which explains the FPS) but not why.  Normally I see 100% utilization on the XP thread, and between 60% to 99% utilization on the GPU for a FPS at my QHD resolution of about 35-45.  This happens in an outside view or inside view and I've now duplicated this with either an altitude constraint on any waypoint, or a speed constraint, or both, when apply to any portion of the flight plan, when in the air.   Works fine on the ground (as far as I can tell) - so changing that before a flight is not causing the issue.  Only in-flight.

I saw a post on antivirus software having to be disabled on the XP folder (which as an IT professional I find very strange as in this day and age, security should never be relaxed to fix a software or performance issue because of the risks it entails) but this had to do with adding or changing waypoints - which I'm not doing here - I'm only placing a constraint which only impacts the VNAV component.  I haven't tried disabling A/V on XP but will (very reluctantly).

I've also been able to reproduce on other flight plans and the performance issue is almost instant when a speed or vertical constraint is added in flight on any existing waypoint although I've only attempted to set speed and altitude constraints on the approach, so slower speed or lower altitudes.

This may be just my setup, the fact I'm running this plane in XP11 RC2, but it's done that before the RC2 update and I've been able to reproduce consistently to the point I now stay away from any VNAV changes and just don't use VNAV for approach descent control.   There's nothing I can do when the FMC starts to act up until I quit the flight.  Restarting the flight returns the normal FPS.

Hopefully one of the gurus here can help me explain what I'm doing wrong.

My addons are X-Enviro and World Traffic, I also have flywithLua and xassign, and ezpushback.  Disabling those does not fix the issue (looks to be completely unrelated).

I also have the EADT 738 and the add-on FMC for that and it doesn't cause that issue, only the IXEG FMC so far. 

Running Windows 10 x64, 16Gb memory @3.2GHz, Ryzen 1800X @4GHz, and a 1080 TI 11Gb card with a slight overclock, current Nvidia drivers, current WIndows patches and current XP RC2 as published on Steam.

Thanks!

 

 

Hello Muchimi..

You most likely need to make a exclusion on your AV-software. At least try temporary just to see if it solve your issue  

 

 

[Muchimi]

Yes - indeed not a solution especially after what just happened with wannacry and that other thing last week...   The answer is never compromise security to fix a software issue but I suppose the risk here is minimal.

 

[Cameron]

Yes - indeed not a solution especially after what just happened with wannacry and that other thing last week...   The answer is never compromise security to fix a software issue but I suppose the risk here is minimal.

 

Exclusions do exist for a reason.

[Muchimi]

5 minutes ago, Cameron said:

Exclusions do exist for a reason.

In my world there are no exclusions - just vulnerabilities waiting to be exploited, but I understand - I get way too into this security stuff as I see how many attempts are made daily to exploit holes and it's my profession to make sure there are no holes.

[mfor]

Muchimi has got a point though.

Not really sure why changing the route in flight would require such heavy AV activity - is the cause of this known?

If not, it might be worth looking into this and fixing the problem, as it isn't really reassuring to tell customers "exempt out program from AV or it won't run properly" unless it is somewhat comprehensible.

[mmerelles]

16 minutes ago, mfor said:

Muchimi has got a point though.

Not really sure why changing the route in flight would require such heavy AV activity - is the cause of this known?

If not, it might be worth looking into this and fixing the problem, as it isn't really reassuring to tell customers "exempt out program from AV or it won't run properly" unless it is somewhat comprehensible.

 

The IXEG bird runs ontop of gizmo plugin which is basically a scripting engine. When you perform a change on the fmc inflight, the fmc runs some scripts to keep recalculating the values until you hit EXEC (commit the changes). Windows defender tries to analyze that realtime getting 100% of the CPU for it and the simulation goes hell (the cpu is locked to defender, the gpu has nothing to do because the cpu is overloaded, you get a freeze or a 1/2 fps at best)

 

So don't be paranoid and put the exclusion, that feature is on windows defender for a reason as Cameron said. You are not excluding the unknown.

Edited June 30, 2017 by mmerelles
misspelling

[mfor]

Well "recalculating values" should not trigger any action of the AV program, nor should running scripts.

AVs are usually are only interested in verifying reads/writes of certain file types and some program actions that usually involve memory acrobatics and other rare stuff. So the question remains what triggers the AV activity and why is it not happening during the initial calculations.

Note: I'm not worried at all and have added the exclusion since I've first encountered the problem. 

However it irritates the programmer in me: I can't see a good reason why this process would need to do something that triggers the AV and thus it makes me feel there should be a way to do this without upsetting the AV. So fixing this or at least explaining why this is happening (and can't/won't be fixed) would at least satisfy my curiosity in the latter case and in the former case avoid the problem in the first place.

 

[Ben Russell]

43 minutes ago, mfor said:

Well "recalculating values" should not trigger any action of the AV program, nor should running scripts.

AVs are usually are only interested in verifying reads/writes of certain file types and some program actions that usually involve memory acrobatics and other rare stuff. So the question remains what triggers the AV activity and why is it not happening during the initial calculations.

Note: I'm not worried at all and have added the exclusion since I've first encountered the problem. 

However it irritates the programmer in me: I can't see a good reason why this process would need to do something that triggers the AV and thus it makes me feel there should be a way to do this without upsetting the AV. So fixing this or at least explaining why this is happening (and can't/won't be fixed) would at least satisfy my curiosity in the latter case and in the former case avoid the problem in the first place.

 

 

There are two things going on here.

Sub optimal programming. The task needs to be broken up into a manner more friendly to game engines.

JIT memory thrash. The scripts are subject to the LuaJIT processing which is what sends MS Defender crazy.

[mfor]

 Thank you, JIT compilation certainly explains why Defender jumps in and gets saturated when modifying the lua code frequently.

 

[Muchimi]

Update!

I have disabled A/V on the whole XP folder and things are back to normal.  In fact, disabling A/V altogether on the XP folder seems to give me a slight boost overall in FPS in XP 11 RC2 - about 1 to 2 FPS looks like although this is not very scientific - there is a slight uptick to my FPS logs in similar situations so I take it that the AV really takes a toll on the XP executables and plugin DLLs.

What I didn't connect is that I wasn't changing waypoints - just constraints - but I suppose it doesn't matter and any change to the route would cause this.

Very, very strange that all this FMC change architecture  would bring the whole computer to its knees without necessarily "pegging anything" in terms of performance management monitoring, but I thank you for the explanation as to what causes this.  I think the pinned post could be updated to say "if you get ANY FPS issue, try disabling the AV first".

Cheers,

M

Edited July 1, 2017 by Muchimi

[Poweer]

There are 2 topics on top of this section about this performance hit...

[Ben Russell]

3 hours ago, Poweer said:

There are 2 topics on top of this section about this performance hit...

The code involved is;

A; In Tom's hands, requiring his intimate knowledge of the FMC.

B; At the cutting edge of changes. Likely to be revised, renewed and generally re-worked from version to version.

 

This means that I can't fix it or optimize it.

1. Get it right.

2. Make it go faster

Fast code that produces wrong results is useless.

Teaching Tom to "shard" his code across frames by introducing a bunch of book keeping code will also make his life much much harder when it comes to debugging.

(and probably introduce a whole pile of secondary bugs related to sharding...)

[Poweer]

Ben,

 

it wasn't attack on You or other devs, it was a statement that it's at least third topic about performance hit during playing with FMC...

I'm perfectly fine with "exception in AV" solution. I know where it comes from and I'm happy with that...

[Ben Russell]

On 02/07/2017 at 2:10 AM, Poweer said:

Ben,

 

it wasn't attack on You or other devs, it was a statement that it's at least third topic about performance hit during playing with FMC...

I'm perfectly fine with "exception in AV" solution. I know where it comes from and I'm happy with that...

Sorry if I come across the wrong way. 

I'm not annoyed. I'm just sharing the technical realities.

It's something I'd definitely like to see fixed but it's a mult layer problem.

Being able to write an algorithm that works is easier than writing one that works in ever shrinking time slices.

(Where we usually had about 16ms to work with (60fps) we now have a target of about 8ms. (VR...))

Great fun and definitely part of the art of programming for game loops.

Edited July 3, 2017 by Ben Russell