Question about CPU priority of mce.exe

[FS++ 707]

 

 

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.

[KingGhidorah 209]

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?

[FS++ 707]

 

 

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.

[KingGhidorah 209]

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.

[FS++ 707]

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.

[KingGhidorah 209]

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

[FS++ 707]

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.

[FS++ 707]

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.

[KingGhidorah 209]

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

[KingGhidorah 209]

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.

[FS++ 707]

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.

[KingGhidorah 209]

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!

[FS++ 707]

 

 

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.

[KingGhidorah 209]

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.

[FS++ 707]

 

 

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.