Archived

This topic is now archived and is closed to further replies.

KingGhidorah

Question about CPU priority of mce.exe

Recommended Posts

When you say take the NGX out of the equation, that's hard to do, because it's the primary plane I use

 

Sorry for the confusion.

 

What I meant by that, I don’t see the NGX as being the source of the issue, so that one can be ruled out. Except maybe for third party liveries

 

And to rule that one out too, could you do a test with stock PMDG livery, just to see?

 

A lot of MCE users fly the NGX exclusively. And because MCE runs outside the FSX process, you won’t even need to reduce aircraft or scenery (and weather) quality settings in order to give room to the speech engine.

 

 

It’s possible the changes made recently to allow MCE to run with UAC enabled, may have had unexpected results. At the very least, will send you a replacement “mce.exe” compiled differently (same source code).

 

Would it be possible to temporarily run at stock CPU speed without the overclock.

 

I know you could argue it was running fine before. Don’t forget, now you have the sound device running at higher stress levels. With FSX it’s only sound OUT in action. Here it’s constantly IN and OUT.

 

If using a USB headset, ensure it’s connected straight to the back of the PC and not to the front connectors (which sometimes don’t deliver the required power output the built-in USB sound device needs) nor via a USB hub.

 

If using a conventional headset (3.5 mm jacks), thus using the built-in sound device, under Windows 64 Bit, I strongly recommend you use the Windows certified sound drivers instead of the third party ones, especially with Realtek HD audio.

 

We could eventually give you the option to raise the priority level of the script manager thread, at least to try out. But first, try the suggestions above.

 

Just need more feedback until it’s nailed down

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

I use My Traffic at very low levels of traffic and low poly models, but depending on where and what time of day the flight is, there obviously might be more stuff at the gate. The amount of AI flying around is so low that I really don't think that is the problem, but I just threw that out there because I don't know why it works well on occasion, but most of the time it doesn't. I don't use Affinity Mask tweaks, all 6 cores are in action. I tried the suggestion where I temporarily disabled 2 cores with msconfig, and it didn't make any difference that I could see.

 

When you say take the NGX out of the equation, that's hard to do, because it's the primary plane I use. But I agree, that it looks like there is little else to be done, and I guess I can still get some use out of MCE on the MD-11 and maybe the Jetstream. If the Flows can't be made to work for me, FS2Crew is probably the better option for the NGX, but I must admit, I don't like the strictly scripted flight phases and unforgiving phrasing that I've experienced on the FS2Crew Jetstream.  I do prefer the flexibility that MCE provides.

 

Do you anticipate that there might be any changes in the future to MCE in the way voxscripts demand attention from the cpu, or is it truly time to give up on NGX+MCE Flows?

 

UPDATE: Please postpone implementing the suggestions above and wait for an updated package coming out tomorrow.

 

Ben (my colleague) decided to do a stress test on the Voxscript flow, using as many clues you provided, and for the first time he was able to see the lag. It has to do with freeing some SAPI resources. And it's quite random. Sometimes no lag, other times up to 10 seconds lag.

 

Part of the issue is that we alternate development platform between Windows 7 64 Bit, Windows 8 64 Bit and Windows XP 32.

 

It's something you can't see under XP, or Windows 7 when debugging with UAC disabled for example.

 

A change will be made, and we'll see how it behaves next.

Share this post


Link to post
Share on other sites

 

 


Do you anticipate that there might be any changes in the future to MCE in the way voxscripts demand attention from the cpu

 

 

Hopefully this will address the issue. Download, unzip and replace "mce.exe" inside \Multi Crew Experience\ installation folder.

 

http://www.multicrewxp.com/mce2540.zip

 

Waiting for feedback.

Share this post


Link to post
Share on other sites

Hopefully this will address the issue. Download, unzip and replace "mce.exe" inside \Multi Crew Experience\ installation folder.

 

http://www.multicrewxp.com/mce2540.zip

 

Waiting for feedback.

 

Thanks, I'll try it out as soon as I can and let you know as soon as I do.  Excellent support, and I really appreciate that!

Share this post


Link to post
Share on other sites

I checked 2.5.40 out with thoroughness, and I have some mixed results.

 

First, I ran it in the normal way (with fps_limiter) after a clean system reboot.  It ran very well.  Then the phone rang, and I had the simulation on pause for a half hour.  When I returned, I re-ran the after takeoff flow.  The resulting flow took about 2 minutes, and it should be about 30 seconds.

 

