Classic British Flight Sim

DaveB,
you've been saying that you find it annoying that FSXB keeps turning a particular parameter on but offers no control over it. There's a tool that will set whatever parameters you like in FSX.CFG every time you run FSX - useful for those odd quirks like the fact that FSX resets one particular parameter every time you change any other parameter within FSX. Sorry can't remember the names of those involved but you should catch my drift -

http://www.fullterrain.com/product_fsxgo.html

I like it a lot, and there are those who call it sliced bread ...

I'll take a look Ro.. thanks

ATB
DaveB

rohan wrote:... Whenever you do that, you MUST use an appropriate value for the mask setting AND use some tool to set the affinity for the add-on app. Unless you coordinate these two affinity values properly, you can guarantee that you'll run into code blocking ...

Or leave it alone in my case which seems to work best on my rig, i.e. I don't use a mask in FSX

Ben,
Quite right. I was just coming back to try to rephrase the comment you quoted. Running an add-on app isn't per se going to give you code blocking - that can only happen within FSX (or possibly in the add-on app). Using an "inappropriate" mask value however would likely give you a processor overload condition with the added load of the extra app(s) - especially on a 4 core CPU. Basically, Windows would either waste processor cycles swapping between apps (processes) or some processes would be working slowly because they weren't getting enough cycles (leading to a similar situation to code blocking) - or both.

Really, on a 4 core CPU, as you discovered, you might just as well let Windows take the strain when you have a single add-on app unless you want to balance the load yourself. If you do, that's where my MUST in the previous post comes into play. If you have a CPU with more than 4 cores or want to run more than one add-on app, then there's much to be gained by applying the MUST technique.

Thanks Ro, that makes sense. The frustration I had for about 3 years of va flying was quite telling, arguably leading to more of my greys than the kids. Fortunately the VA client was the only thing I was running. Actually, that would also explain why it was worse with other addons that also ran, mostly using sim connect.

I can only talk about P3Dv2, but if no affinity mask setting is specified by the user in the .cfg, it runs at 84, which is the default setting put in by Lockheed Martin. On a quad core with HT enabled, this means the first physical core , CPU 0, is left for other processes, presumably to avoid the code blocking problem you mention, Rohan. The other three physical cores ( CPUs 2, 4 and 6 ) are selected. Presumably, with HT disabled, the built-in Lockheed Martin setting will again leave CPU 0 free, and use the three physical cores ( CPUs 1, 2 and 3 ).

I haven't seen any instability with affinity mask settings, even when using 255 ( all four physical and all four logical cores selected ). However, if LM thinks its a good idea to leave the first core vacant, then who am I to argue. Thats why I backed the setting back down from 255 to 254, and so leaving that first physical core vacant.

Ah, the great affinity mask debate has, like a case of ebola, finally arrived on the shores of CBFS. Coming soon - EULA arguments !

I haven't tried P3D2 with no setting. I put it in when I first installed it and it made a huge difference, but given all of the anomalies of the opening release of P3D2, it could have been an erroneous result, I'm going to try it again now

Ben, the odd thing is that while P3Dv2 defaults to 84 with no affinity mask edit, if you DO specify 84 yourself in the.cfg, performance seems to improve. Same goes for Task Manager - if you un-tick then re-tick the boxes to match the default setting, again performance seems to improve, if only marginally. Or it could be the fact that I've clicked back on the P3D window and its once again the window in focus - another issue highlighted by LM on their forum.

That aside, I really recommend bumping up the priority setting in Task Manager, warnings of instability notwithstanding.

Well chaps, just removed the affinity mask in P3D2 (with the last patch applied) and what do you know, its better than FSX. It looks like something in one of the patches or service packs sorted my problem out so now, with no affinity mask set in the p3d2 cfg, its working a treat. Best of all, frame rates with old FS9 models in shot don't seem to be as bad as they are in FSX

Paul,
I'm intrigued to know how you know that the default LM setting is 84 if there is no value in the mask setting in whatever is the LM equivalent of FSX.CFG. Have LM posted anything official about affinity settings on their site ?

A little background, bearing in mind my lack of facts about P3D in this respect. By making FSX multi-threaded, m$ had to include some o/s coding before that could work. That's done by writing what's called a thread handler which provides the means by which resources can be shared between the different threads - essentially every piece of data has a couple of flags associated with it; one of which says if it's in use (being written to). If a code thread wants to access that data, it tests the flag and carries on only if the flag says it's free. Otherwise it waits, having told the handler that it's waiting. And waits. When the thread that was using that data has finished, it clears the busy flag and tells the handler that it has done so. The handler can then restart the first thread which was waiting, and so on, and so on.

There are many different ways of actually writing such code, and some are better than others, but let's not go there. And the above is a very much simplified model. But there is one more task that the handler performs - it reads the affinity mask setting and sets the processor affinity (as in task manager) of each of its three threads before it starts them. At that point, you could say that FSX itself has started.

Now, I cannot believe that LM would have made any changes to such fundamental, low level code as this in P3D version 1, or even 1.4. However, LM have made some fairly serious changes to some of the guts of FSX in version 2, so it's just possible that they've separated out more code into one or even more new threads. Though again I doubt that they will have changed the heart of all this - the handler.

So finally he gets to the point of this story - there is no way to tell Windows in which core it should run the handler - it gets a lottery ticket just like all the other processes started by Windows. Ah but what about using task manager to change a process' affinity - yes that works once the process is running. So herein lies the conflict - on the one hand the thread handler has started its three threads in the cores allocated by the mask, on the other the affinity of other running processes has been set externally by the user by some means. If the user has assigned FSX to some specific cores externally, where is FSX going to run and, more specifically, which FSX code is going to run in which core ???????? We're back to Chinese butterflies flapping their wings and causing ...

There is no way to answer that question - FSX will be split in two with some code managed by the handler and some code managed by Windows; hence instability, regardless of whether this is visible to the user or not. The only guarantee is that this situation will not give repeatable results.

We need to know how many threads have been set up within P3D ... is it still three (as suggested by Paul's input) or are there now more ?