FSUIPC performance

[vdkeybus]

I have created a Windows program with a dedicated thread that transfers data between FSUIPC and the serial port. This thread yields to other processes (e.g. FS) whenever the serial port is busy transmitting or receiving a block of data (synchronous, non-overlapped I/O).

Currently, I'm updating FSUIPC variables at a rate between 2 and 20 Hz using C code that looks like this (the program is based on the BCB example in the FSUIPC SDK and I'm using FS2002):

FSUIPC_Write(0x3ae8, 8, &throttle_L, &dwResult);

FSUIPC_Write(0x3a28, 8, &throttle_R, &dwResult);

FSUIPC_Write(0x3af0, 8, &mixture_L, &dwResult);

...

[Another 10 R/W requests]

...

FSUIPC_Read(0x0574, 4, &alt, &dwResult);

FSUIPC_Read(0x02c8, 4, &vsi, &dwResult);

I noticed that the FSUIPC_Process() function takes a while to complete. On the other hand, it seems to return almost instantaneously when FS stops processing (when e.g. the FS menu bar is popped up using ).

What is the typical request completion time ? Does it strongly depend on the number of requests in the transfer frame ? Should I consolidate a few variables in a larger block ? I'm planning on posting FSUIPC requests in a more intelligent way, omitting FSUIPC_Write()s with (nearly) the same values. Is this worth the while, given the fact that data copying shouldn't take more than a usec on Pentium IV ? Perhaps some synchronization mechanism with FS is executed for each request in the frame ?

Finally, I must congratulate the creator of FSUIPC for developing an excellent piece of software. It's stable as a rock and very easy to program with. If you need to read or write FS data, I wouldn't even consider the option of writing a DirectInput driver or module .dll anymore.

Thanks for your support,

Jeroen.

[Pete Dowson]

I noticed that the FSUIPC_Process() function takes a while to complete.

Unless you are asking FS to load or save a FLT file, or something similar, 99% or more of the time taken by the FSUIPC_Process call is occupied by two things -- the time to change processes, and the time the message is queued, in order, in the FS message queue for attention. Almost all requests, except obviously those involving FS in disk activity, are completed in FSUIPC from the time it receives the message, in well under 1 millisecond.

What is the typical request completion time ? Does it strongly depend on the number of requests in the transfer frame

No, the effect of multitudes of requests is miniscule, just processing in a loop. The memory is shared in any case so the amount of data isn't relevant.

Should I consolidate a few variables in a larger block ?

It may be more efficient, but I don't really think you'll measure any difference -- and certainly not if in the process you include stuff you don't want. If using WideFS from a Client PC on a Network it is really a waste of time as WideClient does that for you, automatically, before sending the request to WideServer. Of course, with Network access there's no message queing nor process switching penalty in FS, but there is the time taken by the Network exchange.

Perhaps some synchronization mechanism with FS is executed for each request in the frame ?

No. Some requests (all weather ones, for example) are certainly synchronised with FS frames, and some others are, but mostly reads are dealt with from memory -- possibly populated on an FS frame basis, of course. None of the frame-synchronised requests hold up the return from the FSUIPC_Process call, though.

Writes are a bit different, and can take a bit longer, depending on many things. Many will need a message sent by FSUIPC into FS and will await a response, though in FS2002 and FS2004 I have tried to make most of the more important ones direct calls into SIM1.DLL.

Programs like Project Magenta are reading many values continuously, at reasonable FS frame rates even across a Network, and still providing external autopilot control as well, over the same mechanism. You should have no trouble whatsoever maintaining anything from 20 to 50 frames per second on the FS PC, depending on processor speed and your own program's processing requirements -- I have 4 client PCs and PM running at 20+ fps with no problems, and that includes Network overheads. Of course I set the frame rate limiter in FS to allow the Network more time. Maybe, even on the same PC, you need to use the limiter to give your program enough time? Maybe once FS gets control, from your "FSUIPC_Process", it is slow in relinquishing it?

Regards,

Pete

[Highvolt]

just wanted to say thanks, because i was going to ask the same question one of these days :)

Cya