Then I restarted FSX and repeated the same flight, but experienced lags right from the beginning.  I tried it again running straight from the fsx.exe, and had bad results.  I contined, in subsequent flights, a number of combinations of things we've previously discussed, with generally no difference noticed from the behavior of the last version, 2.5.39.  One thing I did notice was that mce always performed better after a clean reboot of the machine, and got worse after each subsequent run of FSX.

 

Then I rebooted and decided to change the way I started MCE, just on a theory.  Because the NGX requires a 20 second initialization, and I run in full screen mode, I was starting it like this--  Start NGX, let it initialize, hit alt-enter to go to windowed, start MCE and wait for it to fully initialize, then alt-enter to go back full screen with the NGX.

 

I changed to doing this--  Start NGX and let it initialize, alt-enter to windowed mode, start MCE, and very quickly, immediately, go back FSX in full screen before MCE has initialized.  I started to notice that if I can get FSX back in full-screen before I see "looking for changes to current aircraft...please wait" that the mce voxscript flows were noticeable less laggy.  I found there was no difference in this improved performance of the mce flows, whether I ran with fps-limiter or not, or if I did a system reboot in between FSX flights.  I flew the same short haul flight 5 times in a row, restarting FSX each time and experienced good performance.  Not perfect performance.  There were some minor lags, but none of the "40 second flows" (such as the after start flow) stretched over a minute and I could generally get Clyde back on track by saying "are you there" or "are you done with your flow?"  I even had good results after letting the sim sit in Pause for an hour before the Shutdown procedure on the 5th flight, just to test if there was some sort of leak going on.

 

Does this sound crazy?  I mean, could there be a difference in the quality of the communications between FSX and MCE depending on whether FSX is in full screen or windowed mode when MCE first comes on line?  I know it sounds unlikely that this makes any difference, but this is what I saw.

 

I'm not drawing a conclusion. Just reporting what I saw with this new version over the course of several flights.  B)

Share this post


Link to post
Share on other sites

 

 


Does this sound crazy?  I mean, could there be a difference in the quality of the communications between FSX and MCE depending on whether FSX is in full screen or windowed mode when MCE first comes on line?  I know it sounds unlikely that this makes any difference, but this is what I saw

 

Although I agree it's not something you expect to happen. Ben will investigate nevertheless.

Share this post


Link to post
Share on other sites

I just tried mce with my newest airplane, the flight1/coolsky DC-9, and even though I thought I had made some headway with the NGX, the DC-9 procedure flows were just terribly slow and laggy, despite my efforts to figure out something to make them quicker.  How frustrating!

 

I really can't ask for any more.  It's very clear that my system just doesn't like mce background flows, on my end, because if it was something in your code then others would presume others would be complaining, and they aren't.  I'll keep using MCE for basic direct command input, and I love it, but it looks like I'll just have to do without the Voxscripts for now. Thanks for your efforts to help me, but it's clear I'm just spinning my wheels at this point and that any success I report could be exactly the opposite the next time around.  I haven't encountered very many problems with my system, but I'm aware that sometimes there is something so peculiar going on with somebody's machine that it just doesn't mesh well with some programs and nobody can figure it out.

 

As a last ditch attempt, you had mentioned a possible tweak for the mce.ini file to boost the priority of the background threads.  What is it, and shall I try it now?

Share this post


Link to post
Share on other sites

 

 


As a last ditch attempt, you had mentioned a possible tweak for the mce.ini file to boost the priority of the background threads. What is it, and shall I try it now?

 

That still stands. However we haven't given up yet. You may want to try out the very latest package uploaded this evening:

 

http://www.multicrewxp.com/very-latest-mce.zip

 

This is a full package, and it also updates fInsider.dll which runs inside the simulator process.

Share this post


Link to post
Share on other sites

That still stands. However we haven't given up yet. You may want to try out the very latest package uploaded this evening:

 

http://www.multicrewxp.com/very-latest-mce.zip

 

This is a full package, and it also updates fInsider.dll which runs inside the simulator process.

 

Did clean reinstallation for 2.5.41.  Only got a chance to try out the new version with F1 DC9 so far.  It went well until I hit the After Takeoff Flow, and then Clive started to pause and lag excessively.  The next voxscript, "Prepare for Descent" went better, but that's all I've had a chance to check out thus far.

