Question about CPU priority of mce.exe

[KingGhidorah 209]

Hi,

 

I was having some problems where the F.O. was having these massive pauses in his flows, even though the "pause" in between commands in the script was set to 1 or 2.  Sometimes he would pause for a full minute or two before going on to the next thing, and it was really starting to impact the flight.

 

I changed the CPU Usage slider in the GUI around and didn't see any improvement.  I have no idea where to set it for optimal performance.

 

Finally, I went in and forced the processor priority of mce.exe to HIGH.  On my machine, FSX normally runs at ABOVE NORMAL.  I don't know if this will benefit anybody else by knowing this information, and I'm unclear if there is any downside to doing this.  It seems to improve things, and I don't have any more lags.  I have yet to do thorough tests to see if FSX itself will experience lags in certain situations as a result.  I guess it's a tradeoff.  For what it's worth, I had to do this with other programs such as Reality-XP and Ezdok as well, or otherwise those will experience lags and stutters, but I have no discernable ill effects from setting them to run one notch higher than FSX.

 

But then, what is the proper way of using the CPU usage slider in the GUI?  What does it do?  I have it set to the default value of about 1/3, but I can't find anything in the documentation that tells me any more about what it is doing.  Can you (FS++) explain this a little more, please?

 

Really excellent program, by the way, and certainly breathing a lot of new life into my sim, which had become rather stale as of late.

[FS++ 707]

Hi,

 

I was having some problems where the F.O. was having these massive pauses in his flows, even though the "pause" in between commands in the script was set to 1 or 2.  Sometimes he would pause for a full minute or two before going on to the next thing, and it was really starting to impact the flight.

 

I changed the CPU Usage slider in the GUI around and didn't see any improvement.  I have no idea where to set it for optimal performance.

 

Finally, I went in and forced the processor priority of mce.exe to HIGH.  On my machine, FSX normally runs at ABOVE NORMAL.  I don't know if this will benefit anybody else by knowing this information, and I'm unclear if there is any downside to doing this.  It seems to improve things, and I don't have any more lags.  I have yet to do thorough tests to see if FSX itself will experience lags in certain situations as a result.  I guess it's a tradeoff.  For what it's worth, I had to do this with other programs such as Reality-XP and Ezdok as well, or otherwise those will experience lags and stutters, but I have no discernable ill effects from setting them to run one notch higher than FSX.

 

But then, what is the proper way of using the CPU usage slider in the GUI?  What does it do?  I have it set to the default value of about 1/3, but I can't find anything in the documentation that tells me any more about what it is doing.  Can you (FS++) explain this a little more, please?

 

Really excellent program, by the way, and certainly breathing a lot of new life into my sim, which had become rather stale as of late.

 

Thanks for the accolade.

 

If you click the blue "?" icon and follow that with a click on any item on the user interface, you should hear an audio explanation about what the item does.

 

The CPU slider is the amount of CPU power you decide to allocate to the speech recognition engine. 

 

You may think the maximum value is the way to go, unfortunately it's not that simple. Based on years of experience with the speech engine, it appears the more resources you give it, the more probabilities it computes ending sometime with the speech engine hesitating between two possible recognitions and not returning success. Default values should work fine for the majority of users.

 

The scripted flows are executed on a low priority background thread. And yes, if FSX process priority is raised it may impact on those threads. Don't forget, when FSX runs in full screen mode, Windows will boost FSX thread priorities even if the process is in normal priority. I think you should leave FSX at normal priority.

 

Be aware, with option "Enable optimizations" switched on, MCE will set its affinity to avoid executing on specific cores depending on the CPU.

 

For a dual core CPU, MCE will stay clear of core 0

For a quad core CPU, it will stay clear of cores 0 and 1

 

If you have a heavily fine tuned sim with custom affinity mask, you may want to disable the MCE "optimizations" and let the OS decide where the MCE threads run. You may want to also make sure Hyperthreading is disabled so that all threads execute on physical cores rather than logical ones.

[KingGhidorah 209]

