FSUIPC_Process() has big delay

[Guest]

I have written a DLL module for FS2002. My module creates a thread which loops thru a bunch of functions that read and process game data.

I have timed FSUIPC_Process() function, the damn thing eats ~27 miliseconds each call. My loop only reads 9 variables. And I do use FSUIPC_Open2() for internal module users. So as a result, my loop cycles about 30 times per second. But I need at least 50 times per second.

What takes so long inside that function? is there any way to speed things up?

I noticed that game frame rate is also about 30. Perhaps it's not possible to call FSUIPC_Process more than once per game loop? If this is so, then I can simply call it once per 2 loop cycles in my thread, which will be acceptable.

I'll donate 10 bucks if you can take 10 ms off that function call. :-)

(it's not much, but I'm not getting paid for this project)

[Pete Dowson]

I have timed FSUIPC_Process() function, the damn thing eats ~27 miliseconds each call.

You've got something wrong there. It is almost always less than 1 millisecond, not measurable with the normal timers.

But I need at least 50 times per second.

That should be easily achievable, and is actually exceeded even by some external programs which have to do Process Switching as well.

I noticed that game frame rate is also about 30. Perhaps it's not possible to call FSUIPC_Process more than once per game loop?

The data update will certainly not exceed the FS frame rate. All the parts of FSUIPC which obtain and populate the data which you are reading will be running at the FS frame rate at best (for some lesser items which involve procedural excursions into the nether parts of FS I reduce the frequency a little).

However, the IPC calls, whether via the direct WM_IPCACCESS message you are using, or by the SendMessageTimeout from another process, are dealt with immediately and involve no delays within the FS process, unless something else is taking processor time away during this period.

If fact, if you enable "Extras" logging, FSUIPC itself will Log any IPC call which takes longer that 20 mSecs. If you want it to log all the times for all the calls add a line "Debug=Please" to the [General] section of the INI, and set LogExtras to 8 (instead of Yes). But don't leave this sort of logging on, it will slow things down a little itself.

I'll donate 10 bucks if you can take 10 ms off that function call. :-)

(it's not much, but I'm not getting paid for this project)

I assure you it really isn't possible to take 10 mSecs off something that rarely gets to 1 mSec. If you are measuring more than 1 mSec consistently you have something going wrong.

Maybe it's related to the data you are reading/writing? Many of the Write requests do provoke actions in FS, which will take more time -- for instance Saving a FLT can be provoked by simply writing through FSUIPC. That will take a few milliseconds no doubt.

Pete

[Pete Dowson]

More thoughts on this.

I've only just noticed that you are calling FSUIPC from a separate thread, not the main FS thread. Correct? The Open2 method uses SendMessage. The MSDN data on this as it relates to threads says this:

"Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message."

.. so your "SendMessage" is actually behaving more like a PostMessage, just adding another item to the complete Message queue for Flight Sim's main thread (in which FSUIPC runs). This rather defeats the object of the SendMessage. FS uses the message queue very extensively in any case. Within a single thread SendMessage calls the appropriate Window procedure directly, so it is then as efficient as a direct call.

I seem to recall a time with Windows programming where you were'nt even supposed to use SendMessage between threads, only PostMessage. Looks like they've got around that by treating them the same when this arises.

Really FSUIPC cannot do anything until it receives your Message. Once it does it processes it very fast indeed. I suggest you call FSUIPC in the normal FS main thread and see what results you get then.

Pete

[Guest Mark]

Hi,

Using Java I get either 1mS (smallest measure) or slightly larger when the VM (Java) is thinking.

Cheers

[Guest]

I understand now, calling FSUIPC_Process from different thread results in big delay.

I don't know how to make my function get called every frame. Right now I'm using 2 functions from GAUGES.H:

void FSAPI module_init(void){ FSC_init();}

void FSAPI module_deinit(void){ FSC_close();}

First function starts my thread, the other closes it. I have tried putting code inside this function:

static void FSAPI update_routine_610( void )

{

element_list_update(*Linkage.gauge_header_ptr[0]->elements_list);

test_func("update");

}

But it never gets called. Could you tell me how to make my function get called every loop iteration in FS?

[Pete Dowson]

Could you tell me how to make my function get called every loop iteration in FS?

Most things in FS are called via "chains", which are, in most current versions of FS, set up and controlled by CHAIN.DLL . However, there are many different chains called for different things and it is not easy to sort out. Additionally you would have to rewrite and research this for each version of FS. I really have no idea what FS's "loop iteration" would be, there's no single thing you could pin down.

I think most people who do add-in Modules must have them operated by timer calls (SetTimer with a procedure) or by having a simple small thread which loops, and sleeps, sending a message at intervals to an invisible Window procedure in the DLL.

I don't know what you are trying to do as a DLL but I normally try to discourage having more such continuous activity running inside FS itself, which is why I strive so hard to provide a good service for external programs. The advantages of EXE's are that you can do what you like, take full advantage of all Windows facilities for processes and threads, not have to worry about different versions of FS very much (FSUIPC takes care of that), and not really have to worry about the impact your code has on FS performance -- which is a major concern for internal DLLs.

Additionally, an EXE interfacing to FSUIPC will also run on a separate PC via WideFS -- surely a really big advantage as then both your program and FS get to run better. The current versions of WideFS can easily manage to provide updated data at FS frame rates, which is surely all you need.

Regards,

Pete

[Pete Dowson]

I don't know how to make my function get called every frame.

One thing which might be interesting to check. As you said, the 27 mSecs you are experiencing is remarkably close to being in step with your stated FS frame rate of 30 fps. Why not try to change the frame rate and see if this affects the measured elapsed time on your thread calls? Try both limiting the frame rate (in the frame rate limiter in FS) to, say, 15 or 20, and also see what happen if you get it much higher (reduce some of the display options).

Just a thought. Of course the 27mSecs at 30 fps may be a simple fluke. But if it isn't then you've already got a way of matching the frame rate.

Regards,

Pete

[Guest]

When I dropped frame rate to 17, FSUIPC_Process delay jumped to ~45 ms.

When I increased frame rate to 47, FSUIPC_Process delay started to jump anywhere from 5-22 ms. And in one case, it measured 0.086 ms.

Increasing frame rate to 80 drops FSUIPC_Process delay to 1-12, with a few delays being less than 1 ms.

I guess what I could do, is make 2 threads. One that reads game data, and another that loops thru my functions, which I want to keep at 50 interations per second.

[Pete Dowson]

When I dropped frame rate to 17, FSUIPC_Process delay jumped to ~45 ms.

When I increased frame rate to 47, FSUIPC_Process delay started to jump anywhere from 5-22 ms. And in one case, it measured 0.086 ms.

Increasing frame rate to 80 drops FSUIPC_Process delay to 1-12, with a few delays being less than 1 ms.

All sounds relatively logical. The processor load from FS itself is obviosly partly to blame, but mostly its down ot the frame cycling by the looks of things.

Pete