Share this post


Link to post
Share on other sites

Did clean reinstallation for 2.5.41.  Only got a chance to try out the new version with F1 DC9 so far.  It went well until I hit the After Takeoff Flow, and then Clive started to pause and lag excessively.  The next voxscript, "Prepare for Descent" went better, but that's all I've had a chance to check out thus far.

 

OK thanks.

 

Will wait for more feedback.

Share this post


Link to post
Share on other sites

FS++, on 26 Jun 2013 - 02:25 AM, said:

FS++, on 26 Jun 2013 - 02:25 AM, said:

 

OK thanks.

 

Will wait for more feedback.

Have the results of two more flights, this time both in the NGX.

 

On the first flight I ran as I normally do, using fps_limiter. I started with engines running and immediately called for the After Start Flow. In this particular run, it took nearly 4 minutes to complete, as I timed it with the stopwatch on my yoke. Slowest I've seen.  That was as far as I went with that flight.

 

On the second flight, I started FSX directly, non-frame limited. All the flows on the ground went well.  When I called for the After Takeoff Flow however, much like my previous report for the DC9, Clive stumbled badly and this took a painstakingly long time to complete (should only take about 30 seconds).

 

So...I'm not sure that I can say there is any improvement despite some of the fixes that have apparently been made in ver .40 and .41. Might be time for that Magic Tweak, just to see if that helps :P

Share this post


Link to post
Share on other sites

Might be time for that Magic Tweak, just to see if that helps

 

OK, that will be the next step.

 

Since we won't be hard coding the thread priority changes into the exe but rather give you the option to do it yourself via a "mce.ini" option, it will not require extensive testing on our side.

 

Hopefully a new package you can experiment with by next Tuesday at the latest.

Share this post


Link to post
Share on other sites

Might be time for that Magic Tweak

 

OK, now is the time.

 

Download and install this package:

 

http://www.multicrewxp.com/NEW-mce.zip

 

Go to C:\Users\your_user_name\AppData\Roaming\Multi Crew Experience\ folder

 

Open mce.ini, then add the following section (anywhere in the file).

 

[VOXSCRIPT]

DisablePriorityBoost=0

SingleTaskTimout=15000

ThreadPriorityTweak=0

 

 

 

The default values above are the ones that apply when the options are missing or no tweaks are done.

Valid values for "SingleTaskTimout" are 10000 to 20000

Valid values for "ThreadPriorityTweak" are 1 or 2

 

You can experiment without the need to restart MCE. Make changes, but don't forget to save the file. The next script you run will use the latest custom values.

Share this post


Link to post
Share on other sites

Thanks, I will check this out very soon.  Should have results of several flights in a couple of hours.

Share this post


Link to post
Share on other sites

Version 2.5.43: Sorry to have to report to you that the new settings made no overall difference.  I tested both ThreadPriorityTweak 1 and 2, and SingleTaskTimeout values 10000 and 15000 in various combinations.  Tried 2 planes, the F1 DC9 and the NGX.  Just to rule it out, I also tried running both with fps-limiter(preferred way) and direct, again with various combinations.  In each test run, I recieved lags of varying degrees, the longest being one of the after takeoff flows (run actually on the ground) taking upwards of 3 minutes, and this happened on a run with FSX run directly as administrator, and ThreadPriTweak at 2. 

 

Your support has been absolutely fabulous.  Quite possibly the most one-on-one I've seen with any product.  At this point I would feel terrible asking for any more.  I've really become addicted to the convenience of MCE and will just make do without the flows, and hope that maybe in a future build of my machine, whatever gremlin exists that prevents this software from working correctly goes by the wayside.  I didnt think before that there was anything screwed up with my machine, since it runs FSX very well, but there obviously must be.

Share this post


Link to post
Share on other sites

Version 2.5.43: Sorry to have to report to you that the new settings made no overall difference. I tested both ThreadPriorityTweak 1 and 2, and SingleTaskTimeout values 10000 and 15000 in various combinations. Tried 2 planes, the F1 DC9 and the NGX. Just to rule it out, I also tried running both with fps-limiter(preferred way) and direct, again with various combinations. In each test run, I recieved lags of varying degrees, the longest being one of the after takeoff flows (run actually on the ground) taking upwards of 3 minutes, and this happened on a run with FSX run directly as administrator, and ThreadPriTweak at 2.

 