I may have spoken too soon when I declared I had a workaround (with the high pri thing).  It seemed to have some promise on some less resource demanding aircraft, but it didn't work at all on the NGX, and it didn't work for anything tonight.  Still getting massive lags with all the crucial flows--flows that should take 30 seconds are taking up to 2 minutes, and that is really bad, especially for things like before-landing flows.

 

Therefore I'm back to square one. :( I'm no longer messing around with the processor priorities and have simply been trying to find the optimal position of the cpu usage slider, and also experimenting with the Optimizations tickbox on or off as you've suggested.  No luck.

 

I can't think of what kind of a problem this might be other than that the Flow Scripts are just getting starved of the cpu cycles they need to run in a timely manner, even though there appears to be resources to spare.  As much as I love having a copilot be able to set all the things by direct command, and it's working extraordinarily well, I also want to get the automated flow parts working just as well too. Has anybody else ever reported similar problems?  Any suggestions as to what the next step I might take?

 

Machine is: 990x, 4.3ghz, 6 core, 6g of fast memory, Win7x64.  Hyperthreading is disabled.  Machine is totally devoted to, and very optimized for FSX, and it runs it well under almost all circumstances.  Always run in full screen mode.  Also alongside FSX are Track-IR, Acufeel, and ezdok.  Weather program and other stuff is run on a networked machine, so that shouldn't be a problem. MCE is version 2.5.3.8, the latest.

[WR269 367]

Not sure, I run quite a few program's in the background, inc,using MCE and have to fps impact whatsoever. Maybe reinstall or refresh?

[KingGhidorah 209]

Not sure, I run quite a few program's in the background, inc,using MCE and have to fps impact whatsoever. Maybe reinstall or refresh?

 

I don't have any fps impact whatsoever either. Something like the NGX or the md-11 run at their normal 30 locked fps just like they normally do. The issue is that MCE will suffer massive pauses when it is running a VoxScript, and I'm pretty sure it is, as FS++ said, because those VoxScripts are set to run at a low priority background task.  They are not getting the CPU cycles they need, and the CPU Usage slider on the GUI is not helping.  I even tried something called Process Lasso, which is a third party CPU scheduler, and it didn't do anything better than the standard scheduler. If this is indeed what is going on, I'm not sure there is anything I can do about it, as my machine is already as well-tuned as I know how to make it.   Since I don't know anything about multi-threaded programming, I'm in no position to know whether something could be further optimized on the developer side or not, but I'm almost positive that there is little I can be doing better on my side.   I'm certainly open to all suggestions though as to what else could be going on, because I really like this program and want it to perform as good for me as it apparently does for most others.

[FS++ 707]

I don't have any fps impact whatsoever either. Something like the NGX or the md-11 run at their normal 30 locked fps just like they normally do. The issue is that MCE will suffer massive pauses when it is running a VoxScript, and I'm pretty sure it is, as FS++ said, because those VoxScripts are set to run at a low priority background task.  They are not getting the CPU cycles they need, and the CPU Usage slider on the GUI is not helping.  I even tried something called Process Lasso, which is a third party CPU scheduler, and it didn't do anything better than the standard scheduler. If this is indeed what is going on, I'm not sure there is anything I can do about it, as my machine is already as well-tuned as I know how to make it.   Since I don't know anything about multi-threaded programming, I'm in no position to know whether something could be further optimized on the developer side or not, but I'm almost positive that there is little I can be doing better on my side.   I'm certainly open to all suggestions though as to what else could be going on, because I really like this program and want it to perform as good for me as it apparently does for most others.

 

Agree, it’s very likely a case of a thread being starved of CPU time.  And it appears to be caused by the fact you are overriding all the various processes priorities.

 

Suggest you run everything at their native process priorities (including EZDock). See if you experience any of that.

 

If you become a registered user, we don’t mind giving you some options (via mce.ini) to increase the Voxscript thread priority in order to accommodate your specific usage scenario.

 

