PFC, Hyper Threading and frame rates

[BC]

On another forum, I read of a tip where one could set the "affinity" to make FS9 run on a single processor in a hyper threading system. I tried this tip and sure enough, my frame rates jumped from 15-20 to a pretty good 30 FPS.

I don't know why, but I checked the M$ Knowledge base for hyper threading to see if it was some sort of bug with FS9, which is supposed to be HT capable. Nothing there, but I did see an article about "older" .dll files which would cause WinXP to run them in a "compatibility" mode or something like that.

As a test, with FS9 running in HT mode (2 processors) I moved all of the addon .dll's out of my modules folder (FSUIPC, WideFS, GPS OUT, PFC and fssound).

Started the sim and a solid 30 FPS. Then I shut down the sim and copied back the .dll's one at a time (FSUIPC 1st of course).

Each time, start the sim, check the frames and shut down. All was well, 30 FPS +/- windowed and full screen. When I moved pfc.dll (v 1.55) back and restarted, the frames dropped to 15 +/-.

Soooo...

Is PFC.dll HT capable? For example, does the text of this KB article apply?

http://support.microsoft.com/default.as-us;327809

Article title: "Cannot Run Certain Programs on Hyper-Threaded or Dual-Processor Computers with a CPU Speed of Greater Than 2 GHz"

PFC runs OK, but it slows down the sim by almost 50%.

It's just an idea, but something is slowing down the sim with HT enabled, and unfortunately right now, it looks like the PFC.DLL.

This is on a P4 2800HT machine, fresh install, GF4 TI4600 etc etc.

Otherwise, all works swell...

Well, setting "extend upper wind layer upward" sets the upper limit at 100,000. It seems that FS9 does not like that one bit. If you check under the advanced wx options in the sim, the setting will be 100,000 if you select that option in FSUIPC. Try to get away from that screen and you get a popup box from the sim telling you ti change the value to something less than 99999.

The 100,000 foot setting appears to cause weather problems.

Sorry for the long post, been meaning to ask these questions for a while.

Aside from these things, great job Pete, keep at it!

BC

[jbAg83]

How do I know if I'm running in HT mode on single processor mode? I've got a P4 2.4 with HT and a geforce fx 5900 ultra and fs9 can still run pretty slow in busy situations. Definetely not a steady 30 fps yet it seems like me system should be capable of this, don't you think? I don't have PFC.dll so is there anything else that might be causing the slowdown?

[BC]

OK, first, "How do I know if...?"

If you are running WinXP, ctl+alt+del and check the performance tab. If you see two processor windows at the upper left, you are running 2 virtual processors (Hyper Threading). If you only see one processor window, then you are not. Your MOBO must support HT and it has to be enabled in the bIOS.

NOW, I just did a quick test, which I should have done before the previous post.

OK, with PFC.DLL in the modules folder, I started up the sim. 15 FPS.

CTL+ALT+DEL, under processes, I right clicked FS9.exe and then selected set affinity. Made it run on only one processor then exited. FPS jumped to 30 FPS.

Shut down the sim, removed the PFC.dll from the modules folder. Restarted the sim. 30 fps. Set the affinity of FS9>exe to a single processor. No change. 30 FPS.

Note: the affinity selection only last for the current session. You must redo the setting every time you start the application.

So, my completely unscientific test shows that PFC.DLL does not like HT.

Ideas?

BC

[Capn Tarmack]

On another forum, I read of a tip where one could set the "affinity" to make FS9 run on a single processor in a hyper threading system. I tried this tip and sure enough, my frame rates jumped from 15-20 to a pretty good 30 FPS.

I don't know why, but I checked the M$ Knowledge base for hyper threading to see if it was some sort of bug with FS9, which is supposed to be HT capable. Nothing there, but I did see an article about "older" .dll files which would cause WinXP to run them in a "compatibility" mode or something like that.

As a test, with FS9 running in HT mode (2 processors) I moved all of the addon .dll's out of my modules folder (FSUIPC, WideFS, GPS OUT, PFC and fssound).

Started the sim and a solid 30 FPS. Then I shut down the sim and copied back the .dll's one at a time (FSUIPC 1st of course).

Each time, start the sim, check the frames and shut down. All was well, 30 FPS +/- windowed and full screen. When I moved pfc.dll (v 1.55) back and restarted, the frames dropped to 15 +/-.

Soooo...