Your support has been absolutely fabulous. Quite possibly the most one-on-one I've seen with any product. At this point I would feel terrible asking for any more. I've really become addicted to the convenience of MCE and will just make do without the flows, and hope that maybe in a future build of my machine, whatever gremlin exists that prevents this software from working correctly goes by the wayside. I didnt think before that there was anything screwed up with my machine, since it runs FSX very well, but there obviously must be.

Thanks for the accolade.

 

We now know it's not a case of a thread being starved of CPU time.

 

Aside from re-installing FSX and other add-ons (which I'm sure you don't want to go into), what I would do is look at...

 

Overclocking and its impact on the sound devices. The CPU might be draining too much power, possibly impacting on the USB delivered power.

 

The speech engine runs inside the MCE process and any disruption to the device would potentially cause a lag.

 

Not saying IT IS the root cause.

 

At the very least update DirectX (because MCE uses DirectSound for audio) and make sure you have good sound drivers.

Share this post


Link to post
Share on other sites

I've removed my Creative sound card, cleaned the machine up with Driver Sweeper, enabled onboard Realtek Audio with the latest drivers. I'm tempted to say it works better, but there have been some lags. At least I think any problem with drivers or a standalone sound card can be eliminated from the equation.

 

I briefly tested it with the processor set to stock speeds and settings. I didn't notice much difference in the overall behavior of MCE, but obviously my performance in FSX generally was inadequate, so I only tested enough to convince myself that it wasn't the solution.

 

One thing that I notice that gets the FO back on track when one of his verbose flows lags, is to command "Pay Attention."  Most of the time, he immediately comes out of his stupor and gets busy with his flow again. Could this possibly tell you anything? What does this command cause to happen that snaps him out of his lags? I'm thinking it would be nice if he always payed attention! :P

Share this post


Link to post
Share on other sites

 

 


One thing that I notice that gets the FO back on track when one of his verbose flows lags, is to command "Pay Attention." Most of the time, he immediately comes out of his stupor and gets busy with his flow again. Could this possibly tell you anything? What does this command cause to happen that snaps him out of his lags? I'm thinking it would be nice if he always payed attention!

 

Yes, that's helpful

 

Try this...

 

Open mce.ini in \AppData\ folder

 

Look at the [sPEECH] section and Change "MaxConcurrentTasks=4" to "MaxConcurrentTasks=10"

 

Save the file, and see if it makes a difference.

Share this post


Link to post
Share on other sites

I had previously discovered the MaxConcurrentTasks variable in another previous thread, and have been running with it set to 7.  I thought it only pertained to commands directly given, not to the scripts, and I hadn't thought about boosting it all the way to 10.

 

So I now set it at 10.  Only had a chance to do one brief flight in the NGX, all Voxscripts set to Verbose.  I've been notorious for reporting success in this thread, only to come back a day later and retract it, but if I had to make an evaluation, I would say it was a good improvement.

 

It wasn't perfect.  There were only 2 instances where I had to command "Pay Attention!", once during the After Takeoff flow, and once towards the end of the Clean Up flow.  He (Trav) immediately got back on track.  Overall, I would say it was a marvelous flight.  The longest flow, the Clean Up, took under a minute, and he only stalled on the very last item, but quickly finished up when I told him to pay attention..  The Runway Entry Procedure, involving the turning on of a couple of lights, took less than 25 seconds, whereas in the beginning of my problems, he would sometimes linger on those 4 switches for almost 2 minutes. 

 

Is 10 the maximum value for this variable?  I wonder what could happen if I could boost it higher, because it actually does seem to be improving things.

 

I'm not sure I understand why this might be working, if it is indeed working, and if that's truly the problem.  When I do the flows, I have no other direct commands issued or in progress. I just say "After Takeoff flow" and try not to interrupt him with other commands to distract him from his task at hand, which I assume would only be the next item in the script, not ten other things.

 

The version I'm using is still the .43 "experimental" version you linked to earlier.  I am not currently using that ThreadPriority tweak, because I'm not entirely sure if that one didn't even slow things down further.

Share this post


Link to post
Share on other sites

 

 


Is 10 the maximum value for this variable? I wonder what could happen if I could boost it higher, because it actually does seem to be improving things.

