Jump to content

FMC constraints causes severe FPS issue


Muchimi
 Share

Recommended Posts

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 by Muchimi
Link to comment
Share on other sites

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 :) 

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by mmerelles
misspelling
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

  • Upvote 1
Link to comment
Share on other sites

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 by Muchimi
Link to comment
Share on other sites

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...)

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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 by Ben Russell
  • Upvote 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...