Is PFC.dll HT capable? For example, does the text of this KB article apply?

http://support.microsoft.com/default.as-us;327809

Article title: "Cannot Run Certain Programs on Hyper-Threaded or Dual-Processor Computers with a CPU Speed of Greater Than 2 GHz"

PFC runs OK, but it slows down the sim by almost 50%.

It's just an idea, but something is slowing down the sim with HT enabled, and unfortunately right now, it looks like the PFC.DLL.

This is on a P4 2800HT machine, fresh install, GF4 TI4600 etc etc.

Otherwise, all works swell...

Well, setting "extend upper wind layer upward" sets the upper limit at 100,000. It seems that FS9 does not like that one bit. If you check under the advanced wx options in the sim, the setting will be 100,000 if you select that option in FSUIPC. Try to get away from that screen and you get a popup box from the sim telling you ti change the value to something less than 99999.

The 100,000 foot setting appears to cause weather problems.

Sorry for the long post, been meaning to ask these questions for a while.

Aside from these things, great job Pete, keep at it!

BC

Sir,

I am finding the EXACT same conditions as you mention........my frame rates double after removing the 1.55 PFC.dll from the Modules folder.......and in fact my CPU useage is in the 49 percent range with the pfc.dll removed.......if I reinstall it the cpu consumption goes to 99 percent.

If I use the Affinity tweak to remove one cpu while running pfc.dll the frame rates do improve.....but it seems to me that I have lost my HT function....and the frame rates are still not as fast as when I remove the pfc.dll.

Peter.......can you HELP in this area with a new .dll ??

You might just win an award. Grin.

Regards,

Mel Ott

[Pete Dowson]

When I moved pfc.dll (v 1.55) back and restarted, the frames dropped to 15 +/-.

Sounds like some inefficiency in the Serial Port driver setup then.

Is PFC.dll HT capable?

It's just a DLL. It does use the COM port of course, and that is used in what should be "concurrent" mode -- i.e. PFC is not hanging around waiting for data to be received or sent. So maybe it is to do with the way the Serial port driver is handling this. Testing here I see no difference in frame rates whatsoever, with or without PFC.DLL, but then I've only got a humble 2.4GHz P4 which I don't think hat "HT"?

For example, does the text of this KB article apply?

http://support.microsoft.com/default.as-us;327809

Article title: "Cannot Run Certain Programs on Hyper-Threaded or Dual-Processor Computers with a CPU Speed of Greater Than 2 GHz"

I don't know. I'll have a look.

It's just an idea, but something is slowing down the sim with HT enabled, and unfortunately right now, it looks like the PFC.DLL.

It is probably the only thing using a COM port, so the most likely problem is your serial port driver. Not sure what you can do about that. As I say, there's no difference here at all.

Well, setting "extend upper wind layer upward" sets the upper limit at 100,000. It seems that FS9 does not like that one bit. If you check under the advanced wx options in the sim, the setting will be 100,000 if you select that option in FSUIPC. Try to get away from that screen and you get a popup box from the sim telling you ti change the value to something less than 99999.

There are lots of problems in FS's weather dialogues, few of which are at all related to FSUIPC. I wouldn't really worry about that specific one.

The 100,000 foot setting appears to cause weather problems.

Like what? You need to be more specific than that, please!

There is nothing "odd" about 100,000 feet. Internally ALL altitudes are kept in metres in any case. That one is actually 30480 metres. I would expect the possibility of problems if it were 32768 metres (exceeding 16-bit capacity), but even that would be strange as FS usese floating point almost universally now.

Regards,

Pete

[Pete Dowson]

Is PFC.dll HT capable? For example, does the text of this KB article apply?

http://support.microsoft.com/default.as-us;327809

Article title: "Cannot Run Certain Programs on Hyper-Threaded or Dual-Processor Computers with a CPU Speed of Greater Than 2 GHz"

I've now looked at that article, and it doesn't really apply. Almost all my modules do use the QueryPerformance calls, but only to get accurate time differences between the calls they get from FS. I might change that soon anyway, if I can find FS's own millisecond timer. The article is really talking about things which might go wrong with a program if it assumes that the values it gets back fit into 32 bits instead of the 64 allowed. This doesn't apply to my code, and even if it did, it wouldn't slow down FS, it would just make the DLLs go wrong, as the article implies.