I'm not sure I understand why this might be working, if it is indeed working, and if that's truly the problem. When I do the flows, I have no other direct commands issued or in progress. I just say "After Takeoff flow" and try not to interrupt him with other commands to distract him from his task at hand, which I assume would only be the next item in the script, not ten other things.

 

Values above 10 are ignored.

 

OK, now the issue appears to be nailed.

 

To avoid a situation where FO flips 4 or 5 switches from different ends of the overhead panel like Superman, resulting in unrealistic behaviour, we have to slow him down.

 

He's not supposed to dial something new when his hand is already tied to dialling something else. He would queue the second command, and execute it when his hands are free.

 

Equally, every action he starts increments a specific value which keeps track of how many actions are in progress, and decrements it when the action is done with.

 

Because every command executes in a separate thread, occasionally that variable is seen by other threads to be in the wrong state.

 

When you say "Pay attention", those variables tracking the number of tasks allowed to run concurrently are reset to zero.

 

By setting the value at 10, you're delaying the chances of FO feeling overwhelmed.

 

I am keen to say it is a multi-threading issue. It appears your 6 core CPU is executing those tasks at unprecedented speed. Remember, we only tested on dual core and quad core.

 

 

Now that we know were to look, will see if it can be improved on.

 

For example, right now those variables are managed with a high performance lock "InterlockIncrement" and "InterlockDecrement". May need to use a full "CriticalSection" even if it hits performance a bit.

 

In theory, thanks to the multi-threading design, while FO is executing a script silently in the background, he should be able to perform the odd extra command here and there as well as reply to your questions. And while doing so he needs to know when to keep silent for the scripted command, and be vocal for the others.

 

Will send you a pack for testing as soon as possible.

Share this post


Link to post
Share on other sites

 

 


The version I'm using is still the .43 "experimental" version you linked to earlier.

 

Try this experimental package.

 

http://www.multicrewxp.com/MCE2547.zip

 

Reset "MaxConcurrentTasks=4" and see if flows are executed in a timely manner.

 

Besides the fix for the known glitch, one new thing in this build...

 

If user holds the PTT down in order to talk to ATC or Vatsim, the next scripted action is suspended until the PTT button is released.

 

This is to prevent FO's voice coming in the way when the script is verbose and you're struggling to hear that ATC instruction or your team mates.

Share this post


Link to post
Share on other sites

Installed 2.5.47, and reset concurrent tasks back to 4.

 

Did two short flights in 737, both starting at the stand with engines running, first mce flow being After Start Flow.

 

First time I ran, the After Start flow did not proceed in timely fashion.  30 seconds to start the first item (engine generators), and then about 10 or 20 seconds between each item.  I reran it, and he did better the second time after I lost patience and demanded "Pay Attention."  The rest of the flows ran mostly smoothly, but sometimes the delay between items was clearly a little longer than the "Pause=X" specified in the script, which is generally not a problem provided its only a small difference.  I realize it is possible that Pay Attention is acting as a placebo, and that he was just about to do the next item and get busy again regardless, but at this time I still stand by the contention that Pay Attention actually is helping.

 

The second time I flew (exactly same flight) he did a little better off the start.  Had to say P.A. several times for several flows, but aside from Trav's normal bumbling, it was overall it was a pretty good flight.  Maybe a little worse MCE flow performance than in version 2.5.43 when I tried it out with the concurrent tasks to 10.

 

Might be percieving a little performance hit.  I run with the fps externally limited to 30, and normally during cruise the fps is actually being held back, but in this case it looked like it was struggling to make 30 most of the time.  Probably nothing unusual and maybe just a little fps paranoia on my part because you mentioned the solution might come with a perf penalty.  I should know better than to ever hit Shift-Z because it causes my eyes to burn in torment!

 

I don't think this new version made things better, but you also need to keep in mind how much better the flows are going overall compared to when I started this thread a while back.  I'm out of time to run more flights at the moment, but if you want I can turn the concurrent tasks back to 10 and run some more tests later.

Share this post


Link to post
Share on other sites

 

 


I'm out of time to run more flights at the moment, but if you want I can turn the concurrent tasks back to 10 and run some more tests later.

 

Thanks for feedback. Will see what conclusions can be drawn.

 

The perf penalty I was referring to earlier relates to MCE's own threads execution (within mce.exe), not FSX.

Share this post


Link to post
Share on other sites