Multi-threading is extremely complex and is the main reason why even after 8 years of development, we always find something that needs to be improved on. Things aren’t happening in sequence, threads need to acquire and release locks. There is room for lockups and race conditions, something you don’t see on a single threaded application.

 

Now, you may wonder why we are running MCE as an external application, when we could have made it run inside the simulator, via our “fsInsider.dll”.

 

In early days we did so, but quickly realised it’s not a safe thing to do. The speech engine and the audio dlls alone will gobble-up about 500 MB of the precious virtual address space, whose 4 GB limit is often the cause of many CTDs (remember FSX is still a 32 Bit process).

 

We would have to heavily restrict what the user says, to avoid scenarios where a single unexpected voice command brings the whole simulator down, never mind the fact that over a long period of time, the speech engine might leak memory or become unresponsive leaving you with a crippled FO with no option but to restart the flight.

 

With the current design, should anything wrong happen with our app, the integrity of the flight, which is the most important thing, shall never be compromised as a result of MCE or the speech engine. It’s bad enough for FSX to deal with issues thrown at it by sceneries, weather and aircraft add-ons which don’t have the luxury to decide where they run.

[KingGhidorah 209]

Thanks FS++.  At the start of this thread, I had said I was changing the process priority of several things.  Maybe I wasn't clear earlier, but since that time, however, I have reverted to running everything at their Native priorities, just as you had suggested--I am not running anything (not FSX, ezdok, TrackIR, or anything else) at any forced priority as of now, but the problem has persisted.   My product is payed for, licensed, and activated, so if there are unique solutions available within the mce.ini, it's definitely time for me to try them out.   I did encounter the problem during the demo period, but I went ahead and gambled on the purchase anyway, hoping that there is something I can still do.

 

Regarding deadlock conditions in CPU scheduling, I once heard someone use the analogy of an archaic law from the 1800's.  It said, "When two trains meet at a rail intersection, neither one shall move until the other one has left."

[FS++ 707]

Thanks FS++.  At the start of this thread, I had said I was changing the process priority of several things.  Maybe I wasn't clear earlier, but since that time, however, I have reverted to running everything at their Native priorities, just as you had suggested--I am not running anything (not FSX, ezdok, TrackIR, or anything else) at any forced priority as of now, but the problem has persisted.   My product is payed for, licensed, and activated, so if there are unique solutions available within the mce.ini, it's definitely time for me to try them out.   I did encounter the problem during the demo period, but I went ahead and gambled on the purchase anyway, hoping that there is something I can still do.

 

Regarding deadlock conditions in CPU scheduling, I once heard someone use the analogy of an archaic law from the 1800's.  It said, "When two trains meet at a rail intersection, neither one shall move until the other one has left."

 

:lol:  :lol:

 

Nice one!

 

Apologies for wrongly assuming you were running the Demo.

 

You may well be onto something after all.

 

Ben has just confirmed there is something that may corroborate your observation.

 

It's more likely to affect scripts that have "reset trim" as part of the flow.

 

Hopefully a fix will follow before the week-end.

 

Thank you

[KingGhidorah 209]

 

 

It's more likely to affect scripts that have "reset trim" as part of the flow.

 

Hopefully a fix will follow before the week-end.

 

 

 

This is good news!  One of the things I noticed on the NGX, and I don't know how much it helps, is that any script involving the Runway Turnoff Lights and/or Taxi Lights also tend to make the FO go temporarily dormant. I don't believe I've actually run any Voxscripts that had reset-trim as part of the flow.  I've done some initial run-throughs with the md-11 and the J-41, but not any complete flights from start to finish, so I can't identify any particular places that they have problems. 

[KingGhidorah 209]

----meant to post in another thread, deleted---

[FS++ 707]

This is good news!  One of the things I noticed on the NGX, and I don't know how much it helps, is that any script involving the Runway Turnoff Lights and/or Taxi Lights also tend to make the FO go temporarily dormant. I don't believe I've actually run any Voxscripts that had reset-trim as part of the flow.  I've done some initial run-throughs with the md-11 and the J-41, but not any complete flights from start to finish, so I can't identify any particular places that they have problems. 

 