Really, I think the only thing different about PFC.DLL is its use of the COM port, so I think there's something about the COM port drivers which are coming into play (or not) with HT operation.

Regards,

Pete

[Capn Tarmack]

Peter,

So it might "behoove" us to replace the PFC hardware and purchase new USB equipment?

Regards,

Mel

[Pete Dowson]

So it might "behoove" us to replace the PFC hardware and purchase new USB equipment?

You won't catch me doing that. The PFC stuff is too good.

Anyway, I though this NT problem could be solved by assigning processors or something? Isn't that what you all have been fussing around doing? Is it me confused or what? :?

I've been making notes about all this so I know what to do next week -- my P4 3.2GHz processor, mobo and memory is on order. I expect to be off-line for a couple of days next week whilst I'm rebuilding! :)

Pete

[Capn Tarmack]

Peter,

Well, the way I understand it.......when we use the Affinity option to remove one CPU from the loop.......we effectively remove hyperthreading also.

Wonder if using a USB/Serial adapter might fix the problem? What do you think?

Regards,

Mel

[Capn Tarmack]

Peter,

I just fixed the problem. Grin.

Ordered a GoFlight throttle system that is USB controlled and am going to trash the pfc legacy throttles........that is the only function I used anyway...so take your time if you thought you had a fix. Grin.

Regards,

Mel

[Pete Dowson]

Well, the way I understand it.......when we use the Affinity option to remove one CPU from the loop.......we effectively remove hyperthreading also.

But all the results folks are posting seem to show that, PFC.DLL aside, FS's performance with or without HT is identical, so what does it matter? Please clarify!

Wonder if using a USB/Serial adapter might fix the problem? What do you think?

Depends whether that succeeds in by-passing whatever it is in Windows that is causing the problem. Maybe it isn't even in windows. Perhaps legacy hardware support in the Motherboard's BIOS isn't suited to HT operation, in which casm yes, bypassing that part by using USB might help.

Let me know, please. Also let me know what the difference in performance of FS is with and without HT, both without PFC.DLL. So far no one has shown any.

As was mentioned somewhere else here, really the HT thing is surely best used when you have other processes sharing the FS PC. Then assigning FS to one and all the others to the other seems to be a realy good idea.

Regards,

Pete

[Capn Tarmack]

Peter,

Here is what I find.

We are talking geometrics here. Grin.

Using affinity I double my frame rates........removing pfc.dll and NOT using

Affinity I triple my frame rates.

I just purchased the GoFlight 4 engined USB thrust lever assembly and I know

a good trash man for the pfc hardware. Grin.

Regards,

Mel

[Pete Dowson]

So, my completely unscientific test shows that PFC.DLL does not like HT.

Okay, I've been all the way through the code to see if I can spot anything that looks at all likely to be a candidate for "messing up" HT operations -- not that I'd really know, of course. It's all a bit above my head I'm afraid.

The only significant thing different about anything PFC.DLL does from, say, FSUIPC or WideServer, or most of my other modules, is that it uses the Serial port.

It not only uses it, but, for efficiency, it uses it in full duplex mode with both reads and writes programmed for concurrency -- following all the guidelines and examples in Microsoft sources for such things.

Additional to this it does also create two small threads -- one to check on the status of the serial port read buffers, and extract data as it arrives, and the other to replenish the write buffers in the serial port driver whenever they become nearly empty and there's still data to be sent.

Now, whether any of these actions is specifically inimical to HyperThreading, I just don't know. And, worse, I have no way of finding out.

Looking at this from the hardware up, the first possible area of suspicion is the BIOS serial port support. I doubt that this could do any harm, but given Microsoft's rather pronounced wish to move away from these legacy devices, it is possible that there's less compatibility here that one would wish.

To determine whether this could at all be the culprit, I propose that a test be carried out. If anyone using PFC equipment and an HT CPU could try using a USB-serial port adapter for the connection, instead of a genuine serial port, this should succeed in bypassing the BIOS and use USB parts of Windows XP instead.

I should be able to do this myself in a week or so's time, once I get the P4 3.2GHz processor I've ordered installed and working. But if anyone does it before, please let me know the results.

If this doesn't help, all I can do really is try the PFC driver with different thread priorities, or no threads, and maybe even try using blocking serial I/O, though I don't think that will be acceptable.

Oh, there are some Windows API calls to set a thread's processor affinity as well, so I could try deliberately associating the Serial threads with one or the other virtual processors.

