Read and Process

[derosa]

I am having problems keeping timing requirements in my software. Currently I am reading about 50 offsets and then calling process. The amount of time to do these steps seems to be all over the map. Sometimes it's around 8 mSec and sometimes 1/4 sec. Is there something I am doing wrong or is this just the normal behavior when talking to FS2004. Also using the latest FSUIPC Module.

[Pete Dowson]

I am having problems keeping timing requirements in my software. Currently I am reading about 50 offsets and then calling process. The amount of time to do these steps seems to be all over the map. Sometimes it's around 8 mSec and sometimes 1/4 sec. Is there something I am doing wrong or is this just the normal behavior when talking to FS2004. Also using the latest FSUIPC Module.

Well, there are several reasons for this.

The interface from an external program uses "SendMessageTimeout" to request FSUIPC.DLL to examine the common data area and process the new commands. The action of sending a message between two processes causes a "Process Switch", which will take a variable amount of time and could be negligible on a multi-core processor but possibly several milliseconds if your program and the main thread of FS are using the same core. It will also depend on what other processes you have running on your PC and their relative priorities.

The message is placed into the normal queue of messages waiting to be processed in FS -- every process only has one message queue from which they are distributed to each component as the message loop gets to them. This is where the main element of variability comes in, as when FS's main thread is engaged in something time-consuming it is not always processing messages.

Then, once FSUIPC finally sees the request, the action it has to do varies considerably from one offset to another. Once upon a time, in FS98 and before, all these offsets were just that -- displacements from a base address in GLOBALS.DLL, and almost everything in FS was controlled by these global values -- so writes were effective simply by writing to the memory and reads always gave the results needed because that's where they were.

Since then FS has been gradually but ultimately entirely re-written to use private data, encapsulated within C++ class structures, using complex heirarchical ownerships and so on, spread over several DLLs. FSUIPC has to access these in a variety of different ways, some involving a series of calls to procedures in several parts of FS -- a further reason for varying times in dealing with things.

In FSX the new SimConnect interface is used by FSUIPC almost to the exclusion of all these methods (but not entirely at present). But this in itself is also variable in time taken, as the SimConnect interface is asynchronous and involves things like named pipes or TCP/IP communication, even internally from FSUIPC.DLL via SimConnect.DLL. However, whilst the latency might be greater due to this, I think the timing is more consistent, only depending on FSX's other tasks.

If you have a need for consistent timing you must split off the requests to FSUIPC from your timing part (maybe using separate threads), and accept that sometimes, between whatever events you are trying to regulate, there may be more than one exchange with FSUIPC and sometimes none.

If your FS frame rates are not consistently steady, then you will never get anywhere near steady rates from FSUIPC in any case, because the whole processing system varies with frame rates. One way of increasing the probability of getting a regulated service is to ensure that you set the Frame Rate limiter in FS to some value which is then always attained, so that FS's frame rate stays regular.

Regards

Pete

[derosa]

Where do I find info on the FSUIPC_Read, FSUIPC_Write, and FSUIPC_Process functions and what they should return. Also how to decode dwResult.

[Pete Dowson]

Where do I find info on the FSUIPC_Read, FSUIPC_Write, and FSUIPC_Process functions and what they should return. Also how to decode dwResult.

In the FSUIPC SDK. There's not much info needed, but it is all there. There's also a set of #defines for the error numbers which are self-explanatory -- otherwise look at the source code, which is commented.

Pete

[Graham Pollitt]

I'd like to say a big thanks for this explanation Pete.

I have set framerate of 30 on fs9 and in my app I have split the reads into different groups so I only perform reads on appropriate offsets at required times. Within my code I also have several timers which read these various groups and I must say that I havent noticed any timing issues.

Very interesting to know what is happening behind the scenes

Thankyou!

Graham

[derosa]

Is it better to call a read and then process or to call several reads and then a process?

[Pete Dowson]

Is it better to call a read and then process or to call several reads and then a process?

Since the read does nothing but add a request to your own data in your own process, it costs nothing. The Process call makes a process switch and costs a lot.

So, what do you think? Lots and lots of expensive process calls, one for each data item, or lots of free data requests all then transferred in one process call? ;-)

Please read the description of the Process I posted earlier in this thread. Surely that would have answered such questions? You should ideally be spacing your process calls out to more or less match the FS frame rate you are expecting. Say one every 40 or 50 mSecs , at most. Less if your needs are less.

Pete