New package now ready for download.

 

 

http://www.multicrewxp.com/Downloads.html

[KingGhidorah 209]

I'm sorry to have to report this FS++. but using the new version 2.5.3.9 causes the performance lags when executing flows to be signifigantly worse than even before.  For example, the NGX "After Start Flow", included with MCE, took a full 3 minutes to complete, with painful pauses between each item.  Before it was probably taking a minute and a half.  If the Flow was going at the pace it should, it really shouldn't take more than 30 seconds, as it's just a couple of items.  Other flows also took much more time than they even were before in the previous version.  It will actually be difficult using the scripted flow capability at all now, but continuing to use this new version is a tradeoff with the good fixes made to the derated takeoff problem discussed in the other thread.  So what do we do now?

[FS++ 707]

I'm sorry to have to report this FS++. but using the new version 2.5.3.9 causes the performance lags when executing flows to be signifigantly worse than even before.  For example, the NGX "After Start Flow", included with MCE, took a full 3 minutes to complete, with painful pauses between each item.  Before it was probably taking a minute and a half.  If the Flow was going at the pace it should, it really shouldn't take more than 30 seconds, as it's just a couple of items.  Other flows also took much more time than they even were before in the previous version.  It will actually be difficult using the scripted flow capability at all now, but continuing to use this new version is a tradeoff with the good fixes made to the derated takeoff problem discussed in the other thread.  So what do we do now?

 

It’s very strange. I can assure you we’re not getting those pauses with any aircraft even with a dual core processor.

 

Would appreciate if other users could chime in.

 

As suggested earlier, in case the optimisations aren’t working as expected, disable option “Enable optimisations” in UI and restart MCE.

 

Can you confirm the following?

 

Right-click “fsx.exe”, select properties, compatibility tab and check if “Run this program as admin” option is ticked.

 

What is the FSX installation path?

 

What is MCE installation path?

 

I just want to make sure MCE is able to communicate with the sim as expected.

 

I must admit, not using a 6 core CPU over here (only dual and quad core). Would it be possible to disable 2 cores via the Windows 7 "Run" command, and msconfig and see how MCE behaves?

 

 

Thank you.

[KingGhidorah 209]

I always run FSX through a batch file created by the utility program "fps_limiter_0.2" which limits my frames to 30 but allows FSX to be internally unlimited.  Frames are all over the place if I don't, and the Nvidia frame limiter is a poor substitute.  I always run that batch file by right clicking on the Run As Administrator, and I've always assumed that would make the children of the batch file also inherit admin priveledges.  However, as I look the fsx.exe properties, the box is NOT checked.  Neither is it checked on mce.exe.

 

All of my programs were definitely at least installed by explicitely running as adminstrator.  And UAC is definitely disabled.

 

Before I mess around with disabling cores or Affinity Mask, I'll see what happens when i check the Administrator boxes, first with FSX, and then with MCE.  I'll try the disabling of cores thing as a next step if I have to.

[KingGhidorah 209]

Checked the box for Run FSX as Administrator.  Even though I had thought I had been correctly running FSX as administrator for literally years, I must not have been.  The results were dramatic, and unexpectedly good.  The After Start Flow that had previously taken 3 minutes, took only 40 seconds.  The Runway entry procedure which had taken at least a minute for him to flip 5 switches, now took only 10 seconds, as it should.  After Takeoff and Clean up flows went similarly quickly.  I took several short flights to confirm that is wasn't just a fluke.

 

It appears that the scripted flows are suddenly performing as advertised now, and all because of that stupid checkbox!  Were you expecting that this would make all the difference?  Also, should I also tick the Run as Administrator box for mce.exe, or better off just leaving it unchecked, as it is?

 

Thanks so much for your help!  Really glad to have gotten this all finally working, performance lags in the flows gone, reduced thrust takeoffs etc.  So glad that I got this program!