Anyway, I'm afraid most of this experimentation will have to wait until I have the equipment. Please bear with me until then. I'll be in touch.

Regards,

Pete

[airforce2]

Pete;

I did some experimenting today...found a couple more really strange things about HT and processor affinity I can't fully explain.

I restored a virgin copy of FS9.exe without the affinity mask. Then I assigned an affinity to each DLL in the modules folder separately using IMAGECFG, putting G2D, G3D, and Terrain onto vCPU1, and the others to vCPU0.

With pfc.dll removed from the folder, FS9 starts running with both vCPUs at 100% and ~12fps. I then manually set affinity for FS9 in the task manager to CPU1, and it runs 100% on vCPU1 with minor activity on vCPU0, and frame rates go up to 20fps on average. Then...and this was a surprise...if I reset FS9 to run on both vCPUs, the load will then run shared equally across the vCPUs at around 50% with a lot of flux +/- around 15-20% on both sides...and frames remain at ~20fps.

Then I repeat the experiment with pfc.dll running. Every time I go to both vCPUs with pfc.dll up & running, both virtual processors shoot up to 100% and frames drop back to around 12. Clearly something in pfc.dll is not living happily with whatever does the HT load sharing.

I'm heading out to find a USB-serial converter shortly...I've been wanting one for a while anyway. Will advise how that goes later.

Cheers

[Pete Dowson]

Clearly something in pfc.dll is not living happily with whatever does the HT load sharing.

I'm heading out to find a USB-serial converter shortly...I've been wanting one for a while anyway. Will advise how that goes later.

Cheers

Okay. Thanks very much!

If that doesn't help, maybe you'd like to try a few variations in PFC.DLL for me -- assuming I can think of any which don't involve a complete re-write? If so, please wite to my email address and I'll get back to you when I've thought of something.

Thanks again,

Pete

[BC]

Howdy Pete!

Well, the plot thickens. Your serial port idea had something to it, so I thought I would take the next step..I also use GPSout, which uses a serial port. Utilizing the same remove/test/replace/test again method, there is no performance hit at all with GPSOut using the serial port.

Setting FS to run on one processor with the pfc module removed is no different then when running with 2 virtual processors.

So, it looks like it may be specific to pfc.dll. How does GPSout use the serial port differently than pfc? That may be the key.

Now, about the 100,000 foot thingie...

I have found that if you set the option in FSUIPC, it appears that FS9 starts processing wx and gets to a point and stops. No warnings or anything, the sim works fine, but no weather to speak of. If you look at the advanced wx dialogue and custom settings, winds tab, the upper level will be 100,000 feet as forced by fsuipc. When you try to leave that page,you get a pop up telling you to set the limit to between 0 and 99,999. Doing that and SHAZAM, the weather appears.

I was having trouble with WXre (weather not acting as expected) and I mentioned this to Damien from Active Sky WXre and he changed his upper limit to 90,000 feet, that didn't help. I then found that it was my selecting the option of extending winds in the fsuipc menu that was causing the problem. Hope that makes sense.

BC

[airforce2]

Pete;

I just tried with the PFC controls connected via a Belkin F5U103 serial-to USB adapter. No change in behavior from previous post.

One thought...would it be possible to compile the DLL as a standalone exe rather than an FS module? It might be handy to be able to hang the PFC onto one of the clients and feed the flight control inputs to the server via the WideFS data stream.

Cheerio

[Pete Dowson]

I just tried with the PFC controls connected via a Belkin F5U103 serial-to USB adapter. No change in behavior from previous post.

Disappointing, but at least it eliminates one part of the puzzle. As I said earlier, I'll try to think up other changes to try. If you would like to help test, please write to my email as I said.

One thought...would it be possible to compile the DLL as a standalone exe rather than an FS module? It might be handy to be able to hang the PFC onto one of the clients and feed the flight control inputs to the server via the WideFS data stream.

Not without a HUGE amount of work, and in any case I don't like main flight controls on clients. I tried that once with EPIC stuff and the latency is just too annoying. It is achievable with airliners, but not nice. With anything faster or more responsive it is noticeably annoying.

I think there are other easier and more useful things to try first. Obviously it would help if anyone knew enough about HT to advise me on possibile reasons for this happening, as otherwise it is going to be trial and error. It will be quicker for me when I've got an HT PC up and running, which I may have by the end of the week.

Regards,

Pete

