70% drop in framerates when FSUIPC connected.

[flightdecksoft]

Pete,

Thanks again for all of the work that you have provided to the community over the years. I have written a fairly large program that reads about 40 offsets from FSUIPC (not including TCAS) via WideFS and I have noticed that my frame rates go from 64 fps to 20 when my software is connected to FSUIPC dll. Granted I expect some overhead from reading data, but by any chance are the calls to FSUIPC_Read blocking function calls? I have broken up the reading into chunks of about 10 offsets to try and lessen the load on FSUIPC but I don't see any gain in framer rates by doing that. Any suggestions? I can send you some of the code via email to give you a better idea if you need it.

Regards,

Jason

[Pete Dowson]

Thanks again for all of the work that you have provided to the community over the years. I have written a fairly large program that reads about 40 offsets from FSUIPC (not including TCAS) via WideFS and I have noticed that my frame rates go from 64 fps to 20 when my software is connected to FSUIPC dll.

With only the one program connected via WideFS from another PC?

To start with, with a WideFS connection you should be limiting your frame rates in FS to the update rate your Network can cope with. Depending on your FS PC, 64 fps may not be a good rate for coordinating Network programs. It isn't anything to do with how many variables you read or how often, because all those are maintained by WideClient in your client PCs. Once you ask for an offset, any offset, then WideServer knows that PC is interested in it and will thereafter continually send it whenever it changes. It sends nothing when it doesn't change. At the most, WideServer will attempt to match the FS frame rates -- some variables change at frame rates, some more often, some less often, but WideFS tries to regulate that.

You can probably get higher network frame rates using UDP or IPX protocols than TCP. I use UDP on my 8 PC cockpit system for just this reason, and can sustain a good frame rates on FS and throughout the Network. UDP is checkless -- if anything is wrong on the network, UDP give lose data or get it worng. If you get problems you would need to fix them or use TCP. But choose a sensible frame rate limit in FS.

Also, do check the logs. Frame rate slowdowns are often due to things going wrong -- retries, reconnections, etc. Look in the FSUIPC, WideServer and WideClient log files, see if there's anything not looking right.

Or, are you testing your program on the FS PC, not via WideFS? If so, it sounds like you are being extremely inefficient in the way you are reading them. There are programs around which read many hundreds of variables at frame rates (20 times per second or more) without noticeably impacting FS performance -- those used to drive external gauges, for example, in the assorted hardware cockpits around.

Granted I expect some overhead from reading data

You shouldn't even be able to measure it, especially not for a mere 40 variables. That's next to nothing.

Try some testing with the supplied FSInterrogate program. You CAN use that to slow FS down -- for instance selecting every listed offset, all many thousands of them, and reading them at its top rate. But for all normal selections you cannot measure the impact -- not providing FS has the focus, of course. If the focus is on FSInterrogate then FS gets less processor time by virtue of the user focus, not because of any FSUIPC servicing.

but by any chance are the calls to FSUIPC_Read blocking function calls?

What does that mean? What function calls?

I have broken up the reading into chunks of about 10 offsets to try and lessen the load on FSUIPC

That's the exact opposite of what you should do.

Do all the "FSUIPC_Read" calls. Those don't interface to FSUIPC at all, they simply build your request in memory. THEN do one FSUIPC_Process call. Only that actually does anything with FS/FSUIPC. Every Process call you do means a Process change. Only do one per cycle, and most certainly not one per variable -- that would be a very big mistake!

And do not sit in a tight loop trying to read with no delay in between -- you won't give anything else a chance to do anything. You should be doing all this once per cycle, only, and your cycles should ideally be driven by something like Timer calls from Windows. Something like a 50 mSec timer (giving 20 cycles per second). You could use "Sleep(50)" instead, but then your program's thread cannot do anything either, and you possibly have other Windows messages to service.

Regards

Pete