[Pete Dowson]

Bob,

There's one thing I found which may contribute to this HT problem, or may not. If you've installed Wilco's 767PIC, version 1.3 or later, the PFC.DLL opens a memory filemap to communicate with it's DLL for the 767PIC controls in PFC. Although these are only active when you are actually using the 767, the filemap is an interface with the 767PIC DLL in your Modules folder.

If this is applicable in your case, could you just try running FS without the DLL (I think it is called APS.DLL now, though there may be a B767W.DLL too).

This is just a straw I'm clutching at, but as it is an easy one to try and eliminate it is certainly worth a look. There is some problem associated with HT and filemapping, according to some reference posted in the other thread.

Thanks.

Pete

[airforce2]

Pete;

Tried it without APS.DLL in the modules folder...no change.

Have been doing research this morning on interrupt affinity masking...there's a utility in the Win XP Server 2003 Resource Toolkit that allows you to set processor affinity for drivers doing hardware interrupt handling, which may be at the root of this problem with serial I/O.

The utility is called intfiltr.exe...you can download the WIndows XP Server 2003 resource toolkit from support.microsoft.com. The utility applies to Win XP pro as well as Win XP Server 2003 per the docs.

With the serial I/O interrupt handling set to CPU0, the PFC driver still drives both CPUs up to 100% when FS9 is set to dual-processor affinity. I've also discovered that the sound card (Audigy) does not take well to having its interrupts tweaked...it hisses and pops like mad when you do. Lots of other interesting possibilities are unfolding.

Cheers

[Pete Dowson]

Now, about the 100,000 foot thingie...

I have found that if you set the option in FSUIPC, it appears that FS9 starts processing wx and gets to a point and stops. No warnings or anything, the sim works fine, but no weather to speak of.

This is covered in the global weather problem I describe in the IMPORTANT announcement at the top of the forum. I don't think it isn't anything at all to do with the option to extend the upper wind level. As described, it happens because the "global" weather gradually becomes localised. Then any changes made to global aren't seen locally.

If you look at the advanced wx dialogue and custom settings, winds tab, the upper level will be 100,000 feet as forced by fsuipc. When you try to leave that page,you get a pop up telling you to set the limit to between 0 and 99,999.

Yes, there are lots of things that do that in those dialogues, and not just from values set by FSUIPC. This was the same, in fact, in FS2002 and FS2000.

Doing that and SHAZAM, the weather appears.

If you go into the weather dialogues and press "OK" you are effectively resetting the complete weather system back to user-defined global. that's al that is happening there. It doesn't solve the problem I describe in my IMPORTANT announcement. I don't know of any solution except to move to local weather stting programs.

Regards,

Pete

[Pete Dowson]

Have been doing research this morning on interrupt affinity masking...there's a utility in the Win XP Server 2003 Resource Toolkit that allows you to set processor affinity for drivers doing hardware interrupt handling, which may be at the root of this problem with serial I/O.

The utility is called intfiltr.exe...you can download the WIndows XP Server 2003 resource toolkit from support.microsoft.com. The utility applies to Win XP pro as well as Win XP Server 2003 per the docs.

With the serial I/O interrupt handling set to CPU0, the PFC driver still drives both CPUs up to 100% when FS9 is set to dual-processor affinity. I've also discovered that the sound card (Audigy) does not take well to having its interrupts tweaked...it hisses and pops like mad when you do. Lots of other interesting possibilities are unfolding.

Sorry, I don't understand how this helps me at present.

According to another report here, using GPSout, which also uses a serial port, doesn't actually cause the HT problem. Of course, it's use it trivial -- only output, no input (so probably less use for interrupts), and quite infrequent by comparsion. Also I don't think it uses concurrent serial operations, but its own separate thread instead.

If you want to try tests on variations I might think of for PFC.DLL, please write to me on my email address as I suggested.

Regards,

Pete

[BC]

Hey Pete!

That last seems to have fixed the problem.

Now there is a problem with views. May not be your deal. Further testing required, but after a time the pan views don't work. View down, view up, well, not working.

Man, if it ain't one thing, it's another.

But the HT thing seems to be fixed.

Well Done!

BC

[Pete Dowson]

Now there is a problem with views. May not be your deal. Further testing required, but after a time the pan views don't work. View down, view up, well, not working.

I don't do anything with views at all, sorry. They are all FS's responsibility.

Regards,

Pete